I’ve been speaking with several possible clients. They’re having trouble with Scrum. The managers don’t believe the teams need product owners, so the teams don’t have POs. The managers think a Scrum Master can support at least four teams.
The teams start a lot and finish very little. The teams think they have too many meetings. And everyone works alone—the teams collaborate very little.
What’s wrong? (Aside from everything??)
The managers (often with the assistance of a consultancy) decided Scrum was the answer. However, the managers didn’t define the problem(s) they want to solve.
They started with how—and the answer was Scrum. Scrum is a useful framework as long as you use the framework. Scrum is not the problem. (I’m not sure it’s right for some of the teams, but they could make it work.)
The problem is this: No one defined the necessary why—the business outcomes they want. Those outcomes can help teams decide which agile approach(es) to start with and adapt.
Let’s start with who wants the teams to use an agile approach.
Who Wants the Teams to Use an Agile Approach?
Even back in my early days of teaching and consulting about project management, teams decided on their own approach to their project. I explained how various lifecycles worked and when it made sense to consider which approach.
Before I had the “agile” word, I discussed iterating over feature sets and delivering small increments. I discussed rolling wave planning and how you could inform the next bit of work from what you’d done before.
Often, the managers were in the room. The teams and their managers had vigorous discussions about when to use which approach.
One of the best outcomes? No one left my workshop or consulting thinking they had the One Right Way to approach all projects. When I left, they all understood how to decide how to make tradeoffs.
That’s not what I see now. Way too often, someone who’s not part of the team decides the team will use an agile approach. More importantly, the people outside the team decide which agile approach teams will use.
I don’t find mandates all that helpful. I do like to understand the business reasons for an agile approach. Those business reasons define the why.
Why Does Your Team Want an Agile Approach?
If your team can decide on its own agile approach, terrific. Even if your managers decide you need to use an agile approach, that might be okay. As long as they explain why.
I’ve seen these whys:
- The team wants to create a more collaborative environment. Agile approaches limit WIP (Work in Progress), which teams can use as a forcing function for more collaboration.
- Product people want to experiment and get feedback from users/customers more often.
- Managers want to be able to change their minds about the project portfolio more often.
All fine reasons. You might have other reasons. Read Define Your Agile Success for more ideas.
And when the teams decide on their own agile approach, that’s terrific.
I’ve seen other reasons managers want an agile approach:
- Stabilize “velocity” for all teams. (No, No, No.)
- Synchronize everyone on the same release date and time. (Possibly a good idea, as long as you don’t slow down the faster teams.)
- Save money. (You can save money faster by reducing the overall number of projects in the project portfolio.)
- Managers think agility is about squeezing more work out of the teams. (Oh, please. No.)
Notice that none of these reasons support an overarching goal.
Define the Overarching Goal for an Agile Approach
I’ve seen these terrific overarching goals for moving to an agile approach:
- More innovation to experiment more.
- Faster releases to see customers’ reactions and possibly gain more revenue.
- Experiment with alternative customers and customer segments.
You might have more reasons, such as to enable subscription payments for your products. One big yearly release doesn’t work well with subscriptions.
If you know your why, the teams can decide on the how.
When someone outside the team decides how, they remove the team’s autonomy, mastery, and purpose. Those people exercise their power to decide. They’re not offering a purpose, an overarching goal for the team. (See Practical Ways to Lead an Innovative Organization for this and related problems and my recommendations.)
Which is how these teams get to insufficient numbers of Scrum Masters, no product owners, and team comparison based on velocity. That’s not even cargo cult Scrum—that’s not Scrum at all.
What can you do? Start with the real problems.
What Problems Do Managers Want to Solve?
When I ask managers why they want to use an agile approach, I often start with this question:
What business outcomes do you want?
Then I stop talking. I ask people to write their reasons down on either physical or virtual stickies.
They’ll talk about outages, quality, defects, time to market, all kinds of things. Sometimes, they even talk about the customers they want vs the customers they have.
Managers aren’t stupid. IME, they know the problems they want to solve.
Then, I ask them to read the Scrum Guide (17 pages) and the Kanban Guide (9 pages). I often ask them to read the guides in our meeting. So yes, we take a little time to read. I ask them if they have questions about the guides, and I answer those questions.
Then I ask these questions:
- Do you want to use Scrum to achieve those outcomes?
- Do you want to use kanban to achieve those outcomes?
- What are you willing to commit to, to achieve those business outcomes?
The managers now realize they need to commit to an agile approach to achieve those business outcomes. That means a PO and a Scrum Master for each team in Scrum. (Not what the clients had done at the top of this post.)
What if they don’t want either of these (or a combination of) agile approaches? I discuss the various lifecycles and what they can expect from each of those lifecycles.
That’s why we need to define and discuss business outcomes.
I don’t care what they choose. I prefer if the teams choose, but some management teams are unable to let the feature/product/project teams choose for themselves.
Business Outcomes Drive the Why
That’s why the “why”—the business outcomes—matter much more than an agile approach.
I’ve discussed scarcity before, as in Don’t Start a Project with Scarcity. I mean it. It’s the same with your agile approach. If you can’t commit to an agile approach, don’t start it. Figure out what you can commit to, and start there.
If you want to use an agile approach, read Create Your Successful Agile Project. If you think you don’t need an agile approach, but prefer something other than waterfall, read Manage It! Your Guide to Modern, Pragmatic Project Management in addition to the lifecycle series.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Want a Successful Agile Project? Start with Why Before How Opinions expressed by Java Code Geeks contributors are their own. |
