Agile Transitions – Managing Expectations

We live in a day and age where there’s a ton of information and mis-information out there about pretty much every topic imaginable, and Agile development is certainly not immune to this phenomenon.  In fact, anyone who looks for help in pushing through an Agile transformation in their organization is immediately confronted with a vast array of presumptions and preconceptions about what Agile is, why it matters, and most importantly what it delivers.  The simple truth is that the reality of an Agile transformation — both in process and in outcome — is often so very far removed from the myth that we as Product Managers need to be ready, willing, and able to step in and manage the expectations that our stakeholders have about what’s going to happen and what they’re going to get from it.  Here are three very common preconceptions that simply must be squashed for us to lead a successful cultural transformation.

Agile Transitions Go Quickly

The single biggest misconception that I’ve seen across many organizations is the idea that switching to Agile “just happens” and that there’s no real delay in going from one methodology to another.  Nothing could be further from the truth — transitioning to Agile is a cultural change, not merely a process change, and most stakeholders really don’t “get” this until the transition is well underway.  Managers will start asking where the “specs” are, Sales and Marketing will want to know when the “RTM” date is, and your C-level folks will want to see the roadmap for the next 24 months — all of which are common requests under a waterfall approach that go the way of the dinosaur in an Agile environment.  Add on top of that the need to actually train your development teams on how to use whatever tools and processes you’ve adopted to move you forward — while not impacting delivery too much — and you’ve got a long tail of work that’s going to take months if not years to fully establish the culture of agility needed to be successful under any Agile methodology.  Far too many companies start the transition, put the processes in place, then expect the magic to “just work” and everything to go smoothly.  Don’t allow your company to fall into this trap, and don’t listen to any consultant or trainer who tries to convince you that they can have you “fully Agile” in just a few months.  Unless you’re starting from scratch with no clear culture or process, it’s a long slog that has its ups and downs, but strong payoff in the end.

Agile Means We Get More, Faster

The second commonly-spouted bullshit line is that being Agile means that you’ll get more done, faster.  I’m going to go out on a limb and assume that your development and testing teams aren’t lollygagging along, doing the minimum amount of work not to get fired, and generally not being stand-ins for the cast of Office Space.  Assuming that’s true, Agile will not magically make a team that’s already hard-working and focused work any faster or with greater quality than they already are.  What Agile practices do offer is the opportunity to assess, correct, and improve what the team is doing with every single iteration of work that they do.  But this doesn’t happen instantly — as noted before, these improvements take time and commitment from the organization.  If the teams are identifying issues or opportunities to improve, but are blocked from implementing them by politics, policies, or other cultural challenges, then there’s not going to actually be any improvement.  The only way that anything “more” gets done is not simply by being Agile, but by focusing on improvements to your processes, tools, and other aspects of the job that can be optimized for increased delivery with high quality.

Agile is a “Silver Bullet” for Our Other Problems

Building on the two mistaken beliefs above, far too many people think that all they need to do is “be Agile” and all their other problems will go away…

• Do you have quality issues with your software?  Agile won’t fix that.
• Do you have developers who over-engineer every solution?  Agile won’t fix that.
• Do you have managers who are unable or unwilling to hold peoples’ feet to the fire and demand accountability?  Agile won’t fix that.
• Do you have stakeholders who constantly change their minds about what’s important and what’s not, or whether or not they consider something “done”?  Agile won’t fix that.

I can guarantee you that the list of things that Agile won’t fix is far, far longer than the list of things that Agile does fix.  Let’s be honest — if your company is dysfunctional at a very fundamental level, in any way related to or impactful upon your development teams, being Agile will enhance these dysfunctions, not dispose of them.  Contrary to what some people will try to convince you of, mostly because they want to sell you something, there is no silver bullet to solve your dysfunctions.  I literally can’t say that strongly enough — the very first thing that any company that’s successful in their Agile transitions does is stop and ask themselves what they’re actually doing wrong, and then implement pieces of Agile practice that are specifically focused on improving the company’s ability to respond and react to those dysfunctions.  What Agile practices do well is raise these dysfunctions such that they cannot simply be ignored and brushed off, or swept under the rug.  If your teams are doing what they should in their Agile work, everyone should know what the dirty laundry is — if they don’t, then you’re simply not doing it right.