If a lightweight process like Scrum isn’t working, you’re seeing the fragile side of Agile. It’s all too easy to read about Agile development and listen to people like me – I’m an optimist by nature – champion the wonders of Agile development and how it will improve your development universe. While Agile sounds simple on paper, a proper implementation requires a deep understanding, discipline, and organizational support. And even if you get it right initially, it's easy to go astray.
I embrace Agile/Scrum development because I am firmly convinced that it addresses many of the problems that plague software development along with providing working professionals with the autonomy that they should have in the first place. If something isn’t working, most likely it isn’t the process that is at fault. I’d wager that there is an implementation or execution problem.
We’ve implemented Scrum at my company, and we’ve been fairly successful with the basics to date. Unfortunately, I keep hearing and reading about other organizations that are failing on the basics, hindering their successful adoption of Agile/Scrum. This is the classic ScrumBut problem of, “We’re doing Scrum, but…”
- We don’t have a product owner.
- We don’t have a product backlog.
- We don’t bother with daily standup meetings.
- We’re not doing ... some fundamental activity that is and should be a part of the Scrum process.
I’ve witnessed the benefits of Agile/Scrum, seeing teams improve productivity, reduce overtime, and generally enjoy their day. But we have experienced problems as well.
A common problem is that teams will implement the mechanics of Scrum in the context of old habits. In the software world, functional specialties become the focal point: analysts create the requirements, developers develop the software, and QA tests the software once development is “done.”
Functional hand-offs turn Agile projects into a series of “mini-waterfall” efforts – bypassing the collective, collaborative aspects that Agile development brings to the table to boost productivity. The risk with this approach is that the User Stories may be in various stages of completion at the end of the sprint, but aren’t “done done.”
Even when teams are collaborating well, they sometimes take on more work than they should. This problem surfaces in different ways.
- Teams fail to track their velocity – skimping on an important aspect of Scrum – and then continually misjudge their capacity to take on work and end up committing to more User Stories in a sprint than they should.
- Teams start work on too many stories at the beginning of the sprint instead of focusing on the high-priority stories, possibly feeling external pressure to get a set amount of work done in a specific time frame. This again leads to ending with User Stories in various stages of completeness, none of which qualify as finished.
Client: We have identified a list of issues that we need help with. Here’s the list. Can you help us?
Martin: Possibly. Let me look at your list. Who came up with the items on this list?
Client: Me and my direct reports.
Martin: Has the team been involved in putting this list of issues together?
Client: Absolutely not. We asked them to put together a list of issues they were facing and most of the items were related to lack of trust, micro-management, and bad communication so we threw out their list and put this one together for them…
Or this one from an overly-enthusiastic manager:
Client: This Agile thing is great! I’m going to impress the management team with our success.
Martin: How so?
Client: The development team asked me if they could use Agile for their next project and from what I read, Agile can help them improve their performance and reduce the time to market.
Martin: Yes, if it’s done right you may get those benefits.
Client: Wonderful! After I gave them the go ahead to start immediately, I told them I now expected to project to be delivered in 9 months (instead of 18 months) and cut their budget by half…
When it comes to problems with Agile development, people tend to blame the process when in reality the problem(s) are in their implementation and/or support of the process. While it takes more than you realize to fully implement Agile development correctly, the potential that it creates for greater productivity along with aligning development with the business makes in investment worthwhile. It forces you and your organization to contend with the very issues that are preventing you from improving today.