Agile development methodologies succeed because they help development teams be as effective as possible. Development teams do not, however, work in complete isolation. The company they work for has a strategy. The company manages a portfolio of products, and targets a particular product at specific market problems. Within that context, an agile team can thrive. What’s the best way to provide that context?
Agile Development in Context
Mike Cohn of Mountain Goat Software gave a presentation to the bayXP group in March 2007 on agile estimation and planning (video and pdf at link). As part of setting the stage for his planning presentation, he describes the software development ecosystem as an onion. So did I, coincidentally, in 2006. The gist of both onions is that software development is implementation, in the context of design, driven by requirements, formed to address market opportunities. Mike’s onion provides specific insights into the execution approach of an agile team, so let’s frame this conversation using his terms (but a new visual).
- A company has a strategy. [Example: “Organize the world’s information…”]
- A company has a portfolio of products that is intended to provide a mechanism by which the company can achieve its strategy. [Example: Gmail, Chrome, Gears, Reader, Docs, etc.]
- Each product (or service) the company creates is an intentional part of the portfolio, targeted at specific markets or market segments, with an intention to solve specific problems. [Example: Gears allows people to consume online content when offline.]
- A product is delivered through a series of releases. [Example: Chrome release 0.2.149.30.]
- The work that goes into a release, when practicing incremental development, may be decomposed into multiple iterations. [Example: Chrome iteration 0.2.149.29, not released, but built and tested]
- In scrum, the completion of tasks within an iteration are managed daily. [Example: Today, I will add the ‘check for updates’ to the ‘About Chrome’ popup.]
Many people talk about the agile process as if it encompassed the entire perspective shown above. It doesn’t. When you talk about the software development lifecycle from the strategy level down, you’re really talking about business strategy. Agile development happens in the context of a business strategy, a product portfolio designed to achieve those strategic goals, and the product in that portfolio that is being developed.
Saeed Khan puts it pretty well in his first article about agile / scrum:
Keep in mind, Agile/Scrum is a DEVELOPMENT methodology. It is a great model for developers and engineers and other R&D team members to work and communicate more efficiently. There are very clear benefits to this model. It provides greater visibility into current work status, work remaining, can identify development hurdles earlier and can communicate them outward more easily.
I agree with Saeed. In the diagram above, the layers that represent “what we do” have black text and borders (Strategy, Portfolio, and Product). The layers that represent “how we do it” have white text and borders (Release, Iteration, Daily). In Mike Cohn’s presentation on agile planning, he specifically calls out that agile planning happens in this (inner) scope.
Managing a product backlog (in scrum) is the place where things blur a little. Determining what goes into the product backlog is “what we do”, prioritizing those product backlog items is “when do we do it”, and fitting them into individual releases (timeboxes and rolling-wave planning) is “how we do it.” As agile teams stress, communication here is the key.
The true challenge that companies face is to provide agile development teams with the context needed to develop software.
Providing Context to Agile Teams
Product management is primarily a strategic activity, combining market insights () with company strategy to design a product portfolio, and to determine which problems a particular product should solve, for a particular market segment. This leads to a focus on buyer personas and user personas.
Establishing and maintaining the connection between market insights and agile development teams will develop a distinctive competence for your company. One key is to connect stakeholder goals with implementation activities. This involves translation from the language of business to the language of developers.
An effective bridge across that communication divide has to be visceral and very straightforward. Many agile team members rail against anything that looks like overhead, and the manifesto even codifies this disposition – “working software over comprehensive documentation.”
Our magic decoder ring must be simple, explicit, and light-weight. Sounds like a job for the Ishikawa diagram.
Ishikawa Diagrams for Agile Product Management
The Ishikawa diagram, also known as a cause-and-effect diagram or as a fishbone diagram, can be used to describe and decompose market problems. Consider the following near-real-world example:
You’re developing a product for sales reps. The key to your product’s success is user adoption, and you believe the way to get that adoption is by helping sales reps to maximize their compensation. Sales reps are generally managed via commission-based compensation models. You establish “Maximize Sales Compensation” as a goal for your software (for these users, in this market segment). You then acknowledge that there are a series of “smaller” problems that have to be solved before sales reps actually can maximize their compensation. An Ishikawa diagram of your results would look like the following (consider only the main branches):
For some problems (and some teams!) this may be enough information to provide the context to develop a product backlog. And your agile team will move forward into managing their own execution from the product backlog stage. For larger or more complex problems (such as this example), you will need more detailed communication before diving into user stories / use cases.
The same Ishikawa diagram, with more detail, looks like the following:
For the largest and most complex problems, this is still not enough. You can take each major branch of the Ishikawa diagram and create a child Ishikawa diagram. However, from an agile standpoint (as in “staying close to your market”), you don’t want to do all of that detailed analysis up front. Once you’ve prioritized the main branches in your main Ishikawa diagram, you will want to go to the next level of detail only for the first branch. You want to make sure that you are delivering “working software” – not “comprehensive documentation.” Delay your detailed analysis to the last practical moment.
Assuming you chose “Improve Predictability of Sales” as the first market problem to address with your product. And within that choice, you are going to tackle “Align Solutions to Customer Problems” first. Your child Ishikawa diagram could look like the following:
At this point, you would start writing user stories (or defining use cases) around recording customer problems, searching for ‘comparable problems’, predicting the problems a customer might face (before your first sales call), etc. Those user stories will then get mapped to releases and iterations, and their implementation will be managed through the daily standups.
Outbound Communication of Agile Delivery
This problem-decomposition approach was presented top-down, specifically around providing the needed context to an agile development team to guide their design and implementation activities, giving them the opportunity to intentionally solve valuable problems, in alignment with the company’s strategy.
This same approach can be leveraged in outbound communication of what the team will deliver (and when). You can easily construct a product roadmap that is actually an “agile problem roadmap.” [Ed: can I trademark that? Probably not, since Enthiosys already does it, but without the word problem.] In the short term, talk about specific problems (“Align Solutions to Customer Problems”) that you are solving. In the longer range plan, talk about the next level of problems (“Improve Predictability of Sales”). The team is not committing to a widget or feature. The team is committing to providing a solution to a particular problem in a given release.
When you commit to a particular feature, you inhibit your ability to change as you learn. And that’s bad. You need to be able (after each iteration) to say “This problem is still valuable, but our previous idea about how to solve it turned out to be a bad idea.” If you communicate at the feature level, you’ve added overhead to your process – you now have to manage expectations and update your communications, EVERY time you change designs.
You introduce another problem – these Ishikawa diagrams are so easy to read, and you’re now managing your roadmap based on problems being solved in a given iteration/release – should you tell everyone? Many product managers sidestep the “Do we make our roadmap public?” question because they don’t create an easy to consume roadmap. With this approach, you do. So you have to decide if it needs to be a secret.
Zero-Overhead Planning
Early in this article, I said “agile team members rail against anything that looks like overhead.” Creating Ishikawa diagrams is zero-overhead. Or nearly so. 99% of the work that is displayed through the Ishikawa is work that you have to do anyway, to have an intentional approach to product creation. The only overhead that is introduced is in the creation of the Ishikawa diagram. If your thoughts aren’t already organized this way, you’re in trouble. It takes almost no time to create the diagram that reflects what you should already be thinking.
And that qualifies as low-overhead. And high value. That should win over any resistance from the team.
Conclusion
As a product manager, you have to synthesize market problems, and develop a product vision to solve those problems that is aligned with your strategy. As someone who is “part of” or “working with” (whichever matches your situation) an agile development team, you need a way to provide context to your implementation team. That context can easily be conveyed with an Ishikawa diagram, with almost no incremental effort. Your team can easily consume the diagram, and it gives them the freedom to explore different solution designs. It also enables you to communicate your plans with the rest of the company (and externally, if desired).
My favorite quote from this article: “Delay your detailed analysis to the last practical moment.”
It’s the inflection point between my competeing tendencies to over analyze (as an engineer) and to procrastinate (as a lazy person).