Lean Thinking

Monday, 22 May 2017 12:50

Scaling Up To Scale Down

Published in Agile

Last time we looked at the trend towards massive scale in the agile community and some of the problems scale leads to. We looked at an alternative approach. A scaled down approach -

"Imagine, instead of a huge program, we have small groups of teams, say 2-5 teams in a group. Each group manages its own stakeholders, environments, dependencies and the like. Each group is directly aligned to a set of business stakeholders with a common set of outcomes, is funded through an investment pool aligned to business outcomes, not specific project deliverables, and delivers value end to end for the stakeholder group."

This approach would allow the organisation to deliver value efficiently without the need for massive scaled structures and the complexity and inefficiencies that go along with them. The only problem of course is that such a structure is impossible in most organisations because they are built around large programs and large platforms and simply don't have the ability, architecture or processes to handle a scaled down operation.

So where to from here? Can we move beyond scaled approaches to a scaled down approach? I think we can and the first step in that journey is to scale up.

Tuesday, 09 May 2017 21:21

Should We Scale?

Published in Agile

There has been a trend recently within the agile community to embrace massive scale. Not just a few teams working together but really large groups. Every day we see examples of bigger programs, larger release trains, all successfully being managed through agile techniques. Just recently, a colleague ran a PI planning event for close to 1000 people spread across three countries. I have seen other organisations proudly boasting that they have "the largest release train in the southern hemisphere", with some figures on the incredible budgets that the train is managing. The SAFe framework now has 4 levels rather than 3 to enable it to manage bigger and bigger structures. Less has Less-huge to do the same.

While I celebrate the achievements of the coaches successfully helping organisations achieve this, and the incredible feat of facilitation that a 1000 person, 3 country PI event must be, I can't help worrying that this drive towards massive scale is not altogether a good thing. Large companies want scale because that's the way they are used to working. They are used to thinking in terms of large programs of work involving hundreds of people. In order to help them, we have developed techniques that allow us to handle this sort of scale. But just because we can do something, it does not automatically follow that we should do something. There are significant downsides to scale.

Tuesday, 04 October 2016 14:09

Principles Part 5 - Self Similarity

Published in Agile

We have now covered six principles -
They are built around small, self-organising teams

  • The team has a clear vision of what they are doing and where they fit into the bigger picture
  • The team has a well defined backlog of work
  • There is a content authority responsible for making sure decisions are made quickly
  • There is a clear bidirectional service agreement between the team and the rest of the organisation
  • There is a fast feedback loop that allows the team and organisation to optimise both the process and the product.

At this point we have everything we need to enable a team to operate in a really agile way. The team doesn't need anything else. So why are there seven principles?

The seventh principle isn't a team principle. It's a scaling principle. Very few organisations are able to deliver real value with a single team so the last principle kicks in when you don't have just one team but a team of teams, or a hierachy of teams all working together to deliver value. The first 6 principles define how you should set up your teams, the seventh principle defines how you should link them together -

  • The organisation should be self similar at scale

There are two ways an organisation can handle scale. They can do what most organisations do and add extra complexity to their processes to handle the extra complexity of scale or they can develop a simple pattern (like teams operating under the first 6 principles) that works and iterate that in a self similar way to operate at scale. Add complexity through extra processes or iterate simplicity through self similarity.

Tuesday, 29 March 2016 10:27

Why Guilds Die - The Yfitops effect.

Published in Agile

First up, this post has come about through a discussion I had with a group of other coaches, so thanks to The People's Popular Feed crowd - Steve, Pradeep, Bob, Carl, Gaya, James, Elvira and Tony for the spark.

We all know the Spotify model - squads, tribes, chapters and guilds. It's a great model and many of us have tried to implement it in other organisations. In my experience though, most of those implementations fail, particularly around chapters and guilds. One of the first things we tend to do as coaches is set up guilds. We need a way of getting people to share information across organisational silos and guilds are a great way to do that. Trouble is, it's almost impossible to keep a guild running in many organisations without someone pretty much full time cajoling and pleading with people to attend. Without someone who is willing to make the guild their life's work, they quickly fizzle out. 

It shouldn't be that way. A guild should be self sustaining. The members should be there because they are interested and see it adding value, not because George, the guild master badgered them into attending this week's meeting. So why, when they are so good in theory, are they so hard to keep running in practice? I have been giving this some thought recently (while sifting through the wreckage of another dead guild) and came to the conclusion that it's because we are doing things backwards.

Tuesday, 15 March 2016 10:20

Why I don't like the PI

Published in Agile

Probaly the most iconic feature of the SAFe model is the Program Increment (or PI). The PI (for those who have never seen SAFe before) is a larger, release level timebox, usually 4-6 sprints long starting with a 2 day, all hands planning event. The PI is also the feature of SAFe that I like the least. Proponents of SAFe will, quite rightly, point out that the PI planning event is a highly effective way to plan a release and is great for getting a large team of teams aligned and motivated around a goal. And indeed it is. I still don't like them though. As effective as they are, the PI planning session, and the PI in general, have some unintended consequences that far outweigh the benefits.

The goal of agile is to enable organisations to respond to changing conditions quickly and at the team level, for teams to get stuff out to customers as fast as possible. The PI breaks this in a number of ways. It breaks flow into batches, encourages queueing and reduces the ability of teams and the organisation to respond.

Page 1 of 2

Calendar

« August 2017 »
Mon Tue Wed Thu Fri Sat Sun
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31