Agile Crisis Management Explained – part 2

This blogpost completes the model that I use to build up a mental image of a new crisis situation when I encounter one. I use it to structure and prioritize the thousands of pieces of new information that I need to process in order to get a good picture of what I’m dealing with. In fact it is a tool to get a fast and useful insight in the current crisis situation that will help me to consolidate all the different inputs into a combined and useful image of what’s going on. This image helps me to communicate with the stakeholders and to define the actions needed.
In my previous post the fundamentals of the model have been explained.
In this post the rest of the mental image usage is described.

figure: Burms temple
Remember the essence of the first blogpost:
A strong temple is built upon solid ground and a strong foundation; likewise a successful project is built upon engaged project members and clear responsibility.
When you want to assess a project, start with investigating engagement and responsibility. To do this, look at two things

• Are ‘change’ and ‘structure’ well balanced? So people have the opportunity to express their engagement.
• Is leadership and responsibility effectively implemented? So people operate in their strength and feel free to do what seems right?

Use the questions above to assess the fundamentals of a solution to any crisis.
Haha! Fundamentals are great, but not everything; So let’s move on!
PART III: THE TEMPLE FLOOR – A working value chain
Have you ever been in a real temple? The first thing that strikes you is the awesomeness of the beautiful floor. It’s that awesome floor that takes your breath away and makes you fall in love with this ancient piece of art The beauty of a successful project lies in the elegant effectiveness of a working valuechain, in two dimensions: the functional product dimension and the dimension of virtual ownership.
Looking at a value chain from a Functional point of view means, you have to get the minimal product working end-2-end. Once this is done, things can only get better.
Creating your mental picture of this area can take some effort. Domain knowledge is helpful, so talk to people who have it and look at the project history together. The product owner is a good place to start. Have a look at the storymap and if there is none, make one. You could also draw out end-2-end user interaction scenarios with the product owner. Start with the “happy flow” and once finished look at the features in it already built and what has to be added. Find out what’s holding the project back from completing an end-2-end value chain.
Example questions that can give you a head start:

• Can you explain to me what the minimal end-2-end functionality looks like?
• What’s the value of this functionality for the customer?
• What is needed to complete the first end-2-end functionality set?

Ownership wise, you have to take charge of the valuechain and what happens to it during the course of the project. If your program runs on shared environments, like sharing test or acceptance environments with other projects, find out what is the priority for your program. From there on implement some form of flight control mechanism. On shared environments the case is often that operations is expecting the supplying party to coordinate, and the supplying party is expecting the operations to coordinate. Result is a big mess you need to clean up.
To get an image of what’s going on, talk to Operations. See how often ops has issues when deploying and were they originate from. Of course it goes without saying that this point in your model gets more important and complex the more third party vendors are in acting in your value chain.
Questions I like to use to get my head around this part of the model:

• Who’s managing the timeslots and priorities on the different environments?
• How long does it take to execute a deployment? What kind of recurring issues occur?
• Which colleagues operate right before and right after you in the value chain?
• What’s to be considered the starting point of the value chain? What the end?

PART IV: Four majestic pillars that support the roof
There are four pillars that support the roof of our temple:
1. Create a single managed backlog:
It is imperative to have a single managed backlog. Derailed projects often show a myriad of specs and priorities across the entire program and strange constructs to manage these. Get the whole thing back to a single product owner and concrete priorities. Work out the backlog in rapid design workshops for at least the next release and estimate this with the entire team. To find out if productowners are aligned and focused, check if there is a single backlog or storymap in place together with a sort of chief product owner. Also check if the chief has a clear vision on the product (especially the bare minimal viable product) and the mandate to make decisions accordingly. A good second indicator is to see whether or not productowners are discussing central release goals instead of their own. How often do they jointly check if these central goals are going to be met? Even when there is a clear central backlog and goals, productowners could still work separately in practice mainly cleaning their own alleys.
2. Know your velocity:
In multi-team programs, it’s often hard to work with velocity across teams if you want to relate this to a centralized release- and/or product backlog. But in a program under pressure, it is imperative that you obtain this information to see what scope you will be able to finish given the circumstances and current delivery speeds. To check what’s happening based on velocity ask how teams do their estimation and who estimates what with regards to the final product. Next to this you can ask what reference point is being used and if this is the same for all teams. In the latter case, you usually see. You may need to adjust- and act on a number of things to make any sense of a common velocity, depending on the answer to the above questions.
3. Work end-2-end:
Planning wise you do not want any loose ends to be lying around. This is a great project risk. Velocity in relation to planning-information is only worth anything, when based on end-2-end results from the teams. So from requirement to production (ready) products. To check if the teams and the program as a whole is working end-2-end each sprint, look at program planning phases and talk to program and project managers. They might reveal that they want to do other test types after “development” work is “done”… My rule of thumb is the thinner the definition of done, the more risk is shifted to the end of the program, the harder it will be to mitigate this risk and tame the crisis.
4. Start continuous improvement on the program level in a PTC (Program Transition Community).
I am sure you have all heard of enterprise transition communities or ETC’s. Just like with an agile adoption, taming a project crisis is also not a one-time effort, but a continuous one. Solving all problems in just one go is an illusion. In derailed programs, continuous improvement on program level is often non-existing, and you can’t rely on the self-improvement of individual delivery teams alone. Simple look-ups can improve your mental image. See if there is a program level standup and if issues and impediments are made explicit. See if there is some record available of improvements etc. To see indications of the base to start improving on this level, look at the solve time for impediments not solved within the teams.
PART V: THE ROOF – Prioritized goals and the eternal bliss of: transparent, reliable program results
The pillars hold the roof. The main part of the temple, pointing towards the eternal bliss of transparent, reliable program results. The roof therefor represents the priority in program goals. In many programs in crisis we see, there are multiple program goals trying to be completed at the same time. The goals set by the steering committee have to be streamlined by prioritization. Just like the temple roof is pointy, everything done in the program at any given time should lead to the top priority goal. One goal at a time will keep the focus in the program optimal and guarantee the quickest results. People can still have their own sub-goals, but they should at all time have a direct contribution to the central goal with the highest priority. To get a view on this area, ask the same question to various people in different layers of the program hierarchy; what is our main priority/ goal right now? If your getting different answers there might be a problem (try to ask why to see if the answers lead the same destination), if people are unable to answer, you also have a problem. Also look if you see the goals being properly communicated and repeated. In group sessions, in written meeting minutes and most importantly in peoples workspace.
Conclusion
The first important step to resolve a crisis is to understand its context and situations. Easily said, but not always a simple thing to do. In complex situations, a model that offers a structure for prioritizing information and building up a mental image is of great help. Burms temple is such a model.
Next steps
The next step is to determine what actions need to be done to mitigate the current situation you have modeled using Burms temple. From here you and your client can share and form this common vision into an actionable plan, which will raise you from crisis-mode towards transparent, reliable program results……..
PS thanks again Geert!