I recently saw a graph from The Standish Group quantifying that only 20% of all delivered software features are “often or always used.” This is a pretty staggering statistic to take in, considering when I think of this in light of what my client is building right now for their customers. Could it be said that only 20% of our effort is used??? Think about that for a minute!
What we could do is to completely elaborate, build, test, or document our releases so we can, when looking back, see what was most important to the user… but this would be too late…
Beginning an journey in Scrum can be as exciting as any new endeavor that we begin in life. It can be exciting as well as overwhelming.
A good article I recently read had given me a fresh perspective on this, and with any type of self-improvement, it is valuable for us to self-reflect on how this new improvement is really going to help our lives.
There are many different types of Agile tools out there. Some are free, some are paid, some are going by the new business model called “Freemium” in which you get a distilled version of the software but to get all the awesome features and scaleability you have to pay.
We’ve talked about before how important product owners are in the whole agile process. This is still true. This will always be true!
These product owners are Very Important People as the PO is the person responsible for determining what the team is going to build. This is an important construct in Scrum because it unifies the voice of the business for the team. They are also the ones that set the priorities for the team as well. When there are changes in requirements, the PO continuously makes the decisions and gives the latest information to the team about the changing priorities. Development teams are always asking the questions: “What do you want me to build? What is the business priority?” – The PO tells us!
Philosophical conversations over lunch or coffee often lead to a lot of thinking about our current situations and clients. I sat down with a client over lunch and our conversation steered toward our team, and how it there are so many dependencies hamstringing the project currently. From technological and systems issues, to specific coding knowledge of certain individuals, and even dependencies on time zones. It got me thinking about how dependencies truly affect development and our basic assumptions about them.