Tuesday, December 11, 2007

XP Day: Agile is a brand

An interesting truism from XP Day's final session, Have We Lost our Mojo:

"Agile is a brand."

If it is, then it must have some kind of value. Therefore it is worth protecting from second rate imitations.

Schrodinger's bug

A bug does not definitely exist or not until you exercise the code.

You can either let your users find it, or you can write tests to flush it out.

It's your call.

Monday, December 10, 2007

XP Day: Have You Compromised Your Agility?

One of the more interesting sessions I went to during XP Day this year was the "Have You Compromised Your Agility?" session run by Gus Power and Simon Baker. Run in World Cafe format (complete with tablecloths and candles!) it set out to create an informal environment to discuss whether corporate attitudes are forcing agile and lean thinkers to compromise a step too far in order to become acceptable to traditional corporate culture.

OK, I admit it. I was a plant. No I wasn't quietly photosynthesizing in the corner, I was invited there by Gus and Simon to be deliberately provocative, forcing difficult issues out into the daylight. My table was focussed on "Values". Specifically, the premise was that some organisations have internal Values (and hence behaviours) that do not permit agile processes to develop and prosper but instead force them to mutate into grotesque, ineffectual parodies.

The reactions were interesting. On the one hand there were a handful of aggressive ad hominem challenges. "Who was I to question what a company calls 'agile software development'?" "Who was I to question the value of bug ridden software to the customer?" "If I couldn't work with the status quo of a company then I should be the one to get out rather than try to change it" (even if I had been paid to come in and coach/mentor!). And so on. I was genuinely shocked at the ferocity of some of these challenges, especially since they were targetted at a personal level and entirely missed the points being made. Perhaps I was being a little too provocative at first, but I obviously touched a raw nerve....

However, most of those involved recognised the issue many having experienced it first hand. But there seemed to be a general inability to address the fundamental problems. No-one seemed to feel suitably empowered to do anything. In some cases the deeper problem was justified by external pressures (delivery date being a common theme - "do whatever it takes to meet the date and functionality and to hell with the quality/risk"), others did not feel that they could make the changes needed alone (which is not surprising - people will not change unless they want to change). Only one or two said they would go back and try to change things.

So was the session useful? Judging by the feedback received by Gus and Simon, the answer is a resounding "yes". Did I find it useful from my position as a hired hand? Yes - I got an interesting insight into the current state of the agile nation from people who are in the trenches and trying to get things done using agile/lean thinking in what is sometimes an extremely (sic) hostile environment. Yes, agile is adapting for best fit. But the session confirmed my worst fears that in many cases it is being forced to adapt a step too far.

Thursday, November 29, 2007

Planning Poker Cards Prototype Deck

Finally.... I have finished a full suit of Thirsty Bear Software Planning Poker cards:

OK, it's still a prototype built from laminated pouches, inkjet printouts and a lot of patience, but they make a huge difference to the flow of a Planning Game. Even using a small subset (0, 1, 2, 3 and '?') has a significant impact by removing the "follow the leader" behaviour that conventional planning encourages.

Now to find a printer that can supply a small run as "real" playing cards.....

Tuesday, November 06, 2007

What's in a name?

I think I might have stumbled upon a better name for what I was originally calling "faux agile".

"Cargo Cult Agile" seems to convey the sentiment far better by linking it to the cargo cult religions around the world. In short, it's when a team/organisation blindly adopts agile practices without really understanding them in order to get benefit from them.

I picked it up from an XP Day session description, but it has appeared elsewhere as well (drop me a line if you believe you invented the term, and I will attribute the source). I only wish I had thought of it.....

Wednesday, October 10, 2007

Continuous Improvement

An interesting insight into continuous learning and improvement from Brian Marick:

"At the end of each iteration, each team member should be able to say why she is worth more money to her employer than she was at the beginning

Can you put your hand on your heart and say that you are improving yourself every two weeks? It's certainly something to aspire to.

Saturday, September 29, 2007

Agile teams should be like a bowl of thick custard...

No, I haven't lost it. After seeing some interactions recently I think it's safe to say that a successful Agile Team can (and should) be "dilatant".

Be open to well thought out changes that obviously improve productivity, but push back against fast, ill thought out, knee-jerk responses, and also politically motivated decisions from outside the Team that compromise working values.

Take inspiration from your bowl of custard and get your just desserts.

Tuesday, August 07, 2007

TDD is an approach, not a task

Tim Ottinger has written an interesting entry in his blog about test driven design.

His mantra? "TDD isn’t a task. It is not something you do. It is an approach. It is how you write your programs."

Couldn't have put it better myself!

Monday, July 30, 2007

Come and join our agile team...yeah, right

I have recently been invited to join a(nother) "Agile Team" as a senior developer rather than coach. You might have already gathered that I am becoming increasingly sceptical about these claims having been caught out before.

I have no idea whether the latest offer is truly agile, or faux agile, but it got me thinking. What am I looking for in an Agile Team before I can join it while feeling safe enough to leave my coaching hat at home? Here are my initial thoughts:
  • fixed, short iterations with regular retrospectives
  • story based scope specification with a suitable Customer involved with the Team
  • regular replanning based on real, measurable progress
  • full integration of QA within the team
  • test coverage greater than 80%
  • regular (ie multiple times per day) automated integration testing
I'm sure there are more but these seem to be the essentials that are most often missing.

If you can't check these basic boxes then please have the courage and wisdom to recognise that something is wrong and get help!

Friday, July 20, 2007

Teaching pigs to sing....

"Never try to teach a pig to sing. It wastes your time and annoys the pig" (Robert Heinlein, Time Enough for Love)

When trying to become agile, Team members
quickly tend to fall into three main categories (the percentages are purely based on my empirical observations and should not be seen as set in stone or based on scientific study!).

10-20% will "get it". These are the guys and girls who will be able to use the techniques to learn from their mistakes, spread their wings and perform. They are the future of the new, agile Company.

60-80% don't "get it", but are willing to try, or at least toe the line. They need more guidance about how to work efficiently, and that things are OK. They need more reassurance that the Team does not need this, that and the other supporting items (eg the massive Big Up Front Design documents, or a full specification signed in triplicate). With careful nurturing some people in this bracket will "get agile" (and trust me, the lightbulb moment when they do is one of the most satisfying moments of any Coach's career...). However those that don't really understand the principles do follow the basic ground rules and are not actively damaging to the agile process or the Team as a whole. In fact gentle pushback and respectful challenge from people who don't fully understand is healthy and productive.

10-20% of the Team don't "get it", will never "get it", and in fact really, truly don't want to "get it". These people are the biggest danger to any agile transition since they are not always obvious but will actively undermine changes to the status quo. More obvious behaviours that I have witnessed have included aggressive, disrespectful and/or unecessary challenge, refusal to adopt new working practices agreed by their Team (including themselves!), continuing to use old heavyweight processes in addition to the lightweight replacements, refusal to engage with the Team as an equal member and so on.

Anyone falling into this final group can cause huge amounts of damage to any agile Team but this damage is multiplied in a fledgling agile environment since the result will be bad decision making in order to placate someone who has no interest in working smarter.

So what to do? A difficult decision needs to be made but ultimately the damaging disruption has to be neutralised as quickly as possible - usually the easiest remedy is to transfer them from the agile Team to one more suited to their skills and temperament. 

Alternatively you can keep trying to educate...how are you at giving singing lessons?

Friday, July 06, 2007

"I wouldn't start from here"

There’s an old joke that goes something like this:

“A driver is lost in the darkest depths of the countryside trying to find his way back to the hotel where he is staying. In desperation he pulls over to ask directions from one of the locals. “Excuse me”, he says, “Can you direct me to the Hotel please?”. The local looks at him for a moment, sucks his teeth and says “I wouldn’t start from ‘ere, Bor’”.

When switching to agile processes there is a temptation to not “start from here”, but to try and create a sort of alternative reality before you start where it will be easier to migrate to the new process. This misses the point.

To “be agile” you need to
  • Have the honesty to recognise where you are right now
  • Have the courage to admit where you are, warts’n’all
  • Now fix it one step at a time
  • Repeat...

Tuesday, June 12, 2007

Cruise Control health meter addendum

A while back I pointed out that high performing teams tend to break their automated build. This might be misconstrued, so to clarify the point.

A successful, productive Team will inevitably discover unexpected issues that will break the build. However this does not make breaking the build acceptable so do make sure that this message is reinforced albeit gently and with good humour, for example with silly hats or similar.

Thursday, June 07, 2007

Travelling Light

I like to travel light. I hate carrying things, especially big, bulky laptops. But as part of my work I need to take notes, and also have access to a range of reference materials that can be used to help some Teams to understand what I am explaining - slideshows, summary documents etc can help get the agile message across. The problem is I often don't know that I need a specific document until I need it. I also have a (growing!) backlog of blog entries that need thinking about and finishing - it would be nice to be able to work on these when I can wherever I am but without the encumberance of a laptop.

In order to solve this 'write once access anywhere problem' I have been playing with the online storage service provided by Omnidrive to provide a central location for data I use regularly and "in progress" documents. The system integrates Zoho Writer with the storage so documents can be edited online anywhere - but also they can be posted to a blog. This looked promising except the version of Zoho integrated with Omnidrive won't post to Blogger.

Yet all is not lost! Zoho also host documents, so it should be able to store work in progress online to be picked up later and published from anywhere.

The proof as always is in the actual doing rather than the talking (we value working software over up to date documentation, remember). So hopefully this experimental entry will publish to the blog in one piece...!

Wednesday, April 18, 2007

Understanding Agile, Take 1

To the optimist the glass is half full.
To the pessimist the glass is half-empty.
To the agilist the glass is twice as big as it needs to be....

Tuesday, April 03, 2007

Cruise Control health meter

I use Cruise Control. It’s my automated build weapon of choice. Why? For no other reason that it was the first one that I got my hands on. I (mostly) understand it, trust it and know its quirks and foibles.

It also has a neat feature – it shows project metrics. These are shown as pie and scatter charts displaying successful and unsuccessful builds. Both of these provide useful indicators about the health of a given project.

Taking the scatter chart first. This is a calendar with day on the X axis, and time on the Y axis. A dot is placed on a calendar every time there is a build – red for fail, blue for success. From this you can get a feel for the following:

  • How many checkins are being done per day
  • How successful they are
  • How long a build stays broken
  • Whether the Team is staying unusually late or coming in at weekends

All of these are useful indicators as to how things are going in general. I look for regular checkins during standard working hours and fast recovery from breakage – and I encourage the Team to investigate if this pattern is broken. All fairly straightforward and uncontroversial in the agile world.

The pie chart does something similar – it shows the proportion of broken to successful builds in isolation. Not necessarily as useful as the calendar scatter, or is it?

I have noticed an interesting trend with the pie chart in Cruise Control. At the moment it is nothing more than a gut feel or rule of thumb based on the observation of several teams, and I certainly have no data to back this up….but successful, dynamic teams appear to break somewhere between 15% and 25% of builds.

Shock! Horror! Agile teams break the build!

Well, yes. Breaking stuff unexpectedly is how you learn and improve. It is also the motivation to fix structure and design. So the point I am making is: Yes, teams should expect to break the build once in a while and question if they are not. It would seem that somewhere around 20% is the sweet spot where the Team is behaving optimally. Much more than this and something is going seriously wrong. Less than this and there is either not enough refactoring pressure on the design or the design is almost perfect (I know which of these I would suspect initially).

"Learning is not compulsory" - The Dangers of Faux Agile

I am noticing a worrying trend amongst companies wanting to take advantage of the perceived benefits of the Agile Revolution – specifically the faux-agile project. These are projects that have stamped themselves as “agile” but do not adhere to even the most fundamental good practice. When you scratch the surface they do not continually build and test, nor do they actively refactor bad design out. Unit tests are at best given lip service, and coverage is low. In most cases the only nod towards anything remotely agile is the lack of unnecessary – or indeed any –­­ documentation.

When asked, the excuses for the shortcomings are many and varied – “We know the structure of the software is awful but we don’t have enough time to refactor it right now, but we will get around to it later when we have more time” (yeah, right…), “Our Company culture does not allow the Quality Department to be integrated into development teams”, “We don’t know how to implement the automated build”. The list of excuses given by faux-agile apologists to explain away their inability to address core agile principles is endless. And yet when the proverbial hits the fan and the project is not delivering, someone always has the audacity to claim that it was the agile process that failed! In reality the Team was using that time-honoured (but dishonourable) process called hacking and hiding it behind the Agile flag of convenience. I am sure I don’t need to expand on the potential damage that this can do the the Agile cause.

So why are these pseudo-agile projects becoming more common? First of all I am convinced that it is not deliberate dishonesty – all the members of faux-agile teams I have met and worked with are genuine, honest software developers. Some have even convinced themselves that they are following the Agile Manifesto.

So if it is not deliberate subterfuge, what drives these behaviours?

My opinion is that it derives from the interaction of several issues.

  1. The cost of initial implementation of agile. Kicking off (or converting) a project to ‘agile’ requires some up-front investment. Setting up an automated build machine, defining an acceptance framework, educating the Team in agile process and so on.
  2. Management cynicism. I believe that Management in general is still suspicious of agile methods because they transfer a significant amount of power from the manager to the development team. Add to this any significant cost of implementation (including development down-time), and a pinch of failed previous faux-agile projects and suddenly the tension rises – “Why should I, a traditional manager, risk losing a large amount of budget on an experiment like this? You can do it as long as I don’t see any downtime or schedule slip”.
  3. Lack of understanding of the “Agile Way”. When a Team does not fully understand the holistic nature of an agile process, they will be tempted to cut corners and only implement specific parts, leaving the rest “until later”. This is especially true if they are under pressure to put it into place with no downtime or schedule slip. This is a direct consequence of skimping on Agile training – buying the Team a copy of Extreme Programming Explained does not usually magically make the Team agile…

And so the Team begins to stray towards the dreaded Whirlpool of Doom….not all the framework is in place so the Team works a bit harder to make the process work which means they don’t have time to fix the framework which means they have to work a bit harder which means they have even less time to fix the framework….

So how can we fix this? I would suggest:

  1. Companies must begin to recognise that “agile” is not a silver bullet. It is an alternative way of developing software, and as such it does have a high risk of failure if not installed correctly. As such it will have a cost of implementation. This will involve proper training of the Team and Management and Customer. It will also involve the setting up of the infrastructure – automated build machine, acceptance test framework and so on. The exact cost depends entirely on how close to the agile ideal you are before you start – in other words how far away you are from your destination.
  2. As with any major change, give the Team space to make initial mistakes. They will be better and stronger for it. Give the feedback process a chance to work. Enable the Team. Let the Team learn.
  3. Don’t be afraid to get help! This is not simply a sales pitch for the Coaches and Mentors out there (myself included), it is an observation from the trenches. There are many guys (and girls!) out there who have “been there, done that, got it wrong, then got it right”. Some have decided to share their knowledge to help your Team avoid the mistakes they made initially. The right Coach will set up the Team and leave it in a state where it can be used to seed other teams later, ultimately making your Company self-sufficient in agile training. The short term cost outweighs by far the long term benefit of getting it right.

And what if your Company is not prepared to adapt and implement agile process in a responsible manner, instead insisting on perpetuating the faux-agile anti-pattern? The best advice I can give is to ponder a quote from Lord Deming – “
Learning is not compulsory... neither is survival”.