Earlier in my journey as a coach / delivery consultant, I thought that agility can be achieved through a “high performing team”. Many agile coaches, scrum masters, delivery leads / managers etc have tried to achieve this kind of thing through making a great team. This might work really well in a small organisation, but once you get to medium to large size organisations, this is not necessarily where the key problem is.

In more recent years, I’ve observed how critical it is to bring various groups together to achieve an outcome. The solutions to some problems are larger than just one or two teams and create interdependencies for delivery. Often, the points of waiting and even friction occur where these interactions are necessary.

Problems with “High Performing” teams

A high performing team works great when all of the dependencies are contained within the group. This could be a single team or a “Service Team” which I see as a larger group or “team of teams” providing a service (eg five 10 person teams working together). Often this team have optimised the interactions within the group and have a fairly well known way of working.

Where this group needs to interact with others in the organisation, it can run into problems. Other groups may have their own way of working which may be similar but is often times different. Relationships between members of the different groups may not be very deep or perhaps non-existent.

Additionally, I’ve seen in the past where teams are “high performing” this can increase the silo mentality and start to create a blame culture. That is, they don’t want to be seen as a non high-performer and become insular and in some cases arrogant. They can call blockers out up and downstream, but don’t want to spend their time being “unproductive” by relieving the blockers. If it goes unmanaged, you can see them pull in more WiP in this circumstance while they wait , which creates further problems.

It may be that they don’t have the skills to go upstream / downstream to help relieve the overall system. Thus they continue on with solving “their part of the problem”, but the overall tends to suffer.

Take, for example, a mobile development service team. They may make regular (eg monthly) improvements to the mobile application / device for your organisation which they can do entirely by themselves. Then at some point your organisation wants to launch a whole new feature not previously seen. You want to showcase this at an upcoming trade fair to generate the largest possible market interest in a short amount of time. Your mobile team will need to work with the marketing team and sales teams to ensure you can maximise the revenue opportunity at the trade fair. They may have rarely done this before, thus the interaction is unusual but critical for the overall business success.

Nature of work in large organisations

Your organisation is a network of interdependent services that act together to serve your customers. This is really an adapting, changing, organic ecosystem if it’s running effectively. External stimuli (customers, markets, competitors) will place new demands on the ecosystem and it’s long term success is based on it’s ability to adapt to that stimuli.

In larger organisations, there may be some interactions between groups that are consistent / regular (work together on many / most initiatives), others may be occasional (eg once or twice a year) and others may be a “one off”. For those that are consistent or occasional, you may be able to predict this to a certain extent. Even if you can predict the frequency of the interactions, the nature of the individual interactions may be quite different.

Oftentimes, the really high value work will mean that this kind of work likely doesn’t have much / any connection to previous work so you’ll need to establish some relationships from scratch.

Possible Solutions

Understand the network

Sometimes to get this understanding you may need to visualise the work and “how work works” as it traverses the organisation.

Where it is at all possible, it would be worth gathering some data about the network to understand the interactions. You can see where the common links are that you want to strengthen and how you may wish to make changes. You may also wish to gather data on where wait states and blockers are in the overall workflow. You may wish to introduce a cadence like Kanban’s “Operation’s Review” to continually monitor and adjust.

Protocols

The internet is a classic example of a network that grows and changes over time, but the fundamentals of how nodes communicate with one another is governed by some simple protocols. You can set this up as basic systemic policies to allow for simpler communication and coordination around the network.

Cadences

Sometimes cadences can work to help with synchronising groups. However, beware of this becomes sometime they can be a source of waiting / waste. For example, if you have a quarterly planning cycle, you may not want to wait that long for a new, urgent piece of work.

Reorganise teams

This really isn’t really viable in the short term – with different work coming from different sources it often doesn’t make sense to continually reorganise. Furthermore, there are costs associated with doing so – there will be a period of inactivity, plus you’ll lose the benefit of previous metrics for that team as it establishes it’s new identity / way of working. If in the longer term you see a continuing pattern of teams working together, you may want to take action at that point – just wait until the reason is compelling enough to justify the cost.

Remove dependencies

This is something that you should always consider, however in larger more complicated work, this is not always practical or possible. You may achieve this by slicing work into more narrow / succinct areas of scope to avoid the immediate need for a dependency. This can also be achieved by changing a technical need for the dependency.

Coordination specialists

Some people are natural connectors in organisations, knowing who to contact / bring together to help solve problems. You can use these folks to help guide work through the network, facilitating the creation and maintenance of connections where required.

Team Member Swap / injection

While complete reorganisation of teams may be too disruptive, you may wish to consider injecting a member from one service team to another to act as a bridge for a particular initiative. This could also take form of a swap where team members are exchanged from each group. This will help build a deeper understanding of the other groups context which will make this and future interactions smoother.

Stimulating the organisational network

There are a couple of spins to this from my perspective – one is the effect you get from large group events where there is lots of interaction. Meeting new people and understanding who is who can help to start to bridge the gaps of connectedness – this can often occur as part of a regular planning or other similar cadence. The other way is a deeper understanding is through other techniques like Cognitive Edge’s Social network stimulation.

Conclusion

As your organisation grows, the complexity of how it solves problems will likely also change. When you get to a certain size, having a “high performing team” will not necessarily be enough – you will need to tune the entire network of services to be able to adapt appropriately.

This is not a simple problem to solve, so it’s best that you don’t act too simplistically. Furthermore, as the organisation and environment continually evolves you will never be “done” with this – you’ll always need to monitor and make continuing adjustments.

As I mentioned in my recent post on Kanban books, I would recommend Klaus Leopold’s book on this topic: “Rethinking Agile: Why agile teams have nothing to do with business agility”.

RETURN TO BLOG

I’ve heard this being said a number of times with teams and it often reminds me of the story the Jeff Patton told in his book “User Story Mapping” when he was talking about requirements. In that story, when he was trying to get a better understanding of the underlying need being requested he was told “They’re requirements” – to which he likened to being told to “shut up”.

When I hear the term “It’s on the backlog” I think that’s another way some agilists are telling others to “shut up”, or at the very least “go away”. Often it’s not followed up with more honesty like “we don’t intend to build that”, or at the very least “it’s not likely to be built in the near future”. Sometimes this is a way of saying “No” or “Not yet” where it can be difficult to say this flat out, but is it the most respectful way to treat people?

Again, this is the problem with using the term “Backlog” instead of “Options”.

How about instead try something along the lines of “we can add a ticket to our pool of options, but it’s not likely to be implemented anytime soon, if at all”. You might find that this change in terminology gives your stakeholders greater respect and builds on the trust and transparency that you need to build a more stable foundation for a longer lasting relationship. Also, you’re starting lean towards the use of language that supports probability / likelihood rather than absolute certainty. This incremental step can be built upon later with greater use forecasting.

RETURN TO BLOG

I’ve recently been thinking about a number of experiences in my career where organisations who have a bias for delivery have uncovered options that were not previously available to them. I’ve also seen others who had a tendency to delay delivery (or at least deployment) to when their customers are “fully ready” for it.

This predominantly happens in organisations that have traditionally had long lead times for delivery. Often the transaction costs for delivery are quite high, but other times it may be that the process and thinking over time has solidified such that the delivery managers don’t consider other options.

Some of the arguments I’ve heard include the following (along with my counter arguments):

That’s the way we’ve always done it” – That’s a Kodak moment waiting to happen. You can bet you’re bottom dollar that if you’re not looking to improve, then your competitors are. How long do you think that will last?

It will cost too much” – This is often in the context of the cost of deploying without delivering – there is a run cost to have the hardware / systems there earlier. However, I would counter this by saying the hidden costs you’re not considering are:

  • Lifecycle vs Project costs – if you deploy regularly during the project, you can test the deployment automation mechanism and be confident that it works at the push of a button. Delaying this often means costs are pushed into BAU where later releases are still manual and are longer, costlier and riskier
  • Opportunity cost – by sticking to long cycle times, you are cutting yourself off to potential other opportunities that you’re not aware of yet
  • Transaction costs are high – well, if we don’t do something about it earlier they will always be high. Maybe there are some ways that you can start to reduce these transaction costs that you haven’t thought of – perhaps start here.
  • Have you fully considered the overall cost of delay if you get into a “large batch death spiral“? This is quite likely if you stick to this.

Our users are not ready for it yet” – Perhaps, but have you considered all of your user groups? I’ve seen opportunities where you can do early releases to your staff / operations team often referred to as “Eating your own dog food” (a common practice at Microsoft). This is a great way to reduce overall delivery risk – particularly if you have a large delivery footprint.

What are some of the results we’re likely to see?

Some of what I’ve seen before are a combination of things, the key one is:

New opportunities – This is often not thought of and the value here can be enormous. I’ve seen organisations try to release a new product and it doesn’t go exactly as expected. However, by getting something out earlier, it’s given them a new capability / offering that has allowed for exaptation / transforming into other products or parts of products. By getting something out early they have created a new foundation for future revenue.

Other reasons for taking a bias to delivery include:

  • Reduced delivery risk – particularly around timeline. Getting things out early and regularly so at least someone can use it helps validate if you’re really on track (even if it’s not your final target user group).
  • Reduced costs – In some instances I’ve seen clients say “This often takes 12 months and can often fail – let’s see if we can get something out in 3 months”. It gets really hard to spend a lot of money in a smaller timespan.
  • Stopping – There’s often an OPEX / CAPEX problem if you haven’t actually produced a usable asset. Some organisations, are reluctant to stop the large batches because it will switch spend to date to OPEX from CAPEX which will have deeper ramifications for the organisation and their customers.
  • CAPEX depreciation – If you can start depreciating an asset in 3 months rather than 12, there are potential financial benefits to this that you otherwise wouldn’t have

How do we get started?

In a word – Leadership. By this, I mean someone has to have the vision and courage to see what is possible and make a change. This does not necessarily have to be done at the top level – I would encourage all Delivery Managers, Project Managers etc to consider this on their project.

If you’re working in a space and see this happen, try arguing with some of the reasons above and probe to understand why people might not wish to try it. It may just be “too different” to what they’re used to. You may need to break through any fear there in some way – you might want to create a greater fear in maintaining the status quo with the reasons above to create that movement.

RETURN TO BLOG

Often we become constrained in our thinking by the language we use – a good example is the use of the term “backlog” instead of “options”. Quite often if you say to someone “It’s on the backlog”, the perception is quite often that although I might not get it now, it will become available sometime. However, in reality this is often not the case – or should not be the case. If we change the wording we use, we’ll create a more accurate representation of what is actually, or should actually, be happening.

Definitions from the Cambridge dictionary:

Backlog: “a large number of things that you should have done before and must do now”

Option: “one thing that can be chosen from a set of possibilities, or the freedom to make a choice”

Commonly, the term option is used in the context of the stock market, where you can have an option to buy shares (or not). You have the choice – it’s not an absolute.

As you can see from the basic definitions above, they are quite different and the impression that they can give stakeholders, also, would be quite different.

The above definition of backlog implies a fixed scope – “must do now”. However, to truely be agile we shouldn’t be committing these kind of things up front as we’ll learn along the way and what should be done will change as we learn.

Try to stop using the term backlog, and instead replace it with the word(s) “Option” or “Pool of Options” and see what effect it has to the conversations with your customers and stakeholders. You’ll be able to defer commitments to a more reasonable point in time and have that process better understood. Additionally, you’ll likely find that you’ll have earlier conversations as to whether we should discard some options, rather than keep maintaining the illusion that something may get done.

RETURN TO BLOG

I’ve been doing this retrospective format for a number of years now and it’s been very useful. Given that we’re moving into Spring here in Melbourne I thought it would be a fitting time to publish this as we prepare for the Spring racing carnival.

For those of you who don’t live in Melbourne, or don’t know what the Melbourne Cup is all about, this will help set some background. Here in Melbourne the first Tuesday in November is a public holiday for the Melbourne Cup. The Melbourne Cup is a horse race – yes, we actually have a public holiday just because of a horse race! It’s more than just a horse race, it’s actually part of the culture here in Melbourne, there’s also the all the fashion, food, wine and socialising that goes on during the what is known as the “Melbourne Cup Carnival” – with events on throughout the week.

This particular retrospective format I’ve derived from the event is actually a “futurespective” – it’s useful to use it at the beginning of a project or product development initiative. It’s really a useful way to start to talk about risk, but to come at it from an oblique angle so that you can explore it openly without a great deal of negative fallout.

I start out with asking participants – “If this project were a horse in the Melbourne Cup, what odds would you give it?”. I ask that the participants write down their answers on a card fold it up and throw it into the middle of the table / room. I then pick up the cards and put them on the board ranking them from shortest to longest odds.

Once the values are on the wall, you can see the variety of responses. Sometimes they are clustered, sometimes they are very well dispersed. I really like it when you get a lot of very different responses, because it will add to the later discussion. One of the first times I ran this, I got one response of “2 to 1” and another of “100 to 1”.

This was actually a very small team with only a few people, so it was interesting to see those responses. When I probed some more “what made you give 2 to 1?”, I got the response “Well, the sponsors really want this to happen, so that will ensure that it’s seen through to conclusion”. Then I asked about the 100 to 1 and got a response along the lines of “The technical implementation has quite a few unknowns – I’m not sure when we hook these things together, if we’ll get it to work”.

So, very quickly we came to understand that our stakeholders are not necessarily going to be a risk, but an asset in seeing this done, but the technical implementation may pose some problems. Very different risk areas and very different responses – which was great!

Now, the next step is to get a better understanding of the risks – I often use the likelihood / impact model for this. I write up a card for each type of risk from the discussion and get the team to decide on where it would fit on the chart:

Normally as part of a retrospective you’ll want to take away a few improvements / countermeasures etc to take away and action and this retro is no different. With the above chart we can decide where we want to spend our next focus for improvement – usually start with the High Likelihood and High Impact and then go from there. There may be several risk mitigating / avoidance actions that you’ll need to take, so discuss how you’re going to do this with the group.

You can add these actions to your Kanban board for follow up in the upcoming days and weeks.

The Melbourne Cup retro is a great way to obliquely address upcoming risks in a forward looking retrospective. It’s not something that you necessarily need to do very often, but you might find it a valuable addition to your retrospective repertoire. If you like this idea for a retrospective and give it a try, please reach out to me (dploeg@evogility.com.au) and let me know how it goes.  

Feature Image:

This image was originally posted to Flickr by PreciousBytes at https://www.flickr.com/photos/72562013@N06/10705862835 and is distrubted under Creative Commons Attribution 2.0 Generic License.

RETURN TO BLOG