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.

Tagged , , , , , , , , , ,

6 thoughts on “Agile: Like Fingernails On A Chalkboard

  1. […] – Just Say No the other day though I thought it was worth posting as a follow up as it relat isn’t everything UEFA NewsWhat is a youth coach’s priority ?? development of players or […]

  2. Gilles Ruppert says:

    I absolutely agree with your last 2 posts. The current project I’m working on has embraced agile, with a coach etc, and as developers we really like this.
    It is great to see that you can feed back to your client and adapt to the project on a regular basis.

    The main problem I’ve had with agile is the ‘religion’ around it & how some people see it as the ‘silver bullet’ that solves all development problems. Also: clients jump on it & I hear comments like ‘we completely changed our minds, but we’re allowed since we are “agile”‘, without recognising that each change still bears a cost.

    Educating the clients about agile seems to be the most difficult aspect IMHO!

  3. danrough says:


    I’ll put a copy of this response against the post any way so if you feel inclined feel free to carry on the conversation there but if not I’ve copied it below.

    You make some interesting points, which I think boil down to essentially one thing, that in our haste as a development community to see “agile” adopted we’ve not realised that we also need to manage what is in actual fact a very big shift in the way in which we want to engage with our customers and indeed other disciplines within the development arena (e.g. Business Analysts) and therein why we’re doing it and what the benefits are as we perceive them.

    It’s very easy for us to say that we’re going to develop and deliver software in a certain way, it’s an inevitability though that we will hit a brick wall at some point in terms of progressing this any further without educating the customer as you say.

    Cheers, Dan.

  4. Gilles Ruppert says:

    Agreed. On a positive note: we recently finished the 1st phase of a project & it went really smoothly, with hardly any overtime at all. Good thing is that our TPM is always reigning us back in (esp. the client) when we try to go overboard/fall back into waterfall.

    Still: educating the customer is very important (which we are trying to do) & implementing all the goodness of Agile in big companies where processes can be lengthy is a challenge at best. Speaking to other developers in other big companies, I can only come to the conclusion that the implementation of agile is really on a per project base & needs to be constantly adapted to satisfy the needs of the project. There is no ‘One’ solution.

  5. danrough says:

    Right, which was my point, (which I might not have articulated all that well), applying a process is just applying a process, whether it’s agile or waterfall, it’s ignorant to the fact that most people on development teams want to do a good job. Give those teams the ability to be able to define how they think they can do that and let them know the parameters you expect them to be able to work within and let them get on with. BUT be there to support them if they make a mistake to ensure that they learn from it and don’t make the same mistake again.

  6. […] posted a while ago about the fact that I thought that all a team needed to be successful was a clear set […]

Comments are closed.

%d bloggers like this: