So when does it make sense to customize your agile approach to gain a strategic advantage?
Whenever you have a unique problem to solve that's strategic to your business.
Let's start with a couple of examples.
Example 1: Startup/Small Organization with Few Products
SmallCo has revenue of about $30Million a year. They offer their product in two versions: Pro and Lite. Their customers are the users. (No one buys on behalf of the users.)
SmallCo wants to grow. They can offer a subscription-based revenue model if they figure out how to release something useful almost every week. They want an agile approach, so they started with Scrum.
It didn't take long for them to make changes. The first was not waiting for the end of an iteration to demo or release. They demo'd every week on Wednesday mornings and then they released after the demo.
As they start to release weekly, they notice two things: they really needed to improve their security and performance capabilities. As part of the product development, they spin off security and performance teams. Those teams do what SmallCo calls “Advanced R&D” (AR&D).
As AR&D work, they realize they need to experiment in short feedback cycles. The Security team needs to react to immediate threats. The Performance teams wants to create faster experiments. Both teams don't want to get too out-of-sync with the other teams. AR&D both decide to use kanban to see their bottlenecks and decide when to queue their experiments.
Some of the regular product teams figured out one-day stories. Others mob. Most of the teams limit their team-based WIP (Work in Progress). They dropped several pieces of Scrum:
- The daily standup
- Estimation
- Planning on a cadence. They plan on demand.
If you ask SmallCo what they do, they say, “Something halfway between Scrum and kanban. We don't think we need to be “religious” about our agile approach as long as we get the benefit. We do what works.”
SmallCo started with a Buy approach. Then, they Built their agile approach based on their needs.
Example 2: Large Organization with a Related Suite of Products
LargerCo offers several SaaS products all in the financial domain. They want to “capture” users from their first checking accounts to wealth management and wealth transfer.
After a back-and-forth for outsourcing and offshoring, LargerCo decided to bring all the product development back onshore. Then they decided that they needed different kinds of teams and to use an agile approach.
LargerCo decided to Buy a well-known framework that was supposed to manage projects, programs, and the project portfolio. They tried to install that framework. After millions of dollars and several years, they dumped it. (The framework was too slow for what they wanted. So were the tools associated with the framework.)
They have vestiges of that framework, as in Scrum for every team, and quarterly planning at all levels. However, the Scrum teams are component teams. The Scrum teams require a lot of coordination and release their work once a month.
The managers like the quarterly planning. Aside from the problems that the teams don't finish everything each quarter, the senior leadership likes the regular cadence of planning and seeing accomplishments.
However, LargerCo is seeing other, scrappy firms encroach on LargerCo's customer base. That's because some of LargerCo's products look “old” to their potential buyers. LargerCo saw some dropoff of those younger buyers. LargerCo thinks they can't afford to lose those
It was time to adapt their agile approach (Build).
How LargerCo Use Build to Adapt Their Agile Approach
The managers defined their “why”: release updates and features at least once every two weeks. That requires the teams change how they worked:
- Collaborate more.
- Ask the component teams to create slices so they can release internally more often.
- Move to feature teams instead of component teams.
Who would make these decisions? In the framework days, the managers decided for the teams. This time, they told the teams the results they wanted (release something useful at least once every two weeks). The teams decided.
I wish I could tell you they took all my advice. Nope. Some teams remained component teams and used the slicing ideas to release something internally two or three times a week. Other teams chose to work off a common backlog (the more collaboration option). Only four teams moved to feature teams.
They no longer do large-room planning because the teams create smaller stories. In addition, the product managers use rolling wave, deliverable-based planning so the teams can release more often.
The various managers continue to evolve their approaches to the roadmaps and to the project portfolio. (They're experimenting with the ideas in Agile and Lean Program Management and Manage Your Project Portfolio.)
LargerCo continues to Build their agile approach at all levels. Their agile approaches don't “adhere” to any one framework. However, they are able to release value on a regular basis, which is the point of an agile approach.
What About Other Lifecycles?
In the image above, I suggested not everyone needs agility. That's because agile approaches require the organization to change its culture. Not every organization can or wants to change. (See the Lifecycle series or Manage It! to read more about various lifecycles.) You don't have to choose either waterfall or agile—you have many choices. Choose what offers you a strategic advantage for your business.
Agility Offers a Strategic Advantage
Both SmallCo and LargerCo started with Buying their agile approach. Both organizations have modified their approach (Build).
Where's the strategic advantage? Remember, they asked these questions:
- What is our purpose?
- What kinds of problems do we solve for which kinds of customers?
When they answered those questions, they could check the tactical questions and answers. They modified their agile approach to marry their strategic needs to the tactical questions.
However, their tools approach differs from their product development approaches. That's the next post.
The series:
- Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics, Part 1. (Sets the stage for how I think about strategy and tactics)
- Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics, Part 2. (How agility might offer a strategic advantage.)
- Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics, Part 3 (How I think about tools)
- Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics, Part 4 (When we encourage teams to change their tools, we might get more agility)
What you’re saying makes a lot of sense, but I don’t understand the diagram. Lower right looks like it is tactics problems which require unique solutions – is that right?
Yes, that’s correct. You have a (so-far) unique problem. However, that problem does not change your strategy. (I’ve had a difficult time writing these posts. I wonder if my images are hurting or helping.)
I find the images confusing though the narrative is relatively clear. Re: the lower right. You might solve the problem with a custom agile lifecycle (or non-agile lifecycle), So it could be Build – but the choice wouldn’t likely affect anyone beyond the immediate team. So choice of lifecycle is not a major strategic choice – it’s a tactic. Is that what you are getting at? I’m thinking the vertical axis might be similar to “organizational scope” – e.g. how much of the organization is affected by the choice of lifecycle for this particular job.
Thanks. I am sure now, that I need to rethink my images. Oh well. This is why I publish, even if I might be wrong. Feedback!! Thank you.