How do we go about to instill an Agile mindset and help teams deliver quality solutions? The two main strategies are the “Big Bang” and pilot project approach. I’ve never had the opportunity to go ahead with a Big Bang, so the alternative has been to find a cool project, get a team together, Scrum the hell out of it and watch all the nasty stuff come up. With a few lessons learned and improved processes, start up a second team and so on and so forth.
During a transition process, I often use the same expression as when I’m writing a piece of code: Baby Steps. Baby steps are a good thing! Write a small test, write a bit of code, make the test pass, refactor, rinse and repeat. But in an Agile transition, baby steps are more like compromises. That is, we start a Scrum pilot project and we “temporarily” set aside, bend or extend some of the principles of the Agile Manifesto and pillars of Scrum.
So when a team or an organization feels it necessary to not go full steam ahead with what I consider to be the best way to create quality software, I constantly ask myself : Are we simply taking a baby step towards something more “agile” or are we setting a bad precedence?
A few examples:
- The core team is not 100% on the project- Baby steps or Bad precedence?
- Co-locating teams might happen…one day – Baby steps or Bad precedence?
- Little to no focus is put on improving Agile engineering skills – Baby steps or bad precedence?
- The newly assigned ScrumMaster has never even heard of Agile, Scrum or XP – Baby steps or bad precedence?
- The project is more mini-waterfall than Agile – Baby steps or bad precedence?
- The first 25 items in the Product Backlog are non-functional requirements – Baby steps or bad precedence?
- Transparency is set aside not to upset upper-management – Baby steps or bad precedence?
So if the members of team A are allowed to not be fully dedicated a one project, and a nonchalante “ScrumMaster” tech lead is assigned, what will happen when team B’s manager sees this? Ya ya, I know… Team A and its manager will see the error of their ways, the appropriate changes will be applied quickly and team B will profit from those learning experiences all will be rosy in lala land. Sometimes it happens but it becomes rare when it involves core practices of the organization.
So why do we accept this?
Well since excuses and justifications are the ointment to any compromise to the Agile Manifesto, let me offer you this one: If we, as Agile coaches push too hard, we are perceived as purist, not in tune to the reality and constraints of the organization. Pushing too hard might actually result in the opposite of the desired effect and the Agile transition will force two worlds to collide and the whole thing will go kaboom!
Baby Steps or Bad Precedence?
So how do we make that call? Even better question, how do we bring a team and its organization to make that call and consider the short to long term consequences? What is the break point between Agile values and half arsed Agile values? Do we simply rely on common sense when common sense is often in short supply, or is there some kind of calculated “kaboom factor” that could help guide our decisions?
Baby steps are fine as long as we are not stepping right off a cliff!
24 septembre 2010
A good «kaboom factor» is to blow up one concept at a time.
– Find what is the currently most painful (difficult, productivity sucking, etc.) part of the organization work.
– Match that problem to a solution, many of which come from Agile practices or ideas.
– Apply the solution, breaking cultural or other barriers with the precision «kaboom»
Of course, human change is not as instant as an explosion. Also, several smaller explosions (improvements) may have to be experienced before the needed trust and credibility is established that will allow discussion of a big change.
I’m a big fan of doing whatever possible to avoid bad precedents. I’ve worked on transitions both ways, baby step and big change. I’ve found baby step to be harder in the long run. (Long = about three months.)
25 septembre 2010
Thanks for the great response Alan!
I love the «precision kaboom»!
26 septembre 2010
One of the factors I think is the size of the organization.
For large global organizations, I believe that piloting a couple teams to begin scrum is the right way. My reasoning is that a lot of other things need to be piloted to see what is the best – consistent way to configure tools and reporting. Once you have piloted and have come up with the best practice for supporting tools & reporting than it’s easier to roll out. This phased approach also lets to build an army of scrum SMEs to evangelize and help peers on other teams adopt agile.
Just my 2 cents…
27 septembre 2010
If I’m doing baby steps with something like Scrum, I’ll approach it like this.
1) Find a big pain point in the organization/team.
2) Apply an Agile technique to help either resolve the issue or make it visible.
3) Make it clear, that this is *not* Scrum. We’re not doing Scrum yet, this is just to help with ‘x’.
4) Start training the team on what Scrum is.
5) Repeat the above until the team either knows enough about what Scrum is to want to do it all or until you’ve changed so many practices in the organization that now you’re actually doing Scrum, whichever comes first.
Then you can let the team know that you’re now doing Scrum.
I find this approach meets with less resistance than a full blown conversion, while ensuring that the team doesn’t believe they’re «doing Scrum» when they’re not.
27 septembre 2010
Just like Todd propose, we sometimes have to accept some deliberate concession, only if everybody accept that concessions are crutches.
In the «Baby Step» analogy, there is the concept we are using our judgment and we don’t let Scrum be a barke to productivity.
The «crutches» analogy adds another aspect : no way we are going to need crutches for the rest of our life!
As a ScrumMaster, I’m responsabible of the good use of the Scrum process. I can accept crutches, based on common sens. But in return, I want the organization to accept that derogations are crutches, and that when the time comes, I will kick on then to verify our legs are healed.
27 septembre 2010
Eric, thanks for the thought-provoking topic! Two thoughts related to this:
1) A baby step implies a journey – if this is truly a step along the road to Agile, and there is a plan in place, or at the very least, a goal to become truly Agile, then I’m more inclined to say it’s okay FOR NOW. If, however, this is seen as the “end-state” or “the best we can do”, then it’s probably a bad precedent.
2) It’s also a matter of quantity and severity. I could walk just fine with three 10-pound weights on my back, but just a single 200-pound weight would ruin my whole day! To relate this to your examples: Co-location? Let’s strive for it but until we get there, let’s figure out how to work better with distributed teams. On the other hand, the ScrumMaster who’s never even heard of Scrum? Unless you have a solid Agile coach (or a very experienced team), then this is going to be a major impediment for the team (without the person who would normally remove impediments)!
So to answer your final question, I think it takes more than common sense to solve this. What’s needed is a clear understanding of the impact of each of these “baby steps” and then working with the organization to determine how much “weight” they can bear and for how long, and most importantly how they plan to shed those weights and move ahead.
30 septembre 2010
Mmmm. Is me posting a comment on your blog a baby step or a bad precedence? 😉
I am totally with you on this one. I posted on a related topic (http://analytical-mind.com/2010/09/28/a-dead-coach-is-a-useless-coach/) recently and pretty much come to a similar conclusion – use your judgement and common sense.
It is much more difficult to use judgment and common sense than to simply apply «rules» but it gives much (much) better results in the end – and the person taking the action can actually explain why they have done it.
Keep posting. I love the content.