Lean Thinking

Written by Published in Agile

There has been a lot of talk at work recently about agile maturity checklists. There are dozens of them out there in the wild - the Nokia test, the unofficial scrum checklist, spotify checklists. Every organisation, at some point in their agile journey, seems to become consumed by a burning desire to measure just how agile they are, and sets about creating some sort of ultimate agility checklist mashed together from ones found online plus whatever else they can think to throw in.

There are a lot of reasons organisations want to measure agility. Some of them are good reasons, like looking for capability gaps so coaches and leaders know where more guidance is needed. There are also a whole lot of really bad reasons for measuring it, like comparing teams against each other at bonus time, or looking for conformance to a corporate agility standard. The biggest problem though with most agility checklists is that they measure the wrong things. They tend to focus on specific practices rather than focussing on desired outcomes. They are doing agile checklists not being agile checklists.

Written by Published in Agile

It's always good to go back to first principles occasionally so let's take a look at the agile manifesto. How does it go again? Processes and tools over individuals and interactions... No wait, that's not right. It's the other way around. But anyone observing the agile community over the last few years would be excused for thinking otherwise. For a group that follows a manifesto that explicitly prioritises individuals and interactions above processes and tools, we certainly get very hung up on processes and tools.

Be warned...this is a bit of a rant so you might want to stand back to avoid getting any on you.

For the last few years, the majority of the conversations I have had with other agile practitioners have been about processes and tools. Are you a Scrum or Kanban person? Do you prefer safe or less? Rally or jira? My response has typically been that they are all valid and I will use whatever is appropriate to best support the individuals and their interactions. Recently my response has started to shift towards violently banging my head against something solid, as it's more fruitful than yet another safe vs less argument. At least there is a chance that I will render myself unconscious and not have to hear yet again how less is "more agile" than safe or vice versa.

Written by Published in Agile

We talk a lot about T shaped skills in agile teams. For those who aren't familiar with the terminology, think about a capital "T". The vertical line is the team's core skill, they have deep expertise in that. The horizontal line is all the other things the team is capable of outside its core skill. A good team should have skills that are T shaped (broad as well as deep), rather than "I" shaped - deep in one area with no ability to work outside that (like traditional silo teams). We don't want a team that can only work on the back end of the website, we want teams that can deliver end to end. We don't want teams that can only deliver on the shopping cart, we want teams that can deliver in other areas as well.

The more T shaped our teams are, the more flexible we can be in organising work. If we have a lot of shopping cart enhancements, we don't have to wait for the shopping cart team to become free and deliver them all, we have a bunch of teams who can pick up the work and deliver it. This is a very good thing. There are however, a few key misconceptions about T shaped teams that I have observed over the years, that are worth pointing out and correcting.

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.

Calendar

« February 2018 »
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