Don’t Skip the Analysis When Moving to Shorter Iterations

In most organizations, the days of multi-year, single release, all-or-nothing waterfall projects have come to an end. Instead, teams (agile, waterfall and everything in between) are trending toward smaller, shorter iterations. They hope smaller iterations will reduce cost, shrink time-to-market and improve quality.

Though speed may seem to get better, unfortunately very few organizations see the expected benefits. In fact, increased costs and huge quality issues seem to be the norm for teams transitioning to shorter iterations.

Why aren’t teams finding benefits in shorter iterations? It’s a lack of analysis!

Shorter iterations (agile or not) seem to add time pressure to all components of a project. As teams try to deliver faster, they take shortcuts—thinking analysis is not needed with such small changes. Many teams mistakenly think the iterations are so small that the solution is understandable without the analysis. They try to work faster and in smaller chunks. Analysis gets lost in the shuffle of shorter iterations.

The time pressure of short iterations causes teams to forego analysis on multiple levels:

• They don’t want to “waste time” outlining the big picture at the beginning of the project.
• They push to solution without understanding user needs and without evaluating multiple options.
• As teams “chunk” the project into tiny iterations, they lose track of the relationships between the whole and the parts.
• As the “chunks” are defined and developed teams forget how the chunks relate to each other.
• Feedback loops between and across iterations do not exist.

When organizations operate without shared understanding of the big picture and the interdependencies between iterations, they miss some really big stuff! Those big misses result in:

• grumpy sponsors, users, CEOs, CIOs
• a huge overwhelming backlog of defects/enhancements/rework
• increased cost
• increased time

We still need analysis! We need the big picture! We need to understand relationships, dependencies, upstream, and downstream. We need to analyze, inputs, outputs, data relationships, user goals, exceptions, business rules, scenarios and data flow—even if we’re agile. We need to move the business forward strategically with every release instead of spending our days beating down the backlog like it is a to-do list.

How do organizations shorten iterations successfully?

On a recent flight, I witnessed great analysis in action. A gentleman sitting in front of me had his laptop open in a way that I could clearly see a requirements spreadsheet on his screen. The spreadsheet listed all of his requirements, traced requirements to releases, and traced requirements to user value points/key functions.

He was working hard on this flight! He built and analyzed graphs showing where releases, requirements and value points intersected, and where defects through various testing phases were impacting releases and the key functions of value. He was slicing and dicing all the data and looking back at process flows to analyze the impacts.

I was so impressed! My primary thought was: “Wow, imagine how much better off organizations would be if they could develop and utilize this type of analysis! We used to do this as BAs on larger projects, but it seems to have been lost in smaller iterations.” What was really cool about this guy’s work—I could tell by the number of releases and the release dates that he was working with smaller iterations. Call me a total BA nerd with how I spend “me time” in flight!

So, here are a few things to keep in mind if your team is one of the many struggling with the transition to shorter iterations:

1. Analysis happens in all phases of a project. Agile projects, waterfall projects, big projects, small projects, ALL projects require analysis. Most projects begin with high-level conceptual analysis and gradually dig deeper as the project evolves. The guy on the airplane, for example, was in the middle of a testing phase – which explains the depth of detail.

2. Chunk outside in. When your team starts defining iterations, be an advocate for slicing and dicing based on user needs and value. Every iteration should deliver value to the user. You should not have iterations that deliver databases or interfaces or protocols. You should have iterations that deliver credit card processing, customer account balance reports, and password change notifications.

If your projects are divided into technical components that are not value focused, be an advocate for cross-team analysis with other projects to identify the user value streams and analyze as a team. If you are using an agile approach with user stories, don’t neglect User Story Maps and many of the old-fashioned analysis techniques to help analyze the data, rule, and process dependencies between user stories.

3. Manage change. Projects need enough up-front, big picture analysis to understand how the users and downstream functions are impacted. So many teams have defaulted to processes that chunk work out in tiny non-value added pieces with no traceability to customer value, solutions or downstream impacts. As the project evolves and changes, no one understands who or what will be affected by changes. This lack of analysis causes a TON of rework and defects (some teams calling them “enhancements”).

4. Evaluate your backlog. If you have a giant backlog of defects & enhancements, you probably have an analysis problem. Analyze the backlog! In many cases, the origin of an enhancement/defect is 5 layers back…the original requirement still has not been met after 5 attempts!

You should be able to locate the source of your analysis problem and make adjustments for future projects. Here are a few tips:

• Take time to trace the enhancements/defects backwards through your process.
• Look at all the items in the backlog and analyze how they are all related.
• Group items that impact the same user groups.
• Group items related to the same processes.
• Analyze the backlog as a whole vs. peeling off each item in isolation.

5. Advocate for analysis time. Our primary goal should always be producing a high-value product for our stakeholders. Sometimes that means we need to educate others about the importance of certain project tasks. Effective analysis minimizes project risk. We need to make time for analysis, or at least do a high-level analysis to show others that more is needed. Use visual models to help others understand why analysis is important. Help the team understand how the right techniques and models make analysis efficient.

6. Analyze while eliciting. Analysis and elicitation go hand in hand. It’s up to us to make sure we are enabling ourselves and stakeholders to analyze requirements as we discuss them. This is done through probing questions, using visual models, and effective facilitation techniques. When we elicit information we must go back and analyze it in order to know what else to ask. Analysis and elicitation are not separate phases, we do them together. For example, we might draw models and pictures while eliciting to get deeper dialog. We analyze as we go, by adding to our visuals and pausing to ask probing questions. We use collaborative elicitation techniques that make our stakeholders pause, think and analyze too.

When it comes down to it, no matter how agile, or how small a release or project is… it still needs proper analysis to get results!

Don’t forget to leave your comments below.