Agile Zone is brought to you in partnership with:

Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 557 posts at DZone. You can read more from them at their website. View Full User Profile

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

  • submit to reddit
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.

Published at DZone with permission of Mark Needham, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jeff Anderson replied on Thu, 2010/03/11 - 7:14pm

this whole idea that you have to be all or nothing agile in my opinion completely misses the point. And worse it restricts agile to a very narrow range of environments.

I actually don't really care if my clients become big A agile, as long as they are becoming more agile.

When I see people taking the time to actually adopt some of the practices and get good value out of them that I know that they are at least heading in the right direction.

 I agree with you that principals and doctors are very important, and I don't think that you can follow the practices for any good. Without looking at these principles.


but this whole all or nothing approach is really small minded


Alan Atlas replied on Wed, 2010/03/17 - 6:15am


 Great post. I can't find anything in there to disagree with.

Clearly I did a crappy job on my post if it led you to believe that I would have difficulty with anything you've said above.

The main point I was trying to make isn't one that you really address, which is the idea that in order to achieve its full benefits, Agile requires self-organizing teams regardless of the practices you choose. My experience is that it would be a very unusual company that could allow some of its people the respect and freedom to be on self-organizing teams but manage others in the traditional paternalistic, command&control way. I suppose it's possible, but I haven't ever seen or heard of it. 

So all I'm saying is that it would take truly amazing, elightened, skilled management to maintain both styles of management under the same roof, and so far, I don't know of anybody who does waterfall with self-organizing teams. Therefore, the existence of waterfall in a company will tend to squelch team self-organization, which in turn will reduce the benefits of any Agile implementation.

 I hope that makes a bit more sense.


Sindy Loreal replied on Sat, 2012/02/25 - 9:50am

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.