Agile Adoption: Projects Should Dive-In, Organizations Should Toe-Dip
Hearty debate abounds about whether agile adoption is better done in a gradual "toe-dipping" manner or with an all-or-nothing "head-first dive" approach. Johanna Rothman says do both: projects should dive all-in, while organizations should take it gradually.
In 2 recent blog posts, Plunge In (For Projects) and Small Steps Are Good, Be Careful What You Call Them, Johanna posits that people need to take all-in approaches to adoption of agile at the project level. In essence, she takes a hard line that doing things like working in timeboxed iterations or doing continuous integration, while likely to improve your situation, does not mean you're doing "agile". And further that you are setting yourself up for failure if you call this agile:
...if you call something agile, please make it agile. If you dip your toe into it, you have not made the commitment. If you vary your timeboxes depending on whether you finish work in the timebox, that’s not agile; that’s incremental development. You can say, “We’re experimenting with incremental development. We choose to vary the length of the timebox so we can practice getting to done. Maybe after we practice it for a while, we’ll fix our timeboxes and see how that works.”
That’s perfectly reasonable. I encourage you to do so, if you haven’t tried incremental development yet. But don’t call it agile. It’s not.
Soon after, Rothman presented a third post that ultimately suggests the opposite when it comes to organizational levels of agile adoption. She suggests that managers take a more gradual approach to changing administrative structures across the organization:
Moving to agile for the entire organization is a non-trivial problem. The zeroth step is the project. The first step is the project portfolio. Then comes the really hard work: the human systems are the next step. Once you’ve moved the human systems back to helping the employees, now you can attack the money systems. (One of my clients is trying to do the money systems first, and that’s not working. There may be some give-and-take here, with the money and human systems.)
Managers, it’s ok to dip your toe into agile for the management systems, as long as you take a coherent piece and commit to agile or lean for that piece. It’s not ok to dip your toe for a given project–commit to agile for a project, if that’s right for you. And, commit to learning about agile and lean management.
In essence, Rothman says over this short series of posts that doing agile well requires a level of discipline that not all projects are prepared for. Choose which projects are ready, and transition them fully; but, worry not about transitioning all projects or the whole organization all at once, think 'gradual' when it comes to that. What do you think?
both...here are two examples...
Kevin E. Schlabach
The toe-dipping approach is tomorrow's blog post (8/20 "A further experiment in Kanban" agile-commentary.blogspot.com/ )
All-in for methodologies, think Agile
Even Scrum, for all it's glory, is still only a process. The Scrum board is just a tool. It may be the best process and tool around today, but the very first paragraph in the agile manifesto is "Individuals and interactions over processes and tools". That is how important Scrum is. The agile manifesto has nothing to say about fixed time-boxes or daily stand up meetings, that is just the process talking. If you want Scrum you should do it, if you don't do fixed timeboxes - you still can be the most agile team in the world, and most importantly, deliver working software any day of the week. Never ever forget the retrospectives though, that's what keeps us agile (and it's the last of the principles behind the manifesto).
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015