In Effective Agility Requires Cultural Changes: Part 1, I said that real agile approaches require cultural change to focus on flow efficiency, where we watch the flow of the work, not the people doing tasks. Too few organizations can do that.
Then I offered three suggestions for teams in any lifecycle in Effective Agility: Three Suggestions to Change How You and Your Team Work, Part 2.
What about those cultural changes? Can you create an agile culture for your team even if you can't change how the organization works? (Where the organization rewards resource efficiency, not flow efficiency.)
Not exactly—and you have options. They are:
- Understand the various risks: project, product, and organization, and how to manage those risks with feedback loops.
- Plan for shorter projects.
- Use rolling wave planning to account for new information as the project proceeds.
Let's start with risks and how feedback loops manage those risks.
How Much Feedback Does Your Project Need?
Every effort has risks. And product development has at least these risks:
- Project-based risks, so we can make effective tradeoffs.
- Product-based risks, so we can see how much we need to iterate over feature sets and release increments of value. (See How Product Risks Differ from Project Risks for a brief discussion of those two kinds of risks.)
- In addition, there are the portfolio or organization-based risks, where the leaders and managers want to be able to change the project portfolio more often than the teams can deliver an increment of value.
The faster your team, customers, or managers need feedback, the more you need an iterative and incremental approach.
The image to the left is a date-driven combination lifecycle that iterates over features and offers incremental deliveries.
This is not an agile approach. And it's not a serial lifecycle either.
I used this approach when I had to work with Enterprise Architects or Solution Architects who were supposed to design all the architectures for the product before we started. Instead, we had a candidate architecture which we used to iterate over feature sets and deliver increments of value. That allowed us to manage all kinds of risks:
- We managed project and product risks because we purposefully iterated on the architecture with prototypes.
- While I wouldn't call these releases “frequent,” as in daily, the releases were much more frequent than the company's previous releases.
- And because we did release before the end of the project, we had a “decide what to do” before the end.
- Even better, because the project released frequently, the project portfolio team knew when to expect the end of the project. They did not try to move people or add more features to the project.
This also had the effect of reducing the overall project size/duration.
Plan for Shorter Projects
Plenty of teams realize that once they start a project, they didn't recognize the extent of the work. (Long ago, I wrote When Requirements Spawn Requirements as one example of that.) They need more time to finish “all” the work.
They might be correct, especially if they need just one major release. Instead, imagine if the team split the projects into “Phase 1” and “Phase 2.” Or started adding dot releases, such as .1, .2 and so on.
That's a form of managing WIP. (See? All roads lead to Flow Metrics.)
You don't need an agile approach to reduce the size of a project, but you do need to release regularly. And once you release regularly, you can deliver and demo that often. Consider asking what it would take you to deliver something at least once a month and then retrospect on that work.
That allows teams to use rolling wave planning to inform their next pieces of work.
Use Rolling Wave Planning to Plan Short
I've written a ton about rolling wave planning in my books, but here's a short article so you get the idea: Starting With Rolling Wave Planning.
- Decide on the duration of the wave. I recommend a maximum of four weeks. I prefer two or three weeks.
- Ask the team to collaborate to decide what they—as a team—can deliver first.
- If the team wants to create tasks (insert eye roll here), they can, but only for that one deliverable. No other planning.
Now, everyone monitors their progress. Hopefully, as a collaborative team, but possibly as individuals.
(If you want to read more about rolling wave planning, this is the rolling wave planning tag on my site. And in these books: Manage It!, Agile and Lean Program Management, and Create Your Successful Agile Project.)
Create Effective Agility in Your Team
I don't know of a senior leader who cares about “agile.” But every single one of them cares about being effective and having as much agility as possible. That's why I wrote Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility.
You don't need a perfect agile approach. Do what you can and increase your agility. That will get you a lot farther than an agile death march.