Thoughts from a Thirsty Bear

Hurrah! I have earned another piece of paper (with distinction, no less :-) )! This time for completing the excellent Functional Programming with Scala course run by Martin Odersky and Coursera. I have touched on functional programming before, back in the days when I used to write XSLT for a mashup engine, but this course really helped open my eyes to what the underlying principles are. Not to mention forcing me to reassess the level of test-driven you apply to the new techniques. Now the journey really begins!

“The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities. ”,  Edsger W.Dijkstra ...or in other words... "If you already have a hammer, it is very tempting to treat everything as a nail" My views on using electronic tracking tools  are already fairly well known . But another area that creates a huge impact is the choice of version control system. Using the right software will help your project deliver quickly and efficiently. Choose the wrong one, and the project will be nobbled by unnecessary, damaging and sometimes downright dangerous processes and maintenance overheads right from the start.  In order to avoid the trap highlighted by Dijkstra, it is essential to match the tool to the way you develop and not the other way around .  Let’s consider a fairly typical, highly productive and successful team. In my experience they tend to follow a fairly well defined pattern of working:...

Team: “ Coach! Coach! This agile process stuff you sold us doesn’t work! ” Coach: “ Did you build working software regularly? ” Team: “ No, it was too difficult. ” Coach: “ Did you extend your definition of Done as far as you could? ” Team: “ No, it was too difficult. ” Coach: “ Did you make quality part of your process? ” Team: “ No, it was too difficult. ” Coach: “ Did you review what you were doing at all? ” Team: “ Yes, but we didn’t like what we discovered, so we ignored it. ” Coach: “ So are you absolutely sure it was the agile process that caused you to fail? ” Team: “ Oh yes, absolutely…. ” Coach: " <sigh> " * honest....

Well, that’s a nice surprise! I have just received a very nice email telling me that I have been nominated in the Agile Special Recognition Award category at this year’s Agile Awards .

Paraphrasing an overheard conversation, " This agile process is creating all sorts of problems for us. We are finding all sorts of problems that we wouldn't normally find. "  <pause>   " Oh. Wait. They were always there, weren't they? We just never realised... " All agile processes are designed around regular feedback. They try and touch all phases of delivery as soon as possible, forcing issues to the surface early before they become too damaging. The process is designed makes problems visible regardless of how uncomfortable this may be. They are an unforgiving mirror on the reality that we are often too close to see. But visibility is only the beginning. Just because something is visible does not magically change it into something better - it just means that you know it is there. To change something requires a conscious effort. Your success or failure depends entirely on how you react to the information you are provided with. This reac...

Those jolly fine people at Energized Work are at it again with their "No Bull" paper which provides us with Simon Baker's personal view of the state of software development 12 years(-ish) after the Agile Manifesto. Now, I know Simon and Gus, the founders of Energized Work, well. I have worked with them extensively, and I have nothing but respect for what they have achieved - quality software development with integrity. I also agree with most of what they say and do. I also know the Energized Crew pretty well - a network of committed, high quality software experts who know exactly what they are doing. They have all embraced the whole "agile" way of working. The other thing notable about Energized Work is their well stocked beer fridge. So it is no surprise that the paper resonates with my general views on the software industry today, and the opportunities for improvement that we are missing as an industry. I would encourage everyone to read the paper for...

I am in the process of revisiting exactly what defines agility and what makes it tick, but collecting my thoughts on the subject reminded me of a couple of classic poster summaries from those jolly fine fellows at Energized Work  back in 2007. Well worth a look.