Thoughts from a Thirsty Bear

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.

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.

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

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

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

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.

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.

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!

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

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

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

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.

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

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

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

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