Your customers can’t take your product more often than once or twice a year. Because the product doesn’t need to leave the building, the teams don’t release internally. Nor do the teams demo on a regular basis. The teams miss the feedback loops so critical for an agile approach. Their agile transformation falls apart.
Rethink Your Definition of Customer
What if we expanded our thinking of “customer”? What if we thought of all these people as customers:
- The various people who buy the product. (You might need a retailer or integrator to deliver your product to the people who use the product. )
- The various people who use the product. (Also known as “end-users.”)
- The developers and testers and anyone else on the product or feature teams. Sometimes, these are other feature teams on a program. (Do you have a good name for these people? Colleagues?)
- The people who fund the product or project. (Also known as stakeholders.)
- The people who are interested in the progress of this project or effort, so they can make decisions about where to fund the next set of features, etc. (Different stakeholders.)
When we think of all these various people as “customers,” we might avoid problems such as these:
- We discover feature problems late in the project because the teams didn’t take the time to automate testing or update their tests.
- We discover product problems—the product doesn’t fit together the way “everyone” expected—because we haven’t looked at it end-to-end. We haven’t released it to see our progress.
- We discover release problems because the teams didn’t practice releasing internally.
I’m not blaming anyone for these problems. Sometimes it’s the product owner’s feature-itis. Sometimes vendors change their environment for delivery and don’t tell the teams. Sometimes, people (stakeholders in particular) think differently about the product because they socialized changes they expected and no one told the teams.
Let’s not discuss blame. Let’s think about how to create agile projects with short feedback loops, not projects that look like waterfall.
Prevent Agile Projects that Look Like Waterfall
Several of my clients had these problems.
They started with feature problems. They decided to fix and test and refix and retest because they didn’t always get the fix right the first time. One client had an FFR (Fault Feedback Ratio) of close to 25% for 6 weeks—a long time to feel stuck.
Once the features worked, they worked on the product problems—how does the product as a whole work. That followed the test/fix loop above.
Now, it was time to do something about releasing. One client hadn’t addressed the slowness of their build system—it took several days and manual intervention to get a clean build that passed the smoke tests. They invested one week and cleaned their build process.
Now, each client had a few-hour build process that worked. It was time for delivering more often.
Their first goal was a monthly deliverable:
- They verified that they could deliver the product every month. They created a build that worked.
- They showed the product internally to all the various stakeholders and other teams.
- They asked for feedback.
Each client needed time and a ton of work to create these monthly deliverables. One only spent two months. The other two needed three months to create a monthly deliverable. However, they saw these results:
- The product management people now see the requirements as they exist. in the product, not in people’s heads.
- For integration products, the vendors also created more interim builds. One team overheard a product manager say, “Your late changes broke our build. That’s not what partners do. You need to deliver interim builds to us at least once a week.”
- Senior managers ask for fewer estimates because they can see the product’s progress.
Everyone learned from these monthly deliverables. The biggest learning might have been that their feature sets were ginormous. Until they reduced the size of the feature sets, they couldn’t get to weekly or more frequent deliverables.
The feedback loops helped the teams create smaller features, which allowed the teams to move to weekly builds and demos.
Now, when the teams say, “That’s a huge feature. What can we deliver this week?” the product managers start to discuss MVPs and even MVEs.
Frequent Deliverables Build Trust
These clients are starting to create culture change with internal deliverables, even though their customers can’t take and don’t want weekly deliverables.
The feature teams now trust each other because they can see each other’s progress. The product people trust the teams to deliver. The various integrators are building more trust with more frequent deliverables. The senior managers who think they need estimates love these weekly deliverables. They can see the teams deliver on a regular basis.
Notice that they started with behavior change—moving to frequent releases—not a process change.
Their agile transformation is working because they’re collaborating internally and releasing internally much more often.
All because they thought differently about customers.
If your end-users can’t take the product more often than a couple of times a year, you can still use agile approaches. Consider changing your definition of customer. Release internally as often as possible and see what happens.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Customers, Internal Delivery, and Trust Opinions expressed by Java Code Geeks contributors are their own. |
