Happy to announce that the VUCA MBA website is now live. I have felt for sometime that there is a … More The VUCA MBA (Mindset for Business Agility) Website is Now Live (and open for business)
Retrospectives are my favorite of all the scrum activities because they represent the opportunity to reflect on how we are implementing and to adjust our behavior to be more effective.
I have said to my teams on many occasions that if I were forced to choose only one scrum ceremony that my choice, without hesitation or reservation, would be the retrospective. Without it, how could we ever expect to improve? What essential difference would an “Agile” project have over the many death march projects that teams have come to accept?
In 2002, Jim Johnson of the Standish Group (made famous by their Chaos Report of software project “success”) presented findings of features and functions used in a typical system. The number of features that were never or rarely used totaled a whopping 64% while sometimes, often and always weighed in with 16%, 13% and 7% respectively. For those acquainted with the Pareto principle (80/20 rule), notice how the often and always used features – those things we should concentrate on building for our customers and those things things that bring us the most value – is exactly 80%.
In other words, a great deal of our effort is generally spent creating things that customers do not use or want.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
When I think on this principle I cannot help but think about the potential “dark side” of agile and how it can be misunderstood and implemented incorrectly.
Metrics. Metrics. Metrics. We love numbers. We measure and put numbers to all kinds of things. We use these numbers to mark our projects as red, yellow and red (of course, the project is always green until there are a few weeks left when someone finally blinks and acknowledges reality and begins to use yellow or, god forbid, red).
Unfortunately, in our headlong rush to create metrics we tend to forget the why of what we are doing. Numbers and statuses become an end unto themselves.
The most efficient and effective method of conveying information to and with a development team is face to face conversation.
Since there are so many misconceptions about miscommunication around agile, I created my business cards to contain the entire Agile Manifesto so that when people confuse scrum framework with agile philosophy or say, “This is agile blah, blah, blah,” I can hand them my card and say, “This is agile.”
Then I let them know that agile is nothing more than a philosophy, a series of values and principles.
If I had to take exception to any value or principle this would have to be the one.
While I have the utmost of respect for the original Agile signatories, they made a slight mistake because this principle refers to only projects. I have ranted often enough about the distinction between project and product management (See this post for more), but it is important to understand that Agile works best when we build a product (not a project) mindset. By having a principle that mentions projects might hinder folks from transforming their thinking to product-centric thinking.
I quote this principle verbatim to all the teams I coach constantly because it is the only completely prescriptive principle. While other principles use more vague words like “early”, “late” or “shorter”, “daily” is not open to negotiation or interpretation. The word “must” is also unequivocal as are the roles described.
That prompts the following question – why were the founders of Agile so strident with this principle while allowing for broader interpretation with all other values and principles?
While there are many people who believe that the key reason to adopt agile frameworks and methods is for increased productivity, I tend to find this to be more a healthy byproduct of a team working together over time (and thus could be found in other methodologies).
The real benefits of agile lies in greater transparency, predictability and faster time to market.
The third agile principle speaks directly to these, especially quicker time to market.
The world changes fast. The software development world changes faster.
Locking into a long term plan and remaining steadfast to that plan might bring comfort when the world around us is awash in change, but it doesn’t give the flexibility necessary to remain competitive.