Excessive Analysis and Planning

Regular big up-front analysis and planning is not necessary with Scrum. Instead, just get started and use constant feedback in the Sprint Review to adjust the team’s plans. Create the product backlog after the first Sprint has started!

Starting Work Without Analysis and Planning

All that is really necessary to get started is a Scrum Team, a product vision, and a decision on Sprint length. In this extreme case, the Scrum Team itself would decide what to build in its first Sprint and use the time of the Sprint to also prepare some initial Product Backlog Items. Then, the first Sprint Review would allow stakeholders to provide feedback and further develop the Product Backlog. The empirical nature of Scrum could even allow the Product Owner to emerge from the business stakeholders, rather than being assigned to the team right from the start.

Starting a Sprint without a Product Backlog is not easy, but it can be done. The team has to know at least a little about the business, and there should be some (possibly informal) project or product charter that they are aware of. The team uses this super basic information and decides on their own what to build in their first Sprint. Again, the focus should be on getting something that can be demo-ed (and potentially shippable). The team is likely to build some good stuff and some things that are completely wrong… but the point is to get the Inspect and Adapt cycle started as quickly as possible. Which means of course that they need to have stakeholders (customers, users) actually attend the demo at the end of the Sprint. The Product Owner may or may not even be involved in this first Sprint.

Why Minimize Analysis and Planning?

One important reason this is sometimes a good approach is the culture of “analysis paralysis” that exists in some organizations. In this situation, an organization is unable to do anything because they are so concerned about getting things right. I recently had a coaching client mention that their team had done eight months of analysis and design before starting any Sprints!

Scrum is a framework for inspect and adapt and that can (and does) include the Product Backlog.

Is it better for a team to sit idle while someone tries to do sufficient preparation? Or is it better to get started and inspect and adapt?

These are actually philosophical questions (as well as practical questions). The mindset and philosophy of the Agile Manifesto and Scrum is that trying to produce valuable software is more important that documentation… that individuals and how they work together is more important than rigidly following a process or tool. I will agree that in many cases it is acceptable to do some up-front work, but it should be minimized, particularly when it is preventing people from starting to deliver value. The case of a team getting started without a product backlog is rare… but it can be a great way for a team to help an organization overcome analysis paralysis.

The “Official” Word

The Agile Manifesto is very clear: “The BEST architectures, requirements and designs emerge out of self-organizing teams.” [Emphasis added.]

Hugely memorable for me is the story that Ken Schwaber told in the Scrum Master course that I took from him in 2003. This is a paraphrase of that story:

I [Ken Schwaber] was talking to the CIO of a large IT organization. The CIO told me that his projects last twelve to eighteen months and at the end, he doesn’t get what he needs. I told him, “Scrum can give you what you don’t need in a month.”

I experienced this myself in a profound way just a couple years into my career as an Agile coach and trainer. Ken himself had connected me with a department of a large technology organization. They had over one hundred people who had been working on Agile pilot projects. The department was responsible for a major product and executive management had approved a complete re-write. The product managers and Product Owners had done a lot of work to prepare a product backlog (about 400 items!) that represented all the existing functionality of the product that needed to be re-written.

But, the big question, “what new technology platform do we use for the re-write?” had not yet been resolved. Senior management tasked the small team of architects with making this decision. But they got stuck. They got stuck for three months. Finally, the director of the department, who had learned to trust my advice in other circumstances, asked me, “does Scrum have any techniques for making these kind of architectural decisions?”

I said, “yes, but you probably won’t like what Scrum recommends!”

She said, “actually, we’re pretty desperate. I’ve got over a hundred people effectively sitting idle for the last three months. What does Scrum recommend?”

“Just start. Let the teams figure out the platform as they try to implement functionality.”

She thought for a few seconds. Finally she said, “okay. Come by this Monday and help me launch our first Sprint.”

She announced on Monday that “our Agile consultant says we don’t need to know our platform in order to get started.”

The first Sprint (two weeks long) was pretty chaotic. But, with some coaching and active support of management, they actually delivered a working increment of their product. And decided on the platform to use for the rest of the two-year project.
You must trust your team.

If your organization is spending more than a few days preparing for the start of a project, it is probably suffering from this pitfall. This is the source of great waste and lost opportunity. Use Scrum to rapidly converge on the correct solutions to your business problems instead of wasting person-years of time on analysis and planning.

(This article is a minor update of a previous article called “Pitfall of Scrum: Excessive Preparation/Planning”)