Adaptation and product delivery

By Kurt Brown

Like most, my working life has seen me play different roles for a number of companies. My time consulting has added even more variety into that mix. Over that time, I’ve observed some organisations thrive when unexpected events impact them or their market. Conversely, I’ve seen a lot of organisations struggle with even small surprises.

COVID-19 has brought this disparity in organisational resilience into stark relief. It seemed a good time to share my thoughts on what helps organisations and teams, engaged in digital product delivery detect, react and respond to changing environments.

Clear and open lines of communication

You’ll note in the introduction the phrase “detect, react and respond”. The ability to detect disruption or uncertainty is pretty standard for most organisations, but what varies is the amount of early warning and the amount of information that can be collected.

Early detection of a disruptive event allows an organisation to have maximum time to assess the extent of the disruption, determine the urgency with which they should respond and plan and communicate their response.

However, there is no use in detecting an event, evaluating it and determining a course of action, if you are then not able to marshall and co-ordinate your response. You need established channels of communication with your team, the rest of the organisation and potentially your customers to ensure that any plan isn’t lost, corrupted or misinterpreted.

It’s also certain your initial plan won’t be perfect (that’s where culture comes in, see more on this below), so you need responsive and accurate two-way communication to be able to quickly find that out, adapt your plan and set the new directions.

Tips

1. Take note the next time you see a message that gets lost, delayed or corrupted, in or out of your team. Establish a root cause (my favourite investigative technique is the 5 Whys) and fix the issue in that channel. If it’s new to you, then it’s likely unknown to other people that should also know. If you analyse who knew and how they found out, and contrast that with the people that didn’t know, that should lead to a solution on how best to radiate that sort of information in the future.
2. Do you have channels that get used rarely but sometimes contain vital pieces of information? This can be OK if it’s set up for that very purpose — think of an emergency hotline — but if it’s used for other purposes as well there is a good chance that will get missed by some or all of your organisation when it’s needed.
3. Similarly, do you have channels that get used all the time for trivial or operational matters, such as a group chat or slack channel, that occasionally contain crucial information? This is a sure fire way for things to get missed. Consider establishing separate channels or comms guidelines to ensure important conversations are not lost in the mix.

Efficiency and waste

Any fan of Lean thinking already knows the importance of waste minimisation. But an often overlooked benefit of a Lean approach is when outside forces cause you to have to significantly pivot your product or even stall it in the market. Firstly, already having a small inventory of incomplete work ensures that any loss is minimal in the event of major pivots or halts in production. And secondly, there are a few other Lean thinking measures and metrics you can use to determine the efficiency of your production.

Takt

“Takt” time measures the distance between starting production on one item and the next. This is obviously very applicable to traditional manufacturing but can be employed in technology delivery with some adaptation.

Work in progress vs complete

This goes beyond simply tracking work in progress (WIP) each sprint. It’s important that you have a good, complete and robust definition of done, and worth considering if your definition of done is “done” or “done done”. Is it in production, being actively used, generating value, or is it simply through QA (or worse dev-complete)? Ideally you’re delivering to production multiple times a day, but often larger changes or feature sets take time to truly get to market. A log of what’s in play vs what’s deployed vs what’s actually being used is a useful way to track the amount of pending work you have, and therefore the likely amount of waste you might have should you need to significantly pivot.

Lead time

Finally, lead time is critical. Lead time is sometimes measured as the total time it takes a given task to progress from the beginning of the workflow to its end. In software delivery this is often tracked as the time from when a feature enters a backog to when it’s delivered into production. A more pertinent and insightful measure should really be from the moment an idea is generated to the moment it reaches customers’ hands and is generating value. This is not only a useful measure to determine the likely ability to react to an unexpected event, but can help highlight where you are actually following “Scrumfall”. A Scrumfall process is best described as essentially a waterfall process but with “Agile” ceremonies. Distinct design, delivery, testing and release phases with hand offs between them. That sort of process is not only inefficient and cumbersome, but usually overemphasises the bottlenecks within delivery and squeezes time for adequate QA and development hygiene. Often this is a sign the real delays might be upstream or downstream from the software development process.

Tips

1. Do you have or can you create a centralised idea logging point to truly capture the start of your lead time? It’s hard to get 100% accurate but with diligence this can be tracked.
2. Review your definition of done and the metrics around that. Is deploying to production but feature-toggling something off truly “done”? Is a feature that sits in your app that no-one has used really “done”? Track what value means to you and your organisation with discipline and honesty.
3. Do you see the same “bottlenecks” identified consistently as the cause of longer lead time? Trace back to see if that’s really the problem. A good example of this is delays in getting testing complete that are actually the result of requirements that are not testable.

Note your dependencies

Constraints, bottlenecks and dependencies are inevitable in product delivery. There may be interaction required with other teams, departments, suppliers or partners that are part of your production.

Most projects track dependencies on some sort of risk registry, but typically these stop at project boundaries or inter-team interactions. It’s worth noting them, but it’s also worth exploring what other dependencies exist that are outside of your control and how they can be mitigated. It can be a little bit of a rabbit hole, so it’s important to ensure you are only tracking things that are avoidable.

With each dependency, track a few things:

• What is the likelihood of the dependency creating a significant bottleneck or blocker?
• What impact will it have on delivery?
• What would it take in terms of cost (real expense and/or opportunity cost), time, and effort to address it?
• What benefits would arise from addressing it now?

That last one is the thing most people don’t take time to look at, and similar to the “cost of delay” is a measure that can really tip the balance in your decision to mitigate or remove that dependency.

Tips

1. Spend time with your team critically analysing the bottlenecks and dependencies with a clear mandate — do they really need to exist? There are often simple fixes or at least work arounds that can be employed to remove or reduce the impact of these and often we get caught up in accepting these as part of being business-as-usual (BAU).
2. Do the other parties recognised as dependencies track it on their side? We often see one-sided dependency registers. Whilst that helps your team manage their exposure, it doesn’t help the other side lean in and help address it, nor does it radiate out to others in the organisation that could help to streamline things.
3. How does your organisation respond when dependencies cause issues? Does it take an opportunity to learn from that or does it resort to blame and finger pointing? Addressing these cultural issues is hard but without that you will track your dependencies and perhaps manage them, but never truly free yourself from them.

Don’t rely on chance encounters

We’ve all had chance encounters at the coffee machine or in the lift that have revealed some sort of insight that was substantial. We tend to place emphasis on the power of face-to-face interactions giving us the space and opportunity to allow these insights to come to light. And whilst face-to-face interactions are an incredibly rewarding and valuable part of our human existence, anything that happens by chance is inherently dangerous in the business world.

So next time that happens to you, rather than celebrate the fact that you uncovered a piece of valuable intel, instead explore why it took that chance encounter for that to happen. Why isn’t that just part of the information that is radiated out? What forums should that information have been in and why wasn’t in there? Was that information available but you missed it?

Once you’ve established the initial reason why information surfaced the way it did, it’s then important to do a few more things. Start with a true root cause analysis (again the “5 Whys” from the Toyota Lean system is useful here). Then look at what would have been the impact had it not surfaced when it did or not surfaced at all? What measures can you put in place now to make sure that it doesn’t rely on chance in the future?

Tips

1. When you see decisions being made in ad-hoc encounters (either in an informal context or in meetings that were not held to discuss that issue) take a note. Are there already formal mechanisms for those decisions? If so, why wasn’t it discussed and addressed there. That can often give insight to inefficient processes or breakdowns in working models.
2. Lean into some of these informal settings and formats but broaden the audience. If you often get insights from a particular colleague over a cup of coffee think about inviting others along to start to expand the audience. This might change the dynamic of that catch up, so it might not be a regular thing, but it’s often a way to kick start a broader discourse within your organisation.
3. Engineer some “chance encounters” of your own. Invite members from other teams for a coffee or lunch and take careful note of what comes out. Be sure not to use that for recriminations or political point-scoring though. Use it to gauge how plugged-in you and your team are, and if there are gaps in your visibility, take responsibility for them and take steps to address them.

Culture eats strategy for breakfast

Any product delivery is consistently reviewed for risks and dependencies that would impact delivery. For example, that you are consciously looking at your delivery process for flexibility and adaptability. That you have plans in place to respond to changes in the environment your product is delivered within and the process and team that it delivers. Planning is crucial but you don’t want to have to enact these plans at pace and pressure for the first time in the event of a disruption. As such, it’s important to practice these measures to ensure your team is familiar with them and that the alternatives you have in place are viable and sustainable.

Game days are simple ways to test the resilience of your system architecture and similar techniques can be used across the board to test your entire delivery process. Critically examine your product, it’s market, your customers and your workforce. List all the factors that are possible to present disruptions. Rate the likelihood of each occurring and rate the impact it’ll have. Take the high impact ones first. Have a plan to cover each circumstance ready to go. Don’t wait for things to fail before you see if your plan works.

However it’s important to recognise that any plan will have holes in it. That’s an uncomfortable truth for many of us, especially those whose job is essentially a planning one. And regardless of that, any plan will be difficult to adhere to 100%. As Mike Tyson so eloquently put it “everyone has a plan until they get punched in the mouth”.

This is where your team’s culture will come into play. A team that is ready to work together, to have each others’ back, to dig in, will cope with a plan that isn’t perfect. If your culture is driven around the values of teamwork, knowledge sharing, and helping others grow, they will find a way to adapt your plan to achieve the desired outcomes, often producing better ways of working as a result. A team that doesn’t behave like that will probably be unable to cope even if your plan is perfect, as the pressure and stress of disruption will heighten tensions.

Tips

1. What sort of cultural norms does your team exist within? Use a model (such as the Westrom Model) to determine your team’s dominant cultural traits. Then use the same model to ascertain the broader organisation you exist within and compare and contrast the two. Westrum defines the culture within organizations as “the patterned way that an organization responds to its challenges, whether these are explicit (for example, a crisis) or implicit (a latent problem or opportunity)”. Whilst the model isn’t perfect (one of the biggest concerns of mine being the very loaded terms of “Pathological vs Bureaucratic vs Generative”) it can be a useful way to model how decisions get made and information shared, and is a good guide to help shape your plans.
2. Where you have a small number of key participants it can be useful to model Personality Traits (such as the Myers-Briggs system) and share that with the team. This can help people have empathy for others within the team and establish ways of working and communicating before the pressure hits. Again there are a large number of models and none of them are perfect but can be a useful part of the picture.
3. Look for leadership in small increments. Highlight those that step up when small mistakes occur as they are likely to be the ones you can look to when the big ones come along. Dig deeper than who solved the problem though. Who took ownership, who maintained morale, who helped information flow. Often we focus on the person who “rides to the rescue” without acknowledging those that set them up for success.

If it was easy, you’d be doing it already

Like most things in life, it’s not as simple or cut and dried as simply focussing on the above. There are clearly other factors that will help or hinder organisations in their attempts to cope with disruptions such as architectural flexibility, scalability, capital reserves, partner relationships and employee skills and capability.

However I feel like the above are often the most overlooked, but simplest to address, factors. These are the factors that can be enhanced and built upon in incremental steps, they do not require any sort of big bang cutover or substantial investment to achieve. Conversely they are factors that when left unattended will limit the organisation a lot more than an inflexible legacy tech stack will.

You’ve no doubt heard the expression “never let a crisis go to waste”. But the reality is that when crisis strikes it’s often a matter of getting out of it rather than learning from it for most of us. So I’d suggest instead you lean in the next time there is a small hiccup. Don’t blow it out of all proportion but deal with it with more care and attention than you normally would. Trial some of the techniques above, or other techniques you know of, and get to grips with them. This will help you identify some of the factors of your organisation and its culture and how it might best learn from adversity. Use that as an opportunity to help you pre-empt and ride through the next hiccup a little better than last time.

If you can develop and nurture that learning culture, you’ll be well on your way to preparing yourself to be in a much better position when that next crisis does arrive.