In her work, Johanna Rothman emphasizes the critical role of feedback loops in managing project risks and the need for adopting release strategies that align with the problem's nature and organizational culture.
What risks does your project have?
Do you need feedback loops so you can:
- Cancel the project at any time (to manage schedule and cost risks.
- Assess technical risks so you can rework the architecture or design to manage feature set risks.
- Manage what you release to customers so you can manage defect, feature set, schedule, and cost risks.
Maybe you want to use this project as a way to integrate a team into a new product or a new domain.
Or, maybe you have a work environment that you think isn't quite right for the risks you have. You'd like to experiment.
Project lifecycles and cultures manage all those risks. When you assess your risks and need for feedback, you can decide which approaches might work for this project, for now. And, you can decide if you want to try to change the culture.
Let's start with the number of internal or external releases you need or want.
How Many Releases Do You Want?
Frequent releasing offers us feedback in many ways:
- Know that we're solving the right problem.
- Verify the customer understands the solution.
- Uncover or discover dependencies we didn't know about before.
Frequent releases help us manage risk with shorter feedback loops.
However, you might not need frequent releases. Or, you might only need informal demos to show people where you are.
It all depends on the kind of problem you're solving right now.
What Kind of Problem Are You Solving?
Teams solve all kinds of problems.
Let's start with a known problem. Here's an example: you solved this problem in a previous patch, and now it's time to port that solution to the main. The solution will be different for this codebase. However, you know what tests you need. You understand the problem you need to solve and what the solution needs to look like.
That's a totally deterministic problem. You don't need to discover the solution. You might have to experiment to make sure that the solution works, but you have minimum discovery. You're at the left side of the problem determinism continuum.
Solving Deterministic Problems Does Not Require an Agile Approach
What if you're trying to fix a nasty escaped defect? You probably aren't at the very left part of the problem continuum. That's because these problems aren't straightforward and often include constraints:
- Substantial date urgency because the customers are angry.
- How to fit the solution into the current architecture or design.
- Options for a later, more fully complete solution.
- Anything else about the current product that affects your solution.
As a team, you might show each other your work as you complete it. You might show other people internal demos.
When the team shows itself their work, they learn together and reduce the risks of not solving the problem.
When the team shows other internal people demos, the team invites trust and greater learning.
However, you might not release interim work until you've fully tested your solution.
Why not? Because the risk of further alienating the customer is too high.
From the outside, when teams fix escaped defects, the lifecycle looks like a serial lifecycle. However, it's probable more iterative and incremental. (Iterate on prototypes, increment small pieces of value.)
From the customer's perspective, it's a serial lifecycle. One release at the end, as a completed product.
I don't see many of these kinds of problems. Most of the time, I see less-deterministic problems. Those problems require more customer feedback to know if and when we have a reasonable solution.
Non-Deterministic Problems Require More Feedback to Solve
Let's take the intersection of a problem that requires more feedback and the constraints of the project pyramid. (You might want to read the project boundaries series to see what I mean.)
I think of feedback in these ways:
- Real customer feedback.
- Proxy customer feedback, such as from a product manager or product owner who's not checking with the customer.
- Management feedback.
The more management wants “all” of it, “now,” for “no” cost and “no defects,” the more risks you have. Add in the problem complexity, and you have a project full of risks. (The most useful projects have lots of risks.)
That's where you'll want to consider how much you need to iterate on the team's learning.
What if you need more customer feedback? You'll want some number of interim releases. And, you might need both, which is why many projects use some sort of iterative and incremental (but not agile) lifecycles.
And, if management wants to be able to change what the team does frequently, you need an agile approach, with the requisite culture changes.
You don't have to change your culture to use any lifecycle. However, there are many times when you do want an agile approach.
Feedback Depends on Getting to Done (Added after I published)
The more risk you have in your project, the more feedback you need. And, all feedback depends on getting to done. (See Part 6.) I mean done as in “ship to customer” done. Your team might not be able to release by yourselves. That's a problem you'll need to solve.
If you can't get to done, you can't get feedback. That's why we need to :
- Implement small features through the architecture (not across)
- Refactor as we need to make small changes
- Test in all possible ways to verify we haven't made changes we didn't want
The faster you want feedback, the more you might want an agile approach.
Why You Might Want an Agile Approach
A real agile approach will offer you substantial benefits in the form of shorter feedback loops. The shorter the feedback loop, the easier it is to assess the project's progress and risks.
And, in most organizations, I do find that an agile culture at the team level can help the organization move to a more agile culture across the organization. That said, I have never seen a successful agile transformation start at the team level and permeate management.
Why? An agile culture “attacks” the people's networks and their rewards. We (for lack of a better word) democratize the organization when teams become self-managing. I've written about changing management's compensation from being responsible for deliverables to fostering a great environment. See Management Rewards: Doing Work vs Creating an Environment.
That said, if you have an organization of fewer than 99 people, you might be able to start at the team level and create an organization-wide agile culture. I have yet to see this approach succeed, but maybe you can prove me wrong.
Select a Lifecycle That Fits Your Culture and Risks
I've explained the various approaches in this (too long!) series.
Maybe you need to experiment more with prototypes? Or, with iterating over feature sets? In that case, consider the various iterative approaches in Part 2.
If you need more than one release, consider starting with the incremental lifecycles in Part 3 or the iterative and incremental lifecycles in Part 4.
Any time you release more often, you have more agility with the project portfolio, which might be all your organization needs.
Regardless of your lifecycle, remember that technical excellence, especially with sufficient test automation makes everything much easier.
What if you really want to use an agile approach, knowing that approach will change your project culture? And, that to sustain that approach, you will need to change your company's culture, especially around compensation?
My suggestions:
- Start with principles, not a framework. In fact, start learning about agile and lean principles as a team. Set aside a little time every day for a week to learn and discuss.
- Decide—for now—if you will use iterations or flow. (Read Create Your Successful Agile Project for much more detail than I've offered here.) Make sure you create a board in a shared spreadsheet rather than a tool. Tools lock you into their way of working and you might not know enough yet to know what you need.
- Measure your cycle time. That single measure helps you see where you have bottlenecks and queues. You'll need other measures, but that's a good start.
- Read Esther Derby's 7 Rules for Positive, Productive Change: Micro Shifts, Macro Results.
- Reflect and refine your approach, using double-loop learning.
I hope you found this series helpful.
Register on November 30th, as Johanna Rothman, the "Pragmatic" Manager, goes into detail of this article through an interactive workshop.
