Agile Adoption: Projects Should Dive-In, Organizations Should Toe-Dip

Posted by Mike Bria on Aug 19, 2009

Sections

Process & Practices

Topics

Agile ,

Adopting Agile

Tags

Adoption ,

Introducing Agile

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?

1. Back to top

   both...here are two examples...

   by Kevin E. Schlabach

   The plunge for a global 50 company is described here:
   
   agile-commentary.blogspot.com/2009/07/post-agil...
   
   
   
   The toe-dipping approach is tomorrow's blog post (8/20 "A further experiment in Kanban" agile-commentary.blogspot.com/ )

   Reply

2. Back to top

   All-in for methodologies, think Agile

   by Henrik Leion

   The problem with any process methodology is that although it looks good on paper, it is only if implemented through and through that it will pay back. The difference between Scrum and many older processes (or methodologies- or process frameworks) is that it actually has a fair chance of being implemented properly, something which is very unlikely to happen for, say RUP (just the sheer size of the process framework documentation is a road block). But still, mea culpa [tm Jim Coplien] for not adhering to the process close enough when my project fail.
   
   
   
   
   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).

   Reply

• Older >