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.
I was on a call with one of my Agile colleagues the other day and he mentioned that there are now over 300,000 Certified Scrum Masters.
Should I be excited about this fact?
While this is a great marketing achievement for the Scrum Alliance and I would guess it to be profitable for some folks, is having so many good for Agile and Scrum?
It is with some sadness that I must now admit that it is not.
My experience, especially over the last few years as Scrum has mushroomed and CSMs have been minted at a breakneck pace, is that the CSM certification has done more harm than good.
The first problem I have seen with the certification deals with organizational change. As someone on the front lines of transforming organizations from waterfall to Agile over the last 6+ years, I have seen how the CSM becomes a barrier to actual organizational transformation.
Instead of making substantive changes that will allow for proper implementation of Agile, why don’t we throw all of our project managers in a two day course to become CSMs! This will certainly do the trick and no one will be able to blame us should a transformation not take place.How could we be at fault when we have paid so much and lost some much productive project management time to this two day training?
To give someone two days training without giving them the tools to actually implement what they have learned is insane. Better then that, we have the upper management folks take the two day training and then try to implement in their environments. If people in positions of power actually had to learn and implement Agile then I would expect a great amount of pain would be avoided.
The other problem I have seen is being overly confident. While most would agree that two days of training does not make one an expert, any coach who has been around has seen people who, not knowing anything about Agile on Monday, can take a two day course and feel that they are experts on Thursday.
I guess that certification has a way of doing that to people. If you give them a piece of paper that says they are a Scrum Master, they tend to believe that they are one. I don’t consider myself to be the most obtuse person in the world, but I know it took me a couple of years of doing real, day to day, Scrum Mastering before I really knew what I was doing. For some reason a good number of CSMs appear not to follow the Dreyfus model.
A closely related point is one of competence. Those CSMs who are not overly confident are in many cases woefully unprepared to run a Scrum Team and they are honest enough to admit it. Besides, what can you really learn in two days? You certainly may be able to talk to the talk, but given that many of these new Scrum Masters are members of the lagging, lumbering, inflexible, command and control companies, their two day experience is even less effective.
Agile and Scrum are powerful. In inexperienced hands, it can cause more harm than good.
I have also seen issues with the quality of training. I suppose that as much as the Scrum Alliance tries to ensure that instructors are the most competent, there are bound to be incidences on the road to 300,000+ CSMs.
For example, I have run into a great number of new CSMs that have told me that Scrum tells us that we should not look beyond our two week iterations. That long term planning is somehow evil. Of course, this is not true. If it were, what would be the motivation for businesses to sign up? One reason that businesses are reticent to sign up for Agile is that they are seduced by the false predictability that waterfall provides.
Agile and Scrum certainly have a lot to say about what is possible in the future and teaching that it does not is wrong. Of course, it might be that these CSMs have merely misinterpreted what they have been taught, but I have found this perception so prevalent with new CSMs that the fault must lie in the CSM course.Maybe it is taught, maybe it is misinterpreted often, and maybe it is tough to learn in two days makes no difference to me. You are certifying someone’s knowledge in cases where large gaps exist.
All of this would not be a problem if people trying to transform to Agile Scrum understood what a CSM really is. Unfortunately, this piece of paper that certifies you have stayed awake for two days and have understood basic scrum concepts as measured by a very simple (as in no one ever fails) test means something to others.
I have seen it used to weed out people during hiring process. I have seen people to give it much more respect than is due, thinking that someone is competent to be a scrum master merely because they have a CSM.
Maybe we should start making the certification really mean something or give it a different name.
What do you think?
The way I go about choosing which blogs to write is a very simple process. During odd moments in the day, something someone says or does will trigger an idea. If I don’t capture the idea immediately, chances are that I will most likely forget the idea (one of the disadvantages of human aging) so I use Wunderlist to quickly and easily jot down these possible blogs.
Then, being the good agilist I am, I prioritize these potential blogs, this gives the idea time to settle.
I find that many times an idea I was very enthusiastic to write at the onset becomes less attractive over time and will eventually be scrapped without ever seeing the light of day. The “classics”, or those that stand the test of time, eventually get written about.
Recently, I had something else happen. Instead of losing enthusiasm for actually writing on a particular topic, for the first time in my experience, someone has actually beaten me to the punch and published a blog entry so close to the one I wanted to write that I felt I no longer had to write.
That dubious honor goes to Bob Galen and his great post, Agile Coaches – We’re Coaching the Wrong People!?!?.
In this blog, Bob argues that Agile coaches tend to spend their time on activities that are more lucrative and easier to accomplish (like two day trainings and working directly with scrum teams) as opposed to those activities that are most needed by the organization or more difficult to accomplish (creating meaningful organization change and working with leadership and upper management).
I couldn’t agree more, and so I find now that I really don’t have to write the blog entry I identified some time ago called “Agile Coaching at the Wrong Level” since Bob has done such a good job for me.
I urge you to please go out and read his blog!
There is only one thing that I would tend to disagree with based on my own personal experience.
In my past, I have worked in many places where coaches did not work with upper management or shied away from larger organizational change by choice, but have been frustrated by the very fact that they have been purposely been shut out from decisions affecting the organization at large and have either been prohibited (expressly or implied) or discouraged from working with “leadership.”
It is not that there is not value to be derived from teaching teams to be agile and optimizing teams (and scrum masters), but that unless the organization as a whole supports agile, optimizing teams becomes a never-ending treadmill of obtaining a certain measure of optimization in spite of the organization and seeing whatever progress that is achieved by the team erased as teams are constantly formed and broken up.
No matter how good a coach, results are short lived when the teams themselves are short lived.
This issue is one that needs to be addressed by “leadership” and a coach’s inability to positively affect change at the leadership level, whether by choice or by culture, verifies the contention that most coaches are coaching the wrong people and coaching at the wrong organizational level.
Can anyone say Chief Agile Officer?
I have always considered Joel on Software as one of the best bloggers on software development that exists.
I absolutely love his approach to software development and should he ever open an office west of the Mississippi I would be the first to send my resume!
While doing research on another blog topic, I came across his famous blog on the Netscape rewrite. As happens from time to time, a universal truth crashes into our consciousness causing a virtual cascade of neural connections to fire, providing in the instant the “Aha!” moment. It came to me as I read the profound truth that is “It’s harder to read code than to write it..”
I was blown away because while my post, 10 Reasons Why BDD Changes Everything, has some great reasons to adopt BDD, after reading Joel’s blog again (which I had done before and did not explicitly make the connection), I think I might have missed perhaps the most important reason for BDD.
So here’s one more reason, inspired by Joel, for adopting BDD, namely: If it is harder to read code than to write it, BDD provides a simple and concise method for making the code that we write frighteningly easy to read (especially when compared with how most code is currently written).
Over the last three plus years I have coached adoption of BDD at all of the companies I have consulted and have constantly asserted that a team (and the larger organization) cannot be agile over time (anyone can be agile over a short period) without adoption of some form of ATDD (my choice being BDD) and continuous integration / delivery.
I challenge anyone to change my mind with solid proof. So far only one inexperienced scrum master has even tried!
Conversely, the more I read from software development professionals whom I admire and trust (like Joel) the more I become convinced that my position is correct.
Tell me your thoughts.
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 purposely tried to not comment about the Healthcare.gov website and it’s issues, but the landslide of wrong-headed information written on the subject has prodded me into adding my small voice on the upside that someone reading my this post will learn from this software development fiasco that we all have paid so dearly for.
Most unfortunate for those trying to learn from this is that the issue is so politically charged that to discuss it objectively is nearly impossible. The desire to place blame is too deeply ingrained in the human psyche to not point fingers – and this, for anyone capable of laying politics aside is the second lesson – the lesson that assigning blame is a human instinct that is not always productive in solving problems. Root cause analysis is essential to fixing systemic issues and may tangentially point to individual failings, but placing blame should not be primary.
And this leads to the first problem – the fact that this issue can rarely be discussed without politics. Once we have chosen sides, not only do we move from objective root cause analysis to finger pointing, but we begin to be tainted with confirmation bias in that everything we hear, read, experience is pulled through this lens. Therefore, this means that anything contrary to our preconceived political leanings are completely ignored or logically forced into their respective procrustean bed.
In my agile world the cautionary tale is about how office politics can certainly derail our best efforts to be agile. It is only in an apolitical atmosphere where true organizational change can occur. Where facts are not valued and the truth depends on the individual posting it, then the frank, brutally honest conversations (borrowing from Jim Collins’s saying in his book Good to Great) that are necessary to effect real change are never had. In some cases the only people capable of such brutal honesty are consultants with no vested interest or employees so fed up with the politics that they no longer fear losing their job.
One other political struggle that this instance has exposed is the continual struggle between the agile and waterfall camps. Each side has cherry picked their arguments in attempt to bolster their claims and for me to weigh in on one side or the other does little to further understanding. Of course, I come down on the agile side and believe that this project’s failures can be tracked fundamentally to the fact that the project was in no discernible way agile. This argument is not even vaguely interesting to me.
The most interesting point I have heard (and agree wholeheartedly with) is that there are a number of individuals, myself included, who feel, given the proper non-political circumstances could accomplish this work for a small fraction of the cost with a much smaller team. The reason for our confidence is that most of us already have. interestingly not a single soul who has accomplished something of this magnitude has done so using anything other than agile methodologies.
While the political right claim it is big government’s fault, this argument is somewhat disingenuous because the entities that failed are precisely the private sector companies that are supposedly our economic white knights. The real problem, when all the red herrings are swept away, is the procurement process itself that only allows for the largest, bureaucratic and bloated from the private sector to win contracts. Those companies who, by the very necessity of being small, are nimble will never get these contracts so failure is to actually be expected at the same rate (or worse) identified over the years by The Chaos Report.
A long time ago, government misinterpreted Winston Royce’s “waterfall paper” and all contracts are written to favor waterfall development which has been shown to be a poor methodology in delivering complex software. Again and again we run into the core issue that the nature of software development is fundamentally misunderstood as being merely complicated so that throwing money and bodies at a problem (and these bodies can reside anywhere, with any company like interchangeable widgets) will lead to success. Because software development is complex it works best under agile which emphasizes feedback and communication. Simply the fact that so many vendors were working this project shows the complete lack of knowledge and gross incompetence of people who are paid well to supposedly understand software development. In fact, if people in charge actually understood software development then they would have known the job would have been done much better with a small band of government workers and not the disaffected armies of “private” companies.
The reason I and my agile friends know we could have done the work for much less and with infinitely better quality is because we know what software development is and we would have used smaller teams, fewer teams and co-located teams. We would have increased feedback and communication. We would have completed the most critical scope first and phased in improvements. We would have used test driven development and continuous integration and testing to ensure performance all along the way. In other words, we would have operated in a completely egalitarian, non-political manner and achieved success.
What are your thoughts?