Things Change. Be Agile.
If you missed it, here’s my newest presentation about story points that I gave to the Phoenix Scrum Users Group yesterday.
Here is also a cool video of the meeting that Alan Dayley shot using the new Hyperlapse app.
Thanks for everyone who came out! I had a lot of fun.
As an agile coach who has had the wonderful opportunity to work with many diverse companies in many different fields, I can attest that one of the benefits of having a coach is having a wealth of experiences from which to draw upon and over time we are able to notice patterns even among disparate companies. Some are rather obvious, like the inability for organizations to understand the difference between project and product management or that agile is an organizational change, not just an IT change.
Nevertheless, there are some patterns which are sometimes less obvious (or at least I have been more oblivious to) or that seem to take longer to identify.
Recently I had an, “Aha!” moment when looking back on my prior experience which has led me to coin a brand new axiom – agile is about leadership, waterfall is about management.
Like all things obvious after the fact, when this finally dawned on me I felt silly that I had not noticed the distinction before – duh, of course you say! However, the distinction is subtle so, in my defense, please don’t judge me too harshly.
The realization has been fermenting for some time, but it struck home recently when I was discussing issues around organizations transitioning from waterfall to agile with a colleague of mine. The trend I was referring to was the fact that nearly every agile transformation that he and I have worked have been initiatives from the project management office.
While a transition from the PMO can be successful, the very fact that the PMO is more about management (in most organizations), that even having the word “management” right there in the middle presents organizations with inherent challenges. The PMO is about top down, command and control. Should a scrum team actually have self organization, usually in spite of the top down PMO, and find something that works well for their team, the PMO usually pounces on this innovation, desperately solidifying it as a “best practice” for every team in their command.
I remember one innovative coach who used trophies to recognize agile excellence for their team. It was appropriate to that team and worked well for that team. This is an excellent example of leadership (and a self-organizing team). Unfortunately management happened to attend one of these trophy presentation ceremonies.
What was management’s response? “Wow this is great! Let’s buy a bunch of trophies and make every single team do this going forward!”
Unfortunately, this type of top down management is what PMOs are used to and comfortable with. This is one example of why PMO-led agile transformations are so challenged. The urge to manage (waterfall is about management), as opposed to allowing teams to self-manage (agile is about leadership), is in the DNA of most PMOs (and most organizations).
This mentality is easy to find. All you need to do is to gauge the amount of fear in the organization. The more fear, the less leadership. Is CYA the order of the day? Don’t expect your agile transformation to go smoothly, but CYA is the hallmark of management.
Avoidance of failure is not the same thing as success. Avoidance of failure and the concomitant avoidance of blame is the realm of management. Pursuit of excellence and success is the realm of leaders. Is your agile transformation not going well or you are not receiving the benefits you expected?
Stop trying to manage and lead. Stop using managers and start using leaders. Move the transformation from management silo into the realm of organizational leadership. Perhaps you should appoint a Chief Agile Officer.
Remember at all times – agile is about leadership, waterfall is about management.
I have presented in the past something I called Rapid Release Planning. While I stand by this method for teams that have a history of delivery, I have found a much better way for new teams or teams with no previous history of delivery. It’s called Silent Grouping.
If you are interested in possible mechanics, please follow the link above. The only guidance I would provide is that I do not start out by using any numbers. This seems to work much better in that all I ask is for the team to place the stories from smallest to largest. Natural groupings occur when you do this and then you can then use these groupings to draw lines on the board that would correspond to points from the natural groupings.
The real importance is that by utilizing this technique a newly formed team is able to get stories pointed much faster than anything else I have ever found. It keeps people focused on relative size and avoids in depth discussions about acceptance criteria.
More importantly it can be used for other single dimensional relative measures, story value, for example. If you then take these two relative values you can come up with a quick, easy and painless way to see a relative ROI for each story.
When I tell people I am an Agile Coach, unless they are in IT, I tend to get a lot of strange looks. Most of the time they will say something like, “I get the coaching part, but what the heck is Agile?” It is at this part of the conversation that they experience immediate regret as I launch into an endless barrage of commentary on Agile development.
Lately, however, I have begun to re-examine my own assumptions about what it the Coaching aspect of an Agile Coach is, especially now that there are so many professional coaches looking for work after the end of the regular NFL season.