Over the past decade, there has been a ton of ink spilled over Agile development. Much of the Agile narrative has focused on the pros of implementing Agile methodologies, such as better planning, faster feedback, and the ability to quickly pivot and make changes. These are all good things. However, from a Product Management standpoint, Agile has some major problem areas that can create inefficiency at best, or completely wreck a project at worst.
Before we continue, I want to be clear: I love Agile. The teams I have managed and worked as a part of have delivered lots of user stories and requirements to Agile teams and seen success. Agile can be wonderful. In my travels over the past four years as a Pragmatic Marketing Instructor, I’ve also witnessed several “Agile traps” that jump up and grab teams.
1) Agile makes it harder to be disciplined with regard to strategy
Because of the nature of Agile, multiple sprints happen every two to four weeks. Organizationally, we now have the ability to change direction more quickly than ever before. This can be helpful to react to changing market conditions (or the needs of big deals).
Unfortunately, this ability to quickly change is a double edged sword. Because we can change direction quickly doesn’t always mean that we should. I often see Agile teams building half-solutions to dozens of problems instead of actually fully solving anything, because they are flipping from solving one problem to the next one too quickly. Agile requires extra discipline to stick to the strategy when it’s tempting to continuously change direction.
2) Agile values feedback from customers (sort of)
Agilistas would say that they strongly value getting constant market feedback at the end of every sprint. That’s good. In my experience, what actually happens is that most teams recruit four to five customers who are willing to provide that level of constant feedback and then roll with them – for the rest of the release or even multiple releases.
Going back to the same customers for feedback creates a two-fold problem. First, do those four to five customers really represent your overall market segment? Or, are they the “noisy 20%” of your market segment? In my experience, the types of customers who are willing to sign up for regular meetings to provide feedback every other week don’t typically represent average users; they represent power users and experts.
Second, customers aren’t dumb. Soon, those four to five customers figure out that they have a disproportionate amount of influence on your direction, and realize that their feedback can turn you into essentially a custom development shop for their particular needs – again, that’s not market driven, that’s customer driven.
3) Agile’s roles can actually prevent you from being market driven
When teams implement Agile, they often look to create new roles. Specifically, the “Product Owner” role is one that is often tasked to Product Management.
Unfortunately, the Product Owner role is extremely noisy and tactical and requires a lot of day-to-day interaction with Development in daily standups, sprint planning sessions, and retrospectives. While there is nothing wrong with making the Agile team run efficiently, I have seen teams get so obsessed with “making Agile work” that they start sacrificing what Product Management really should be doing – which is spending time with the market.
I speak to Product Team members every week who are doing the Product Owner role, and they all tell me that 95-99% of their time is spent on internally facing Development activities, and they rarely, if ever, speak to anyone in their market. That’s not a recipe for being market driven.
4) Agile helps us run faster, but are we running in the right direction?
Agile’s big promise is that it will help us run faster in Development (or whatever), but it doesn’t say anything about if we are building the right thing to begin with. That is the role of Product Management to find out. I see Agile teams often getting so obsessed with the machinations of Agile that they forget that you can be the most efficient company in the world, but if you’re building something that no one wants, it’s pointless.
How is your team using Agile today? Are you running into any of these issues, or others? Please share your experiences in the comments section.