Introducing the concept of Agile Tactics, and a practice called Focus Mapping.
AgileByExample 2017 invited me to Warsaw to talk about my experiences with leading and being a part of agile transformations from over 15 years. 30 minutes is a good timeframe where you may not ramble too much, yet not risk dumbing down the subject as with lightning talks.
At first, I wanted to talk about the anti-patterns of agile today.
A pet peeve of mine concerns the problem with current agile being filled with extroverted practices and how it often rewards extroverted behavior. This is fine, if you want to create a homogenous workplace where it's considered less valuable to be shy, thoughtful, or introverted. I find such reasoning counterproductive. (This is coincidentally why I often feel out-of-place at agile conferences, which seems filled with extroverted people. But that’s another story)
Yes, I’m introverted, and I prefer to ponder things before I answer. Brainstorming is fun, but I find it more energizing to plunge into a problem myself first, only to discuss different ways forward later with others. But I opted for a different topic this time.
I chose to present my view on the different time spans in an agile organization, and a practice I’ve used for several years to close the gaps between hierarchy levels and roles in a typical organization.
In this first installment, I will explain how and why I created Focus Mapping, and in the second part I will describe the actual session in more detail, and how I facilitate it.
Defining multiple layers of decision-making
In the late 2000’s, I encountered several situations where a huge disconnect between the long-term strategic planning and the teams sprint planning existed, often impeding effective work.No real attention was being paid to ways for bringing these closer together. Instead, alignment was deferred to the product owner, who would use things such as scrum of scrums to align efforts. I experimented with adding on a forecasting event to sprint planning, and most times, three months turned out to be a good starting point. Also, I found skilled individuals who needed to operate between teams and over multiple sprints, to use their expertise in the best way.
When experimenting, I learned two things:
- Teams should do this. Not product owners, project leaders, or even worse, ScrumMasters.
- The result needs to illustrate how teams perceive they need to spend their focus (or capacity) to reach goals, not the goals themselves.
Hence, I chose the name Focus Mapping for the session itself, and Focus Map for the resulting map which becomes a forecast of how teams will need to interact and focus their efforts over the upcoming months.
(Initially, I called this session Tetris Planning. This was inspired by a session where teams surprised me by cutting out ”tetris blocks” of colored paper to illustrate the overlap and dependencies between their teams. In the end, I went with Focus mapping as it better illustrates the purpose. Also, I don’t want to upset Russians that grew up in the 80’s)
I started referring to the long-term forecasting and decision-making as the strategic level, the team's daily and sprint planning as the operational level, and the new three-month forecast thus became the tactical level.
Building the Tactical Level
I suggest that the agile tactical level is a fairly new idea and used to only exist as story hierarchies on the product backlog. The tactical level visualizes design decisions, dependencies and effort management up to three months ahead. It provides a common playfield for business owners and teams to meet when discussing progress and capacity tradeoffs and offers a space for people operating on a tactical timeframe.
Teams and stakeholders meet on the tactical level to agree on how they will spend their upcoming focus and capacity to reach the overall goals. They coordinate and resolve dependencies, and make tactical judgements and decisions to create realistic forecasts. Visualizing the tactical level also makes it easier to add advanced project management techniques such as Critical Path and Critical Chain if needed.
The tactical level provides a natural place to integrate multiple ways of working. Some teams may use Kanban, others Scrum or a mix of both, yet another team use waterfall, because they have close to no variability in their work. Some teams estimate in points, others in days and hours. They can all integrate their respective cadences and forecasting methods on the tactical level.
Focus Mapping is performed monthly, thus creating a sliding window of three months forecast. But the outcome is not as important as the resulting discussions and alignment of views and expectations during the session. To illustrate my point, let's bring up a few of the benefits I have observed:
Focus Mapping creates a pull from the long-term, strategic level
To forecast their work, teams need strategic items of a size they can pull into a tactical forecast. Epics can often be estimated, but prove difficult to plan. They need to be refined to a level where they can be pulled into the forecast. This rewards continuous preparation and refinement, which often result in research or pre-planning events being forecasted to refine and increase our understanding of certain epics.Focus Mapping creates a pull from the short-term, operational level
The Focus Map becomes a playfield that communicates:- All critical paths towards bigger releases (i.e. ”never disturb a team who works on orange stories”)
- Dependencies and bottlenecks, and how teams envision they will resolve them
- How teams manage WIP
- The consequences of introducing bigger change, or a new big story
- The next good opportunity to start new efforts
Focus Mapping creates a window where the strategic and operational levels meet, and can glimpse into each other’s reality
This may surprise you, but by engaging together in an envoy to map out dependencies and efforts, the environment each layer has to operate in becomes visible to each other. The effects may be surprising, and memorable.At ABE17, I was approached by a gentleman who asked me this very insightful question:
When agile teams realize to their horror that the strategic business environment is being based on the concept of waterfall - what do you do?In fact, I've experienced this several times.
Spoiler alert: If you’re operating in a business where deadlines are crucial, this often holds true, no matter how agile your teams are (and how much your agile coaches are waving their fists angrily at the clouds). (This is also where you need to add more powerful estimation and simulation efforts to your forecasting, but that’s the topic for another article)
It may also come as a surprise to your business owners you are operating on forecasts and assumptions to some extent, and that it might be necessary to learn as you go sometimes. I have had wide-eyed business owners shout ”BUT I THOUGHT YOU WERE ENGINEERS” when they realized some of the efforts offered no better forecasting quality than the sales predictions of entering a new market. (So that’s what the ’R’ in ’R&D’ stands for)
By exposing each other to the realities of their operating conditions, we come to the last benefit I want to talk about:
Viewing multiple time frames for decision-making allows for people to work on multiple levels
When discussing this for the first time, a few people argued I ”reinforced traditional hierarchy”. Now, I have nothing against hierarchy per se, but it's important to understand that the three levels I describe should not be confused with people hierarchy - these are three different levels of time perspectives, and teams and individuals may operate on one or several of these levels as needed.Some thrive in the operational level, making agile adjustments and navigating fast decisions. Others are invested in the long-term strategy and where the business is moving. Some work in teams but help with decisions on every level due to their interest and understanding of the entire business, etc.
What about release trains?
Release trains, as described by SAFe, stems from a similar idea, to create a way for multiple teams to deal with a portfolio of work and manage their WIP. They also seem to stir up a lot of emotions. Perhaps because they may appear as a rigid and final way of doing things, but I don’t know. I first read about release trains around the same time as I was working with Focus Mapping. From working with several release train sessions, I would list the main differences as:- Focus Mapping is a starting point, to suggest and reward different behaviors to the organization through practice. It often evolves into other tools and adjusted timeframes once the way of working matures
- Release trains seem to reward a behavior that promotes big refinement and planning efforts quarterly instead of continuously. When I see SAFe efforts, I often see business owners huddling together shortly before each release train planning to bring backlogs and roadmaps up to shape. Sometimes they try to cram in refinement efforts in sprints near the end of the train. (Yes, it’s not meant to be that way, but we’re only human)
- Most organizations shorten the two-day release train planning out of fatigue. As Focus Mapping happens monthly, it runs smoother and use less time
- SAFe also seems to impose (again, not necessarily by design, but by spurring a behavior) a cadence of quarterly releases, which is fine in some businesses, but problematic in other
- Release Train Planning often creates a board of achievements. Focus Mapping creates a board of focus areas.
LESS basically just says ”throw more Scrum at the problem”. So I have found no evidence suggesting this practice would not work with either framework.
Remember: Methods are not as important as the behaviors they reward. If someone tells you otherwise, you need to find a different (agile) coach. We are in a realm where no single best practice, but several good practices exist. Try, inspect and adapt.
But… adding more planning still doesn't sound agile?
A few people suggested this looks like you would lapse back into waterfall, big planning up front type of work. If you would detail all work over three months, we would create potential waste. But to add as little overhead as possible, we project the larger items on the later iterations, visualizing and dealing with the capacity and dependency demands they seem to instill. I provide smaller physical planning size on the boards for the upcoming months compared to the current month which always seems to do the trick. Also, we use the term “forecasting” to emphasize that this is our idea on how we might have to organize work in a month or two, but it's likely to change!Why not remove the levels completely?
I suspect the Holacracy crowd has left by now, but if you’re still around, hear me out. You will still have to make decisions, assumptions and forecasts that span over multiple time periods in most organizations, and it doesn’t matter how you are organized. Focus Mapping brings people together to figure out how to deal with upcoming challenges. It does not matter how you are organized, although if your organization forbids people from working with decisions and forecasts on multiple levels, you will be less agile.Also, if people often bring up a similar need, why not address it? Perhaps this leads to new ways of collaborating.