upper management's view
Upper management tends to see Agile and it's kin as "the next great thing". It makes sense: these processes promise high quality deliverables and fine grain control of release dates. Also, because customer involvement is high, the deliverable will be precisely what the customer wants - no more, no less. These are things the VP R&D struggles to get right every day - Agile processes are seen as a "silver bullet".
first and second level manager's view
First and second level managers get the bum end of the deal when it comes to rolling out Agile. They have to understand the new process well enough to manage within it. They have to deal with the full spectrum of developer reactions to this change: some developers will fully embrace it, some will do everything they can to avoid Agile process. They have to answer to the VP R&D - and try to explain why the "silver bullet" is taking so long to work.
developer's view
Developers all have something in common: they are motivated to write awesome code and get recognized for doing so. Daily scrums, day+ long planning sessions every iteration, and retrospectives - are just a bunch of meetings that get in the way of being awesome. The majority of developers tend to resent the number of meetings, seeing them as low value. The final issue: Agile makes developers feel a bit claustrophobic, since every aspect of their day has to be "part of the iteration plan, in support of their team".
the challenge
If you read about Agile and it's kin processes, they all say the same thing: "If you don't follow every aspect of the process, it won't work". I call this a "tampering voids warranty" disclaimer - and I don't like it. If someone approaches me with the-next-great-thing and it has a "tampering voids warranty" disclaimer, there's a 99% chance I'll reject it. Let me explain a bit further with an analogy.
I see anything that has a "tampering voids warranty" disclaimer as an immutable puzzle piece. You're the other puzzle piece. Since the-next-great-thing puzzle piece is perfect and immutable - you have to change yourself, your team, your family, etc., to make the fit work. The human nature response to this is to resist. Not because of the old saying that "change is hard". People resist because deep down, we all know that there is no silver bullet and the-next-great-thing isn't perfect - it goes against human intuition. Also, the more you ask someone to change, the more benefit that person should see from having made the change.
Coming back to Agile, the people being asked to change are the developers and the first and second level managers - and no matter how much you polish it, they will see the change to Agile as a net loss for them. However, the VP R&D didn't have to change at all - all s/he had to do was say, "we're an Agile shop now" - and s/he and the company get all the benefits.
so - what to do?
I wish I had a magical answer here - but I don't. And you wouldn't believe me if I said I did, since I just made the case that there is no silver bullet process.
What I will say is this: to be a great manager, director, or VP, you have to resist falling prey to the-next-great-process - especially ones that come with a "tampering voids warranty" disclaimer. Great products come from great people - not process. You simply can't invest heavily enough in your people - and I'll be honest, molding great developers/managers is a lot of work - but it always pays off.
As for process, I say tear off the "tampering voids warranty" tag and see what happens. Trust your team to come up with variations on the process, and let it evolve. Remember: the most important aspect of the process you choose is that it brings benefit to people you're asking to change.
Agile was infuriating for me. Weirdly, I think that it was less because of my proclivity against meetings (though certainly, I despise being in meetings as often as it requires), and more because people would incessantly hijack it for their own nefarious purposes. I don't think I got through a single stand-up where I felt like people were "on-point", and iteration planning was invariably like pulling teeth because someone would refuse to just do the planning, instead distracting everyone for hours with minutiae that THEY thought were important. Rough.
ReplyDeleteTotally valid point. I mean, really, I totally agree - I've gone through the same things you describe. Although, it's hard to blame Agile entirely. Agile brings a lot of new meetings into your R&D group's life... if your R&D team isn't good at keeping meetings on point, having clear goals for every meeting, that's a different issue. I'd wager few R&D teams are good at having meetings - Agile just magnifies this point. In some ways, this is a topic unto itself - a very important one - the art of having relevant meetings. A difficult, but important subject - too complex to discuss in a reply. Cheers.
ReplyDelete