Tag Archives: agile

The Tool Trap

As a life long fan of technology and one privelaged to work within a high tech industry, it’s easy to get distracted by the shiny…

Technology is nothing but tools. When you consider that the people who are usually most passionate about technology are the ones in the agile camp, the proliferation of agile tools in the market place has a sense of inevitability.

It is also the most common mistake we make as practioners, certainly when we start down this agile road. Agile = Cool so we want all the shiny cool new tools. Preferably one written in Ruby (or Python or Haskell). With many rounded corners and buzzword compliance.

I think the reason why we fall into this trap, why we find it so compelling is because we’re technologists. At our core, we believe that given the right tools we can change anything for the better. This unflagging optimism is why I read too much sci-fi. On my first real scrum job, I immediately went straight for the throat and tried to find the right tool to get this scrum stuff embedded into our development process ASAP. I believed that the tool would help us ‘do it right’. Turns out there is a word for this belief: Technicism

And I got it precisely wrong.

Agile adoption is a change process, and change is hard. We all too easily use technology to hide from change. My problem with most electronic scrum tools I’ve seen, is that it is all too easy to use them to hide the valuable stuff that help us to manage the change. (Maybe if we had the technology where all our walls were display screens that were also touch-sensitive it might be different.)

Change is also about humans. People. We’re complicated beasts and slow to change. So the best thing to use to bring that change about is the base instincts. For example, we’re social creatures. That means that the most important influences on our behaviour can be found in our peers. This is a function of our evolutionary history. So use the peer pressure to help drive behaviour. A visible example of this is the daily stand up.

In a recent conversation with a much wiser man than myself, Peter offered the not entirely surprising insight that most agile teams which move from a physical (cards, sticky notes, scrum boards) to an electronic one, usually go back to the physical. I believe that there is a sinister conspiracy at work: Scrum is in fact a 3M marketing ploy. The insight that I get from this is one that is easily lost in a cubicle farm. Making software is a social activity, and the technology we use to communicate is a poor analogue for our evolved communication patterns. Alistair Cockburn has a graph which illustrates this wonderously. In fact go read his talk while you’re at it.

So what I have learned is that this agile stuff, works a whole lot better when I step away from my identity as a tool user / maker. In fact I get a warm fuzzy feeling whenever I see my team in front of our scrum board…

Advertisements

Hero-Driven Development

I feel like I may need to start this post by paraphrasing a song: “You’re so vain, you probably think this post is about you.”  I have had the privilege of working with some remarkable technologists during my career and the danger is that they misinterpret what I’m about to write about. Steve McConnell calls them “10X Developers“. They’re the ones who can produce code at a rate of 10 times that of the average. Every software company would like to employ them, and some believe they do.

What I’ve started to notice is what amounts to an organisational anti-pattern.

Anti-Pattern: Hero-Driven Development

http://www.flickr.com/photos/roby72/3345955051/

Captain Squarejaw to the rescue

Problem: Whenever some gnarly problem raises its head, the Hero is sent to fix it. The team sit back and let the Hero work, maybe watch what The Hero is doing. The Hero fixes the problem (slays the dragon) and the team gets back to doing what ever it was they were doing till the problem was discovered. The Hero flies off into the sunset.

Context: The team has hit an impediment which is within their theoretical skill base but without the experience or resources to fix the problem. The person accountable for delivery is panicking. The team is thrashing and seem to be getting no closer to a solution. Someone lights the signal for The Hero who swoops in to save the day.

Forces: Every software development project is a hostage to budget and schedule. In this context it makes sense to solve the problem as quickly as possible. But this is inevitably a short term fix; depriving the team of the opportunity to learn from failure and pain means that their growth will be stunted. The team’s ownership of their work diminished. In the worst case scenario it can lead to a loss of confidence and morale. There is also the danger that over time, the threshold of what is considered a problem will decline. The perception could evolve that the Hero gets all the interesting work. And worst of all, that any work done by The Hero is immune from scrutiny.

Solution: Trust the team. This is their problem, their mess. Support them where needed, get them expert help, but make sure that the team does not lose ownership of the solution. The Hero can still step in to help the team solve the problem, but the difference is in how the help is evaluated and used by the team. This is an act of collaboration and not an act of salvation. It is vital that the Hero be seen mainly as a ‘consultant’ to the team, whose output should be mainly advice. If The Hero is writing code, it needs to be dealt with in the same way as any other developer’s code. It should meet the team’s “Definition of Done”. And ideally, it should be reviewed publically so that the team can learn from the event and hopefully improve (Inspect and Adapt). It is better as a longer term strategy to have a team of heroes than to depend on a single person to solve all your problems.

Note, I am not concerned in this post with primadonnas or those who don’t share their knowledge. This is not the true Hero. If I had my druthers, I would fire those people from any organisation I was working for. In my experience someone who is trying to make themselves indispensable in an organisation deserves to be shown the door; they are acting for their benefit and not of their team mates or company.

Orlando Gathering

For those of us not lucky enough to be in Orlando right now, the Open Space findings are being captured at:

http://scrumorlando09.pbwiki.com/browse/#view=ViewFolder&param=Orlando

Presentations are also being published to the Scrum Alliance site at:

http://www.scrumalliance.org/resources?tag=SG+Spring+2009