In the last few weeks we (Agilesparks) have been trying to liven up the israeli scrum forum – iScrum.
This is a forum dedicated to practitioners of Agile/Scrum in Israel. There are some interesting discussions and ideas and its also a place to monitor for events in the israeli Agile/Scrum community (e.g. user groups, ask the expert sessions, etc.)
One of the questions raised was the issue of agile adoption curve. There are several interesting opinions, and I’ve been thinking a bit about this subject, see two of my comments:
ince indeed it is a journey, a critical question is what is the break even point on this project or in other words how long to roi.
The costs are investment in Learning, training, coaching as well as organizational time, attention and productivity loss due to learning curve and transition difficulties ( see the j-curve mentioned in the material Inbar quoted )
depending on the specific variables of the transition the time will vary but it will be more in the months time frame to years timeframe I think.
Note that at that point it’s important to continue to drive to more and more agility to get even higher benefits
and
Another reference to the change curve is in the Virgina Satir Change model also see .
An important point to take from this model regarding change and agile transitions specifically, is that the level of resistance/chaos that causes the productivity dip and risks to the transition, is a function of readiness and preparation.
An organization can minimize the time/impact of the dip by improving preparation. Improving preparation is possible if you assess your readiness for this change and focus on improving readiness before going into the change. While this sounds a bit un-agile, it seems like there is empirical research around this that shows that at least some of this preparation brings better results.I’ve also been thinking about the implications of exactly how you do your agile transition (or any similar change for that matter) on the change curve. Some of my questions:
* Is it better to dive in across the board, or do it in vertical slices of the organization? In other words, is it better to stagger the productivity dip, or to have one big dip and get it over with? My instinct is to stagger the dip, with the added value that after one slice (department) has gone thru the dip, the organization has better strength/stamina to go thru another dip because it knows what waits on the other side, and its also more prepared at the organizational level to support the change. In addition the risk of a big organization going into such a dip, with the various departments feeding off each other’s dip, and the supporting functions trying to support everything and remove impediments everywhere at once, is a scary notion (speaking from experience…)
* Is it better to implement a change via a big bang methodology (e.g. Scrum) or a pattern/practice at a time? Here, while I think the dip will indeed be shallower for each practice, in most cases you’ll want to move fast to utilize the “driving force” of an enterprise-level change. It is important to note that after you DO the big change, it might be best to continue with one practice/pattern at a time, in a Kaizen/Continuous Improvement spirit. Note that the Lean/Toyota style talks about doing even the initial change in a flow mode rather than a large batch mode. Sounds agile to me ;-)
Together with a few colleagues we were looking at the effects of this curve on a big enterprise transition we are involved in, and trying to learn from it. I’m sure some more thoughts will come up…
Join us in the discussion!