Agile Forest

Find your path to agility with Renee Troughton

What would 17 peeps do in a Jacuzzi you think?Ten years ago some smart guys got together to find what they had in common despite being to some extent competitors to each other. I like to think that whilst at The Lodge at Snowbird ski resort that they jumped into an extra large jacuzzi and sorted their differences to find their passions that aligned.

At the end of their bubble bath they had reached enlightenment and defined the Agile Manifesto and named themselves the Agile Alliance.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I was greatly anticipating hearing where the Agile Alliance group would say as part of their 10th anniversary re-union at Agile 2011 Salt Lake City. Admittedly my information was limited to second person discovery or tweets and I didn’t expect anything dramatic, but some contention or even one person standing up and having the courage to say ‘Hey maybe we could have fixed the wording a little to suit audiences other than software developers’ would have been good.

So for a lack of seventeen people taking the stance that there could be an element of imperfection (or dare I say it taking an iterative focus to constantly refine it) then I am going to give it a crack:

Manifesto for Agile Solution Delivery

We are uncovering better ways of delivering solutions and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working solutions over comprehensive documentation and meetings
Customer and team collaboration over SLAs, KPIs and contract negotiation
Responding to change over following a plan

Constantly reflecting and improving the way we work over following a process without understanding why

That is, while there is value in the items on the right, we value the items on the left more.

Why the changes?

  • Agile isn’t just for software development. It’s application has now broadened to include other areas of IT including hardware, services, process improvement and for a large number of people it is being applied outside of IT into other domains. I can appreciate its origins, but some of these origins are in Lean and blending Lean and Agile together has given us a really strong framework.
  • This framework has broadened the practices, techniques and tools that we use to implement Agile. Each month it alters a little and I think that is a great thing. I don’t see Lean broadening itself to take on other approaches. In some way it risks diluting the original purpose of Agile. In some way it can be debated whether this dilution means we are following Agile or something else altogether. For me, it is about bringing the right tools for the problem. I don’t care what it is called, but for the moment let’s stick with Agile being an umbrella term. The new added manifesto item for me is this constant refinement – not just of Agile itself but of how we apply Agile. I know it isn’t worded right, but the concept I am trying to get across is that we are dealing with Complex Systems and thus the only way to improve is through a reflective improvement framework. Alistair Cockburn said it best with his Oath of Non-Allegiance – it’s about finding the best solution for the current situation.
  • Team collaboration is just as important as customer collaboration, but I guess this could be covered off by the Individuals and interactions over processes and tools statement.
  • Only a small portion of the development community have any relationship or reference to a contract, so I expanded it to include SLAs and KPIs/KRAs
  • Change of wording for software -> solutions
  • Change of wording for development -> delivery
  • Addition of something about meetings. All too often I see teams complain about Agile because of the sheer number of meetings with perceived low value. Collaboration is important but not at the risk of reaching consensus perfection. Get your 80% value from the meeting and then shut it down.

Should the Agile Alliance take a step to re-write the Agile Manifesto?

If you are interested in other variants take a parody focus of the Manifesto for Half-Arsed Software Development or Manifesto for Software Craftsmanship.

P.S. Sorry for the delay in a post. Computer failure, followed by a cold, followed by a brief holiday, followed by many podcasts for Agile 2011 are poor excuses but I am using them.

2 thoughts on “Agile Manifesto take 2

  1. Renee, I am glad you are back. After listening to some of your podcasts, I was wondering if you had decided to make a permanent change-of-medium. (And I know about the cold thing… I am just rebounding from the flu and have not posted in over a week myself. My head is just not screwed on tightly these days.)

    One word that has always bugged me is “delivery”. It says more for me than “development” as you have suggested, but I have focused on our work offering solutions as promises we make our customers… so I moved maybe ten years ago from using the term delivery to using the term “fulfillment”, as in “fulfilling on our promises”.

    With respect to the manifesto, I am cautious to share it with people so they don’t get all militant and defensive about the agile approach. Right in the manifesto it says we value “Individuals and interactions over processes and tools”, but then we see people arguing with each other whether they are “doing” agile or not.

    In saying “I don’t care what it is called, but for the moment let’s stick with Agile being an umbrella term”, I interpret that you have a more pragmatic outlook… it is all about the solution, after all. So why is it that the manifesto that provides some solid rallying principles for the industry simultaneously produces fanatical purists who appear to value processes and tools over individuals and interactions???

    Sorry for the soapbox. I am glad you are back.


    1. Hi Ken,

      Thanks for checking in. I think your idea of fullfillment is a good one, I guess my concern is that you can fulfill a promise, but is it the right outcome? It is something I have been battling in my head recently – where perception is 9/10’s the law. If you are perceived to fix a problem but didn’t really does it matter if the customer is happy? The reality is no it doesn’t matter from a commercial perspective but in a perfect world the old Business Analyst in me says it does matter.

      The ‘Individuals and interactions vs process and tools’ one is a great debate and one that I battle with every day having a process analyst background as well. I have already made a post and a comment on a podcast regarding my hatred for people following chaos and labelling this ‘Agile’. But I can accept that working Agile comes in many guises and hence not all practices and techniques are applicable. It is a toolbox to be applied, but working your way throught the maze of right solutions is hard for a novice agilist. It comes down to being safe to fail and being allowed to make adaptation mistakes.

      What I love about the first manifesto item is that it really is so true. You can have a 100% perfect process, but if the team isn’t talking to each other and relating to each other at a most fundamental human communication basis then you will fail no matter what process is in place. People skills trumps intellectual skills when working in teams.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: