Monthly Archives: May 2008

Agile: Like Fingernails On A Chalkboard

This is a post that I’ve had in my drafts for some time now, mainly because I’ve been trying to temper it’s message somewhat, having posted Agile Adoption – Just Say No the other day though I thought it was worth posting as a follow up as it relates to the last of the 3 points that I made.

Handling Polystyrene, somebody running their fingers down a chalkboard, two things that have always made me cringe. Well, you can now add the word Agile to that.

It seems that in my haste to see Agile adopted, I’ve not taken the time to clearly state to people why I see it as a worthwhile pursuit. After our recent reorganisation there’s even more talk of a move to Agile, we’ve got our own Agile Consultant, there’s even some people working on defining an Agile process. All good stuff.

Or perhaps not. There are some things to be really concerned about here, to desire to have, or to create an Agile process misses the point somewhat I think, there are plenty of good books out there which will help with a vanilla implementation such as Agile Project Management with SCRUM (Microsoft Professional)*, more importantly though let’s not pit Agile against Waterfall (for that is what is implied) – let’s not suggest that one is better than the other because there isn’t an argument there.

So what can we be doing, if not Agile, what should we be aiming for?

Well in my head it’s simple (some people might take the opportunity here to say that most things are…), we should be aiming to do the best job for our customers that we can. That’s a pretty vague and unsubstantial statement, to be more specific, if we’re considering delivering projects / products at an enterprise level, I think you need the following two things:

1. A Clear Governance Model

This serves two purposes, it ensures that the customer is getting sufficient visibility of the progress being made on a project, it commits them to the project in some way, it is a vehicle for communication with them. Secondly, it gives the team some parameters to work within, consider the Forming, Storming, Norming and Performing group development model which suggests that during the forming stage a team will meet and understand the opportunity and challenges that they are presented with. If we focus on the typical challenges faced by project managers I think it’s fair to say that attempting to work within the classic Time, Scope and Budgetary constraints is one of those challenges but we should also recognise that there’s always some movement on those and that in that the challenge is to operate within a set of parameters and in my opinion those parameters should be mandated by the governance model both from a tolerance perspective and a communication / escalation perspective. My point here being that how the team is delivering is not important to the customer nor in fact to the team initially, they should set out a set of principles by which they want to be driven (perhaps during the storming and norming phases) in each instance based on their knowledge of their environment and allow the practices that they use to evolve as their landscape changes around them.

2. A Culture In Which It Is OK To Make Mistakes

This may make some of you think, that would never work in an organisation but let’s face it (and be honest) we all make mistakes on a daily basis, it’s what you do about those mistakes that define you and your organisation. Now granted, you don’t create a culture, you build relationships and trust but as well as that, I think you need to build an environment of learning, one where you’re looking to continually evolve and that everybody’s committed to furthering themselves and others around them. All very easy to write about, a lot harder to actually implement and live by.

* I don’t necessarily subscribe to the opinion that Scrum is sufficient as an agile process in itself, I agree wholeheartedly with my colleague Matt Wynne that Scrum is a vehicle for introducing a change culture at an organisational level and like the stabilisers on a kids bike for a team – see the full post here.


Agile Adoption – Just Say No

Mishkin Berteig has posted an interesting article regarding what he considers the best agile practices to implement now, that is those that deliver the highest return on investment. After the recent reshuffle here I’ve had the opportunity to start to work more closely with a couple of our development teams which has been great.

I agree with all of the points that Mishkin makes, I would in fact add one to them, I think teams should be running Retrospectives from the outset, one of the fundamental principles certainly in Scrum terms is to Inspect and Adapt and it’s not until a team starts to learn to understand its’ own performance and has the desire to improve itself will they realise any value in what they’re doing. Retrospectives give teams an opportunity to reflect over their last iteration / sprint and indeed over the entire time that they have been working towards delivering the software, it allows them to see the improvements that they’ve made as well as the areas that still need some work.

As I get to spend more time watching and helping teams adopt agile practices though, I’m starting to distil further my own opinions on how to approach a so called adoption, I think this largely boils down to 3 things:

1. Understand Why

It’s a concern that so often I hear people talking about that fact that we’re doing this one agile or see people doing a sit down stand up (the clue’s in the title folks) just because they think they should be. Before you get started take a look at what you’re already doing; what is it that you think you could be doing better, understand why you think you need to change, you could perhaps even consider running a retrospective to gather some information first.

2. Be able to clearly state your vision for any change

If you’re going to make a change, I think you should be able to clearly state not only the reason why but the vision you have for how the change will be effected and most importantly where you’re aiming for. In that, I also think you should need to be able to measure how effective the change you’re making is. Discuss the principles that are aligned with your vision, I think the Lean Software Development principles are a pretty good starting point for a discussion round this.

3. Don’t use the word agile

This is a bit of a difficult one. If you’re going to change what you’re doing and even have any inclination to want to use agile techniques, don’t call it agile. Why? Well, for a couple of reasons; Firstly there are those people that you’ll come across that are naturally resistant to it and it’s better not to expose yourself to that pain in the first place and secondly, I don’t think that to be agile should be the end goal. Sure business agility will deliver a lot of benefit to your organisation which they’ll thank you for but agile isn’t necessarily the only way to achieve that. By constantly reviewing what you’re doing and aspiring to do it better at all times you’ll deliver huge value, Dr Deming’s plan-do-check-act cycle (on which agile is loosely based) should help you there as a framework by which to carry that out.

I’d be interested to hear what you all think, have I missed the point or am I along the right lines?