Wednesday, January 12, 2011

Shouting is not an agile value

The Agile Manifesto is well known:

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.

Related, but perhaps less well known is the idea of Agile Values. Their origin lines in Extreme Programming, with there being five recognized values as of the second edition of Kent Beck’s Extreme Programming Explained.

In brief the five values are:
  • Communication – amongst all on the team
  • Simplicity – of design, emphasizing ideas such as implementing the simplest thing that will work and the acronym YAGNI (you ain’t gonna need it)
  • Feedback – feedback from automated tests, from the customer and from the team
  • Courage – to keep things simple, to implement only what is needed today, to refactor and throw away code that’s no longer needed
  • Respect – for other team members, for the customer

The fuller definitions can be read on Wikipedia (or of course in Kent's book).

One blindingly obvious thing you’ll notice is that shouting is not an agile value. Never was, never will be.

Well duh!

So why do I mention this? Oh well, you know. It’s not like there aren’t some managers who use that as a “technique” for trying to get what they want. It doesn’t necessarily have anything to do with agile, although regrettably I’ve seen it (and once done it myself) in response to somebody just not getting our new technical practices that came along with the agile adoption.

In my case it was due to extreme frustration with somebody who seemed almost perversely reluctant to commit code to the source control system. He was passing around changes to other colleagues by emailing them Java source code. This wasn’t the first difference of opinion about developing software I’d had with the gentleman in question. He harbored some curious ideas and was not enjoying our change over to Scrum.

I confess I rather lost the plot as we were there in the office late at night desperately trying to make sure the team made their sprint commitment. I blurted out rather loudly “What the $#@! are you doing?” I did quickly apologize and later after we’d got the job done we went to dinner and made up. I’m not proud of that moment and it’s not a “technique” I ever intend to use again.

Nonetheless, there are folks out there of a more strident nature inclined to use it far more frequently. I don’t know if their threshold for frustration is lower than mine or if they just need an anger management class or what the deal is. Suffice to say though, as an approach to trying to coach staff into doing what you want it’s not a winner. Indeed it’s a completely toxic behavior. Even if Mr or Ms. Shoutypants has great ideas people are very unlikely to ever “hear” them because they’ve written him off as an aggressive belligerent asshole.

Patience. Now there’s an Agile Value. In fact it’s a key one I believe. Stimulating, inspiring, managing and maintaining the change to agile practices takes effort. It takes leadership. And it takes patience. And so I propose that we add to communication, simplicity, feedback, courage and respect the value of patience.

1 comment:

  1. In an ideal world there would be no need to shout but sometimes I can understand it when the whole team have given up working with someone because they are being obstructive. In this very rare circumstance I have once seen shouting work as the method of last resort.

    It is a pity but then again maybe those people are just not team players.