Mark Needham

Thoughts on Software Development

Does an organisation need to be fully committed to agile/lean/scrum?

with 2 comments

Alan Atlas has a recent blog post where he discusses agile, lean and scrum and suggests that you can’t truly achieve agility unless your company is fully committed to it which differs slightly from my experiences.

Alan makes a valid point that we’re not really following an approach just because we use all the practices:

Many people make the mistake of viewing Scrum and Agile and Lean as sets of practices. “If I do kanban, I’m Lean.” “If I do sprints, I’m scrummy.”

It’s quite easy to put our work up on a story wall, run a daily standup and unit test our code and not really get the full benefit that those practices are supposed to give us.

As I’ve mentioned before though I think it is part of the learning process that we start out focusing on practices and not principles.

However, at some stage we need to start thinking for ourselves about the value those are giving and making adjustments to them if we’re not seeing much value i.e. we need to look beyond the practice and to the principle or outcome that we are trying to achieve by using that practice.

The part of the post which is different to my experiences is this bit:

So I smile to myself (I think it’s to myself) when I hear management say things like “We’ll never be totally Agile in this company. There will always be waterfall projects.” I smile because what that really means is that they’ll never be Agile at all.

I haven’t heard conversations like this before but I think it is still possible to deliver software in a team working in an ‘agile’ way even if the rest of the organisation which that team operates in follows a different approach.

It won’t be as smooth sailing as if the whole organisation buys into the lean/agile approach and there will still be some reporting and bureaucracy that you need to deal with but it’s not a lost cause.

My colleague Lindy Stephens and a couple of others covered some of the issues around project governance in the enterprise in a ThoughtWorks QTB in Sydney last year. The slides from that presentation are available on slideshare.

If your company is not fully committed to agility then you won’t achieve it, and your results will be a self-fulfilling prophecy of unrealized potential.

Even if an organisation decides that it wants to be agile I think it still takes time to get used to the approach and it always seems to take a few successful deliveries to see that some of the worries that heavy weight processes and paperwork try to protect you against are not necessarily valid.

I’ve spent a lot of time being indignant that people didn’t buy into the agile approach but the more I spend time in different organisations the more it becomes clear that even for the people with the best intentions in wanting to learn this approach it will still take time to get there.

I’m coming to the conclusion that it’s a good thing that people have some level of skepticism because it forces you to really understand why an agile approach is more effective and then try and persuade other people of that.

It’s also helpful to note that it makes sense to vary our approach depending on the context that we’re operating in. For example if the team is distributed across different cities then we might have more written documentation than with a co-located team.

It’s very rare that an organisation or group of people will just ‘get it’ straight away – in many ways it’s quite an iterative/incremental journey.

Be Sociable, Share!

Written by Mark Needham

March 11th, 2010 at 8:05 am

  • http://weblogs.asp.net/garrypilkington/default.aspx Garry

    The management at my company don’t know the first thing about agile/lean, so we are certainly not an agile company. Having said that, I am slowly introducing the other devs to unit testing, code coverage and continuous integration. Hopefully bit by bit we can get the benefits of being at least partly agile.

  • Luke Stubbles

    Tools and practises are generally easier to teach and and easier to learn (not to mention measure), so many companies adopt them at a faster rate than the principles. This leaves a dangerous situation where you know how to use tools and practises but you don’t know why you’re using them.

    In this situation, teams will find it hard to adjust them to their unique project situation or understand how to challenge/adapt their use and thus continuously improve.