AgileLondon at McKinsey Labs

This week I went to AgileLondon which was hosted at McKinsey. It was a really interesting MeetUp-style event with a format I’ve not seen before.

There were seven presentations and we all voted for two of them after a short elevator pitch from the presenters on why their presentation was worthy of being included. The other five were ‘eliminated’ and the audience provided a topic for those presenters to work on while the two were being presented.

As you can imagine, all six presenters at McKinsey were slick. They were probably the best set of presenters I’ve ever seen from a single company – all clear, eloquent, confident and understood the audience [of software developers].

LeSS – Large Scale Scrum

An organisation structure in LeSS

The first presentation was on LeSS presented by Karim Harbott (@karimharbott).

LeSS is an alternative to SAFe, enabling Agile Scrum teams to scale effectively. Karim is an Agile coach and usually spends a couple of days on LeSS, but here he had only twenty minutes.

The first piece of advice was to try to avoid scaling scrum teams in the first place. A small high performance team is always going to be more productive than the management and communication issues of multiple teams. However there are always going to be some projects which require multiple teams.

An organisation structure in LeSS

Karim explained LeSS concepts such as principles, frameworks, guides and experiments. He went through the team organisational structure with multiple teams and Product Owners, and how they are co-workers – Scrum Masters don’t report to them.

There were four key takeaways:

Try to avoid scaling scrum teams

Scaled teams often requires deep organisational change

LeSS is Scrum, it shouldn’t be any more complex than core Scrum

Invest in quality coaches (although he would say that!) to start the project off on the right track

Trust

The next presentation was from Cuan Mulligan (@cuan), who I don’t think works for McKinsey, but probably should.

Cuan started off by asking whether trust is tangible or measurable and even with a room of 150 people it was a good debate.

The trust triangle in organisations

Cuan described how results are proportional to trust. The World is now changing – previously, big companies could beat small ones due to expensive barriers to entry and distribution. But now, fast companies beat others, and too often big companies are slow.

Where trust is high and implicit, communication flows more easily, and often a team doesn’t need to hear the full story to understand what is being said.

Cuan recommended a few books including The Advantage, which we’re using at Endava, and Cuan talked about the pyramid of trust – see the photo here. Trust is supposed to be the foundation, which leads to results, however too many organisations start with results – the Chief Executive announces “We will increase sales by x”, which assigns accountability, commits people to achieve the goals and so on – essentially trust is the final achievement and it’s all backwards.

Character and competence are primary ingredients of trust. Cuan described how character and competence are often confused. Language is very important to separate the two. In the UK for example, we often mistake a criticism about competence as a character flaw, so we need to be extra careful about the language we use.

The quickest way to increase trust is say-do. This means if you say something, do it. If you don’t do it, even if it’s trivial to you, “I’ll send you an email by 4pm”, it erodes trust.

Agile Contracts

The final presentation which was produced on the night was about Agile contracts. These types of contracts are notoriously difficult in IT services companies.

An Agile contracts presentation – created in 40 minutes. How hard can it be?

McKinsey’s recommendation was to involve legal early on, incentivise staged delivery, reward the response to change, and avoid time, scope and cost dependencies. They recommended including a minimum guarantee for a deliverable, and to include a long term incentive.

A good tip they gave is to avoid the language of a purchase or buying something. If the legal team from the buyer thinks they are buying [an Agile] something, they will naturally fall into the I’m buying something and if you don’t deliver then I will penalise you mindset. Instead of this, encourage the buyer to think of the engagement as an investment.

Please share this post with your contacts because it makes me feel better.

3 thoughts on “AgileLondon at McKinsey Labs”

The 8 topics we chose from were:
1. Caught in the web of complexity
2. Agile in the US – the current state of play
3. The importance of building Trust, from the CEO to the team.
4. Managing your impact – what type of problems is your organisation designed for
5. A practical application of Cynefin
6. Large Scale Scrum (LeSS) in 15 minutes
7. Importance of Self organisation
8. Crowdsource topic on the night – creating a talk in 30 minutes