Thoughts from a Thirsty Bear

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?

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

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

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

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

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

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