Lean Thinking

Written by Published in Agile

Take a thin steel rod. I'm sure you have one handy. Clamp one end in a vice (which you also have handy...I know I do) so that it's sticking straight up in the air. Now move the free end of the rod to the side a little and let it go. What happened? Did it spring right back? OK, now move it a little further. Still springing back? If you keep going, moving it a little further each time, you will find a point where the rod no longer springs back but bends permanently. Materials scientists call this the elastic limit. Below this limit, materials experience elastic deformation - they spring back to the way they were before once the force is removed. Above this limit, they experience what is called plastic deformation - they no longer spring back but permanently change shape.

So why am I giving you this lecture in materials science? Because organisations behave the same way. When you apply a force to them - when you change something - the organisation is very good at snapping straight back to the way it was before.  As soon as you stop pushing the change, the change disappears. We've all seen it happen. As soon as you relax, the change evaporates and within a short time the organisation is happily doing what it has always done.

Written by Published in Agile

Teams hold a special status in agile. Teams are at the heart of all agile frameworks and much of the focus of the agile community is on growing and supporting teams. Not just any teams, agile teams stress things like self organisation and cross functionality. There is no denying that a really good agile team is an awesome sight to behold. The amount of stuff they can get done is nothing short of remarkable. But there are also an awful lot of agile teams that have the same properties but their performance isn't anywhere near as good. So what is wrong with those teams? Is it the people? Is it the environment? Is it the nature of the work? What stops some teams from performing where others with the same characteristics flourish?

In an effort to understand why, I have been thinking deeply about the concept of the team; why they are so effective and why we insist on certain characteristics for our agile teams. The conclusion I have come to is that it's all about the ability to make decisions.

Written by 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.

Written by 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.

Calendar

« November 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