Sunday, June 05, 2011

What agile means to me

[Update: in response to some of the comments here and on HN, I thought it might be worth updating with a note on my personal experience with Agile, which appears at the bottom of the post.]

Agile (with a big 'A') has become so mainstream now that it has started to become the problem. An alarming number of people who espouse the virtues of Agile, and who quote the Agile Manifesto believe that Agile is a project management methodology, and that Agile really means SCRUM, XP, Kanban, and that it is embodied in the daily stand-up, whiteboards or writing requirements on post-it notes. I was once told by an Agile Trainer (LOL) that the correct way to phrase the requirement "we need advertising placeholders on the site, and some way to manage which ads appear where" was "As a User, I wish to be marketed to." Needless to say his company lost a $m project on the back of such BS.

As a result of all this, Agile (big 'A' again) has become a bit of an albatross - it doesn't really work, it doesn't deliver the benefits it promised, and it inevitably involves a lot of arguing amongst the team about who should be doing what, and when.

All of which distracts from the fact that agility (small 'a' this time) is a wonderful thing, that can be achieved, that does provide enormous benefits, and that should be encouraged in everything we (as an industry) do. Agile (small 'a') refers to team dynamics, delivery processes, the software itself (how easy is it to change), and operations. Everyone should aim to be agile.

So, a few lessons I've learned along the (hard) way:

  • The best way to achieve your goal is to start with the right people
  • If you've found the right people, let them get on with the job you're paying them for
  • The people with the best ability to plan the delivery are the people doing the work
  • A small team with a manageable backlog needs very little Project Management
  • Everyone on the team “needs to know”.

A few things that help this happen on a practical level:

  • Try and avoid building towards a pre-determined marketing / launch date
  • If you do have a fixed time, then scope is variable
  • Never try messing around with team sizes to massage delivery
  • Automate everything in sight - builds, deployments, testing, progress reporting, tea-making
  • Measure as much as you can - no feedback == no direction

And finally some other things that will prevent you from getting there:

  • If you have to have everything on your requirements list, you can't be agile
  • If you need to plan beyond the next sprint with any degree of accuracy, you're not agile
  • If you think you can "fix" an iteration by adding more people, you're not agile
  • If you are prepared to change the end date of an iteration to "fit something in", you're not agile
  • If you have to give a fixed date for delivery - it's very, very difficult to be agile.

Postscript: my personal experience with Agile.

I worked for several years at a company that was at the forefront of the Agile movement in the UK, and I believe that at one point they had more registered SCRUM Master practitioners than anyone else in the country. (I think Sensai Schwaber visited in person at one point, although I’d left by then.) They were generally acknowledged to be the leaders in the field.

The incident in the post occurred when I returned to the company as a client, parachuted into a large project that they were running with the full SCRUM toolkit (“Agile Coach” included), that was running into trouble, principally the fact that it was not agile. The project was rescued by hiring a team of people with the right combination of aptitude & attitude.

As I say in the post – agility is a great goal, and everyone should aim for it – but don’t make the mistake of thinking that Agile is the means to achieve it.


SimoneC said...

There is no set of practices that let you do the last point, many "processes" promise you that but they can't deliver on that promises.

The problem is the well known :) unknown unknown that gets on the way...

So the best set of practices are the ones that remove the assumption that you can predict the unpredictable and let you adjust 'the plan' on the go

Rob said...

I more or less agree with all your points. I've seen exactly the problems you've laid out.

I love how you split things up into small 'a' and big 'A' agile. I might have to start using that.

L said...

Agile (uppercase 'A') is exactly as you describe in lessons learned. I believe at the root of the misconception(s) of Agile are 'Agile-elitists' who try to sell the framework in a one-size-fits-all approach. Agile is meant to be agile (lowercase 'a') and adaptable to each environment, product and style of work.

Sure there are fundamentals like the daily stand-up, product backlogs and requirements as user stories, etc. However, when those things become roadblocks in and of themselves, a mature team removes the roadblock and continues work.

Scott said...
This comment has been removed by a blog administrator.
Jeffrey said...

No methodology can survive internal sabotage and that includes Agile. With team members arguing every day over who does what and when, I'm not surprised the team failed. Calling a group of people a team doesn't make it true. A team is composed of people who have a clear understanding of their individual roles. Without that, the group has little chance of succeeding using any process.

Hugo Rodger-Brown said...

@L - I think the critical word in your comment is "sell" - it's turning agile into a product that has led to people abusing the term.

@Scott - whilst you are correct that seeing an albatross used to be considered good luck, it can now be used to refer to a burden / curse -

@jeffrey - nearly every team I've seen that attempted to follow a strict agile 'process' ended up arguing about it, precisely because a rigid framework is not agile. It's the misguided execution of Agile as a methodology that causes the team to fight, not the other way round.

arsenalist said...

With regards to the requirement example you gave, I agree. People get caught up in trying to strictly adhere to a rule that is supposed to be general, and lose sight of the actual task.

If you have the personnel who can decipher a broad requirement like the one you mentioned and then construct the underlying backlog items, great, but problem is that there aren't many of those types of people around.

In the end, you have to think in practical terms. If something doesn't feel right but you're going along with it just because it's supposed to be "Agile", then it's probably wrong. Trust your gut instinct.

Benny Hertach said...

I would say your conclusion is the same as what the original Agile Manifesto 10 years ago suggested (especially the sentence at the end):

"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."

L said...

Hugo - I'm not sure what you're exposure is to Agile but I've entertained similar sentiments from others and found the following to be true each time.

These people;

- have limited exposure to Agile, often 1-3 projects attempted or 12 months,

- weren't fully committed to the implementation of Agile practices,

- didn't know what to expect beyond the increased benefits and

- gave up before the benefits could've been realized.

There are many factors that contribute to failure. This is why we promote 'fail fast'. In each failure the team is expected to learn and recalibrate. An immature (loosely used) team is not expected to be able to do this by themselves. Mature teams "smell" the failures from far and prevent them from happening. Smells become the Agile response to Risk Management.

My suggestion would be to find a Coach (non-elitist) that can guide you through successful implementation.

Joe Crockett said...

When "A"gile became something that a company can standardize, market, and sell, it instantly became less "a"gile. "Agile" as a way to deliver software is needs to be able to try, fail, innovate. As that innovation occurs it adds to the toolset.

Jeffrey Harrington said...

This is definitely a fair criticism and I agree with almost all your points.

However, I generally prefer the story style ("As a user, I want to achieve this") way of stating basic requirements. It not only gives context but helps focus on the "why" rather than the "how".

When my team doesn't follow this style, we end up with requirements that are either too short/vague ("Revise score weightings on report") or are way too long/crazy (insert 6 paragraph garble).

Stories alone, though, definitely aren't enough. I think one thing that is missing from the agile teams I work(ed) with are consistent, documented acceptance tests.

In any case, good post, Hugo.

flopez said...

Hi, good article.
I'd advise them (Agile with big A) to read this book:

Agile and Iterative Development: A Manager's Guide

Matth said...

I've found that people who didn't lose weight using the Fad Diet Plan had four problems:

- limited exposure to the Fad Diet Plan, often only 1-3 dieting periods attempted or 12 months

- weren't fully committed to the implementation of Fad Diet Plan practices,

- didn't know what to expect beyond the increased weight loss and

- gave up before the benefits could've been realized.

sebs said...

Recently i find XP lots more attractive to teach people the Agile thingie. Less dogmatic and more a kind of a toolbox.
Start with the Values and not Roles or Practices, leave out the agile manifesto in the first try and go to the principles. This is more than most people will need for living in a softwareproject in one devs life.

Hugo Rodger-Brown said...

@L I've updated the post with a disclaimer on my personal experience with Agile - I'm pretty confident that spending time with an Agile Coach will not aid my understanding of the process.

Anonymous said...

So, a methodology becomes successful, people pervert the methodology or implement it incorrectly, and the methodology is to blame and we should thus rebel against the original stated intent? Why not just correct the incorrect? It seems incredibly intellectually dishonest to flee from a stated ideal rather than defend it from subversion by the inept.

Jason said...

Great post.
I too aspire to little(a) agility, and am sick of the quackery of big(A) Agile.
I'm trained and practiced in PMBoK and Prince2 practices. Little (a) agility can be instituted very effectively into these frameworks and processes.
But my experience is those that spruik big(A) Agile, are usually half-arsed project managers that cant plan beyond their next breakfast, and are using Agile as an excuse not to try.

Randall said...

A personal coach and a book to explain and implement a process? FAIL. I think no matter what process you use your ability to execute it within a team marks it's success.

Personally I prefer to think of any of these as "tools" in our toolbox. What works for one project, team or company may not work for another.

Thogek said...

The thing to remember is that Agile is little beyond a vehicle for becoming more agile. Those who get too lost in the tools or in the "purity" of big-A Agile itself can easily lose track of that, and end up getting little-to-nothing out of their loyal Agile-devotion. Those who remember that, and value agile over Agile, using Agile to the degree that it promotes agile, can get a lot out of smart, thoughtful and consistent Agile processes and behaviors.

It's the classic problem is over-valuing the tool or the methodology over the goal it's supposed to facilitate. One's a tool, the other's the tool's goal. Don't confuse the two, or you'll end up with neither.