I can haz agile certification?

Via various convoluted routes:

Become a Certified Agile Software Specialist!

Update: the link is now cobwebbed, but if you did the original then please get in touch!

Something to ponder

If you get an infinite number of non-test-driven developers programming in a room for an infinite amount of time, would you end up with the works of Shakespeare?

What is this software craftmanship thing anyway?

There's a buzz in my tiny corner of the industry at the moment. "Software Craftmanship". But what is it exactly?

I for one am not sure. Currently it seems to be all things to all people, but with a common theme of quality running through it. Some think it's fairly hardline, others think it needs to be flexible and all-encompassing. But one thing it's not - it's not just about agile or lean processes and practices (although personally I think they are a significant step in the right direction). So what the hell is it? Here's an attempt at defining what it needs based on existing professional engineering and other disciplines that could be considered craftmanship (for example, carpentry, surgery, architecture/building and so on).

• It needs a set of ethics. This is what keeps you honest and provides a structure on which you can base decisions. Ethics tell you when to walk away when you are being asked to compromise too far. They provide the line in the sand that you do not cross. In XP, these are the Values.


• It needs a set of tools and techniques that are the generally accepted best way of doing something. Think about a stonemason, or cabinetmaker - they use specialist tools in specific ways. Also a surgeon has an array of specific techniques to handle different situations. Note that there is absolutely no reason why there should not be multiple ways to achieve the same results here. However, unfortunately for us the software industry is notorious for aggressively defending personal preference and style over and above effectiveness and quality so there are plenty of red herrings to remove.


• It needs continuous learning. A master craftsman will always be experimenting with things, looking for new tools and techniques to add to the entire craft. Since these new techniques are outside the accepted practices, they can be carefully assessed in controlled conditions in much the same way that, say, a surgeon would try a new procedure with extra precautions, or a master stonemason would try something new on a cheaper, expendable offcut of stone first.


• It needs apprenticeship. Beginners and journeymen need to teach and be taught. An apprenticeship model works extremely well for this - see something, do something, remember something. Plus by working alongside master craftsmen you learn the nuances that can never be documented.

Once the majority can agree on the values, principles and practices that fit these four things, then - and only then - can we really claim to be software craftsmen. Until then it's simply another forum flame war.

Let the Craftsmen Craft Software

There are times when the software industry makes me despair. Making an analogy with someone building a house, you wouldn't:

• Hire the cheapest cowboy builders you can to build your house. ("'We build you house very cheap. £500', 'OK, you're the cheapest. It's a deal!'")


• Hire skilled builders but force them to compromise by refusing to supply them with the resources they need ("Oh we can't let you use electricity. Or petrol - it's a fire risk. Or let you move that fence that is in the way. Or..."), restricting their working environment ("You can plaster that room, but you have to do it through the letterbox") or by unreasonably restricting budget ("you can only buy the cheapest bricks").


• Hire skilled builders but tell them how to do the job, despite not knowing anything about building ("Don't lay bricks like that. Stack them, don't overlap").

Also you wouldn't make the same mistake when building the house again and again when it collapsed, expecting that somehow things will be different this time around.

You absolutely would not build a house like this. So why expect to deliver software successfully like this?

Here's a dangerous idea for you - hire skilled people, provide them with what they need and let them do what they do best.

Groan

A recent exchange between me and a non-developer, trying to explain that some Scrum Masters are better than others:

Me: "Scrum Mastering is pretty much the same as Team Leading. To find a good one you need to look at their past. They almost need a 'pedigree'."
S: "Oh, you mean Pedigree Scrum?"
Me: "Yes. They need to eat their own dogfood....."

At that point we had to temporarily abort the conversation.

OK, maybe you had to be there....

Scrum needs XP

I stumbled across a blog post about Scrum's origins on Jeff Sutherland's blog recently. The whole thing is worth a read in order to get a perspective on where the methodology came from, but especially interesting was the following comment:

"Few implementations of Scrum achieve the hyperproductive state for which Scrum was designed (5-10 times normal performance). Those that do all implement variations on XP engineering practices..."

This fits with my - and others' - experience over the past few years. Scrum, with a few tweaks based on personal experience, provides a good starting point for a lightweight management framework. But that's just it - it's a management framework. You need wrap something to be managed in it. And if that something is a lardy, slow mini-waterfall process then you will simply end up delivering stale garbage more efficiently.

XP has the opposite problem. It provides tools and techniques to develop quality software efficiently, but it does not provide any guidance on tracking or how to control requirements. It benefits from being wrapped in something to manage its external dependencies.

Combining Scrum and XP may not be the only way to develop software but it does seem to be a damned good starting point for further iteration. Do it - you know it makes sense.

The Right People

I talk a lot about getting the "right people on the bus" when talking about teams, especially agile teams. Quite simply, by ensuring the people involved can all pull together rather than undermine each other makes a critical difference to the success or otherwise of the team. Research suggests that this is more critical than we might think.

But how do you find these people? How can you recognise them? What traits do these people have? I've had a go at nailing down specific behavioural traits based on my experience of working with good - and bad - engineers over the years. In no particular order:

• Courage. The "right people" that I talk about are courageous. They overcome their fear of being wrong and are prepared to challenge ideas. They are also "doers", people who have the courage and motivation to get up and make a change where it is needed.

• Pride. Not the damaging kind, but pride as in wanting to do a job well. Professional pride is definitely one trait that separates a money focussed Mortgage Driven Developer from a Software Craftsman. Striving for improvement is always valuable.

• Respect and Humility. Being humble is hugely important when working closely with others towards a common goal. It is the ability to sit and listen without judgement, then provide feedback and respectful challenge. It is the ability to admit when you are wrong. The ability to resist pointing fingers and scoring political points when others stumble. From humility comes respect.

• Curiosity. I cannot think of a single successful developer or manager who does not play with new technologies and/or techniques to see if they are useful. If they work, they get added to their toolbox. If they don't work, they get put to on side until they find a use. Active curiosity stops people from getting stuck in a rut and proves they have the ability to learn.

• Communication. The ability to communicate is essential. Gone are the days when developers can "go dark" for weeks on end. Active, regular communication engenders understanding. Rolling this ability in with respect, humility and courage creates a powerful mix that gets results.

• Sense of fun. Fun is a useful way of releasing potentially damaging stress. I also think it is massively undervalued in the workplace. In my experience, people who have fun tend to be better motivated and have a better work-life balance than those who are 100% focussed on serious work. The better balance allows them to deliver day in, day out. And sometimes a Nerf duel is simply the only way to settle that pointless design argument....

People who have these traits are rare but worth seeking out - they are definitely out there. If you can build a development team of these kinds of people then you really will have a team to be reckoned with - if you put them on the right bus...but that's another article.

One bad apple spoils the barrel

Via Coding Horror:

"A recent episode of This American Life interviewed Will Felps, a professor who conducted a sociological experiment demonstrating the surprisingly powerful effect of bad apples."

This is not news. In fact it's something that I and other coaches have suspected for many years. But this study provides some more scientific backing for our suspicions. In short, even one misbehaving team member can upset the entire team and endanger delivery.

Getting the right people on the bus makes life much easier, massively reducing the risk of introducing agile thinking to a company and increasing the chance of successful delivery. OK, the study also suggests that a good facilitator can defuse the effect of the Bad Apple, but as the study shows, people capable of doing this are few and far between (only one team out of the entire study had a team lead capable of counteracting the problem).