Lean Thinking

Written by Published in Agile

I do a lot of coaching at large companies. Big, monolithic, and often very conservative organisations. Organisations like that are very difficult to change. They have become big and successful by being conservative and risk averse. There is a lot of resistance and inertia. They may recognise the need to change. They may recognise the benefits of change. Actually making that change though, means taking risks and they just can’t quite take that step. They will fiddle around at the edges and do some cosmetic stuff, but actually changing into an organisation that embraces innovation and risk is just a step too far.

So how does a coach actually implement change in an organisation like that? By making a small change that changes the behaviour of the organisation in a way that drives more change. Let me explain –

02 December 2013

Let's Get Physical

Written by Published in Agile

At work I do a lot of stuff. I help teams produce software that is used by millions of people. When I am home on the weekend I do more work, but it's different work. I work with my hands producing things. Physical things. Although what I do at work is valuable (far more valuable in dollar terms than my attempts at DIY) I almost feel more of a sense of satisfaction at seeing a finished thing worth $50 roll out of my workshop than a million dollar project roll out of one of my teams. Because it's real. Because I can touch it and pick it up ( well, maybe pick it up... some of them are quite heavy). Because it is a physical thing.

I react differently to physical things than I do to electronic things. Maybe this is because I am not in my first flush of youth and don't qualify as a "digital native". Maybe to younger people, electronic stuff feels just as real as physical things but I doubt it. People are hardwired to treat things they can see and touch as more real than things they can't. Even in the physical world. People will often take the single chocolate bar they can see now, rather than wait for ten chocolate bars that are waiting in the next room. The one they can see is more real than the ten they can't.

Written by Published in Agile

When a team is behind its targets, the natural instinct is to work even harder to catch up. Sometimes though, the best thing you can do is… nothing.

Let’s look at a team. For various reasons, they have done several sprints' worth of work with no test environment available. How can this be? Let’s just imagine that they work for a hypothetical large company with a ludicrously complex process around setting up test environments. I’m sure such things never happen in real life, but just go with me on this one.

Written by Published in Agile

They say that when all you have is a hammer, every problem looks like a nail. It’s the same in business – when all you have is a project management methodology, everything looks like a project. Most organisations have become very project focussed. Everything is a project. New release of software – project. Some process change – project. That’s great. Projects are good. They are certainly better than the ad-hoc approach we had before projects. But projects do have some drawbacks.

To work out what the drawbacks are, we need to look at what a project is. A project is defined (by the PMI who should know) as something that has a defined scope, a defined start and a defined end date.  So projects are finite in length. Anything without an end date isn’t a project, it's business as usual.

08 October 2013

Vision

Written by Published in Agile

Normally, the phrase 'project vision" or "project goal" elicits a collective groan from any team in which it is used. This is because project vision statements are generally... well... crap. Whoever puts them together inevitably feels it necessary to slip into management speak and string a bunch of fairly meaningless weasel words together – "we will proactively leverage our synergies to achieve outcomes consistent with our values...". Lots of words but no actual meaning. No wonder people greet them with a groan.

But at the same time, the team needs to have a cohesive picture of what it is they are working towards. They need to know what the goal is. More than that, the team will do much better at reaching the goal if they really believe that the goal is worthwhile. They need to see the goal as a thing to be desired, a thing to be strived for. What do we call such a goal? Well.. that would be the project vision, wouldn't it. This leads us to a dilemma. The team needs a vision to strive towards, but vision statements are so universally awful.

16 August 2013

Self Organisation

Written by Published in Agile

In the Agile world, we (and I am certainly no exception) talk a lot about Self Organisation, but what does that mean? What is this thing called Self Organisation?

Written by Published in Agile

Some agile teams do well. Many don't. In my experience, there is one consistent thing that separates the teams that succeed from those that fail and that is sound engineering practices. Foremost among those sound practices is Test First (or Test Driven) design.

Written by Published in Agile

The key to Agile and Lean methodologies is “the rapid delivery of customer value”. Anything that does not add value is considered waste. In Agile, value is often defined as “working code” but this is too narrow a definition. It assumes that the only stakeholders that matter are the end users of the software and that the only product the team needs to produce is the software.

Calendar

« August 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 29 30 31