Dan North gave a talk about business mapping at the Scaling Agile for the Enterprise 2016 congress in Brussels, Belgium. This event is hosted by the Agile Consortium International and Unicom and is being covered by InfoQ.
InfoQ interviewed North about the problems that he sees from a business perspective when the IT part of an organization adopts agile, and asked him what business mapping is and how it can help organizations to increase their agility?
InfoQ: Can you elaborate about the problems that you have seen from a business perspective when the IT part of an organization adopts agile?
North: By far the most common case is where the solution has already been agreed, often in some detail, before the delivery organisation even sees it. They try to apply their agile methods anyway, but this just becomes a charade of feature breakdowns, estimation, backlog grooming, and ever more elaborate process. This has earned the name "Water-Scrum-Fall", where either end of the process—the analysis at the front and the release management and transition to live at the back—are still heavyweight processes that do nothing to reduce the time to market.
Because the "agile" process is completely divorced from the business, all they see are more delays. In the old days they could just tap their friendly siloed developer on the shoulder, ask for a feature and wait for it to appear. Now their request goes into a backlog, waits a fortnight to be estimated, gets scheduled into a sprint some months out, and even then it is likely to slip. So ironically their experience of "agile" is slower delivery, more process and overhead, and greater distance from the people doing the work. This is what happens when you take a bag of practises and apply them blindly, without having an understanding of the underlying principles and goals of the approach.
InfoQ: Shouldn’t adopting agile help to bridge the gap between business and IT?
North: This is the frustrating thing. Instead of building bridges this style of IT-only agile adoption drives a wedge between not only IT and the business, but internally between delivery teams and traditional governance roles like project and programme managers.
InfoQ: Can you explain what business mapping is?
North: Business Mapping is an umbrella term for a set of techniques I’ve been developing with Chris Matts, who is a portfolio and product management coach and former business analyst. We worked together at ThoughtWorks over ten years ago—he was my co-conspirator developing BDD—and we’ve stayed in touch ever since. We realised about a year ago we had independently developed very similar models for scaling development. He was working from the portfolio level inwards, with around 1,500 people across hundreds of teams, and I was working at the programme level with around 500 people across tens of teams. Now we both had the other data point we knew these techniques worked at both those scales.
We spent much of last year refining and articulating the various component activities and techniques, which represent a risk-based approach to business agility rather than the more common control-based approaches. Business Mapping applies Theory of Constraints to expose uncertainty and create options for delivery, rather than assuming the constraints and solving for capacity.
InfoQ: How can business mapping help organizations to increase their agility?
North: It starts at the top with Initiative Mapping, which is aligning portfolio-level initiatives with key business drivers. Then within an initiative it uses a process called Demand Mapping to identify and roughly size the work needed to deliver the business capabilities that will enable the initiative. As part of the lightweight scoping exercise the programme team identifies constraints of skills and capabilities. On the people side an exercise called Skills Mapping identifies current and aspirational skills—what can people do and what new skills do they want to learn—which provides the inputs to the constraints problem.
Finally Delivery Mapping is the process of organising the people around the work in a way that optimises for both flow and learning. Depending on which skills are available or needed, work items can be rescheduled or restructured around scarce skills, or people can train and teach one another to balance out anticipated skills shortages. This approach, known as Skills Liquidity, is a novel alternative to traditional resource levelling techniques.
InfoQ: If InfoQ readers want to learn more about business mapping, where can they go?
North: At the moment Chris and I haven’t written up much about this, so our intention is to start documenting it, initially as a leanpub book. There are a couple of iterations of the Demand Mapping overview talk online, and Chris has been talking and writing about Skills Liquidity and Real Options on his blog, TheITRiskManager.wordpress.com. I have a personal backlog of items for my own blog too. I need to write more!
