Thoughts from a Thirsty Bear

I find it remarkable how some teams manage to invent new and exciting ways to undermine the benefits of agile process and principles. The latest I have come across is what I have started to call the SOA chicken and egg dilemma - how do you develop a service and an associated client? Here is the wrong (but sadly too common) way to approach this. Mock the client, build the service. Then mock the service and build the client. Then integrate. Each step being presented to the Product Owner as “done” separately. Worse still, some projects are using separate teams to develop each side. See the problem? It’s mini-waterfall. Make the service, make the client, make it work. It can’t be used until you have developed both sides in isolation and integrated. Each side is based on BUFD assumptions about what it should do, and not what the system needs to do from a user perspective. OK, so how would I handle this? Slice the functionality, not the components. Pick a nice, easy user oriented function

Once again the UK Government has a failed IT project . Failed as in almost three times over budget (an approximate overspend of a whopping £456 million ), 3 years late (and still not delivered) and not satisfying fundamental requirements. The chairman of the committee commented, "There was not even a minimum level of competence in the planning and execution of this project." Ouch! So what went wrong? From the Public Accounts Committee report it appears that some of the key issues were: Underestimating technical complexity Underestimating the need to standardise ways of working to avoid excessive customisation Poor planning Poor financial monitoring Poor supplier management Too little control over changes Costs and progress were not monitored for 3 years ?! Sounds familiar? It does to me - it smells like a typical "throw the requirements over the wall and hope" waterfall failure pattern. But would a more agile, flexible approach helped us here? Continuous delivery o

In case you missed it, here is the Liskov Substitution Principle summarised in a handy motivational poster. (from a set of originals by Derick Bailey , released under Creative Commons)

It seems that some people have some quite strong views on the "right" way to track progress. Here's my view. In the red corner, we have the traditional burn- down graph. You start with a certain amount of estimated work, and as you finish it you cross it off the list. You finish when you hit zero. In the blue corner, we have the burn- up graph. Here you still have a certain amount of estimated work represented as a line across the graph. Work is added cumulatively and you finish when you reach the target amount of work. OK, so what's the difference? In my opinion, not much. Some suggest that a burn-up graph is psychologically more motivating because it is going up. Others I have spoken to prefer to see completion as zero, and like to see work left heading downwards. Personally I'm with the burn-downers. Another factor in choosing which way the burn goes might be ease of changing the goalposts - in other words, how easy is it to add or remove from the backlog est

Dear aspiring Software Craftsman, Here is my advice. Take whatever courses you think are interesting. Study closely the work of the Old Masters. Stop writing software that was only designed in your own mind. Stick with one technique until you perfect it. Buy a book on software structure. It's the only book you need. Until you can write a program without bugs you don't know how to program. Stay away from Javascript. You'll never master it. Very few ever have. Forget about commercial frameworks. Use Open Source. It's where the action is. Visit an old age home. Talk to the people who remember 8 inch floppy disks and punch cards. Learn to play chess. Take a business course. Do not use an MP3 player. Learn a foreign language. Scala should do it. Learn to cook. Please. Before you get scurvy or rickets. There are more food groups than pizza, coffee and chocolate bars. Learn to play a musical instrument. Learn to swim. Do not litter. Avoid politically correct people. Avoid anyo

My buddies at Energized Work , Gus Power and Simon Baker, have won the Gordon Pask Award for Contributions to Agile Practice . Their " No Compromise No Excuses " approach has proven incredibly successful, and is helping many in the industry raise their game, myself included. Congratulations guys!

Just found a great metaphor to contrast waterfall development with agile. Agile is more like a pond. And you get a picnic at the end! The Opposite of Waterfall is Pond Thanks Alan Atlas for a very clear, beginner-friendly metaphor.

It seems that right now "agile" is flavour of the month everywhere.It has hit the mainstream. Everyone has it on their CV, too, so we have a situation where the industry want the skills, and everyone has the skills. Everything is fine and dandy in the software industry. Right? Dead wrong. There is a disturbing trend appearing in the industry. It is becoming increasingly difficult to identify anyone who has genuine agile experience. Many developers, BAs, QAs and product owners declaring agile experience on their CVs, when put into a true agile/lean environment struggle to cope (to say the least). To give typical examples, consider the developer who claims "agile" experience, but does not understand (let alone able to write) unit tests or the power of automated build systems. Or the "experienced agile" guy who had a Gantt chart showing the story contents of every iteration. Or the teams who believe it is acceptable to leave the build broken for weeks on end

Mike Hill has written an excellent article titled " How TDD and Pairing Increase Production " An excerpt: "If you want more production, look first to raising your internal quality. ... All day long, every time you make a move, you will be depending on the code that’s already there. Every line of it you have to study will slow you down. Every extra open dependency will slow you down. Every bad variable name will slow you down. Every flawed design decision, be it big or small, will slow you down. If you want to work as fast as you can, you want to work with clean code. Period." There are many more thought provoking truths in there. Read it! It might just change the way you write code.

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

Just spotted in a job ad for a lead developer: "You will be expected to implement a rigorous Agile Development process and work with the Technical Architect who will define the technologies and toolsets"

Finally, after several days of thinking, searching for templates, scratching head over the CMS and rewording, my poor, neglected website has been revamped. Or at least Stage 1 is complete, and it is now in a state where I can iterate further changes over the weeks/months/years. It now reflects more accurately what I actually do these days, which is an added bonus!

Ron Jeffries has just blogged about dropping quality in favour of speed. Take a look at Quality-Speed Tradeoff — You’re kidding yourself . Having seen many, many projects fail because of this common fallacy, it is a subject close to my heart (but there goes the draft blog article I was writing....). In summary, there are two choices. Subjective historical addenda are mine based on my experience: Reduce quality to go faster. You might get ahead short term, and you might even get ahead longer term if you don't add too many bugs and if you don't make the code uninhabitable. [But history is really not on your side here.] Increase quality to go faster. There is a chance that you will over-polish and not add important business functionality. [Historically this will not happen. Especially if you make this possibility an integral part of the quality process by holding regular customer product reviews and focus on delivering important business value first.]

It would seem that someone at that fine institution Google had a bit of finger trouble over the weekend. I can't help thinking that some (more?) unit testing might save them a whole world of pain and panic in the future. 'nuff said.

Bletchley Park is an unremarkable, run-down country estate in South East England. Unremarkable, that is, until you realise that it was where a team of boffins , including geniuses like Alan Turing , broke the German Enigma code in WW2. This allowed the Allies to intercept vital information and save countless lives. It is also likely to have significantly shortened the war - maybe by up to two years and 22 million lives. Its place in history is assured by this alone. But even more remarkable, in order to break the code the scientists had to invent from scratch the first ever electronic computer - Colussus . Thanks to the efforts of Max Newman and Tommy Flowers and many, many others we have the computers we have today. Through their efforts, we have the software industry - the productivity tools, the games. We have levels of communication no-one could have dreamed of back then - mobile phones, satellites, GPS. We went to the moon, and are now eyeing up Mars and beyond. We have the abi

Via Simon Voice : wagile adj a cross between agile and waterfall process. The mess that's left if agile is only partially implemented without cultural change. See also: failure , compromised , doomed

I have just finished doing my own, personal retrospective of 2008 after spending a couple of weeks relaxing and decompressing. Definitely a cathartic experience that has left me re-energised and ready to go in 2009. Highlights: 2008 saw me go into several flawed companies/teams in succession as well as some well adjusted ones. Although I delivered results, they were nowhere near the level that I am used to getting, and the battles to get even those results were long, protracted and draining. Portia Tung wrote about something she called " The Wall ". Well, I found my wall last year and although I managed to scale it, it wasn't elegant. So in 2009 I intend to only work with well behaved clients who genuinely want to change, or have already made the change to agile/lean thinking but need guidance. Life is too short not to. Consulting should not be a battle, it's a co-operation. More of that in a later blog post. But I also need to understand better what my personal &q

I have just been reading a thread on an agile group discussing the best practice for bug tracking in an agile team. Almost everyone has immediately jumped in and suggested things like Bugzilla and Jira. At risk of this turning into a rant: You do not need a formal bug tracking system in a healthy agile development team Quite a sweeping statement. Let me explain. The whole problem seems to come from a fundamental misunderstanding of what a 'bug' is. I define a software bug as "undesired or missing functionality". Now let's compare this to a definition of a 'story' - a story is a statement describing the desired functionality - i.e. it is an invitation to correct undesired or missing functionality... Sounds familiar! In other words bugs are stories . And if they are really stories, then why treat them differently? Simply write them on cards 1 , throw them onto the backlog and let them be prioritised along with everything else. Bugs that are importa

I have been playing on Twitter for a month or so to see if it could be useful. As yet I'm undecided, but it has been useful enough to capture idle thoughts on the run so I'll stick with it for a while longer. For anyone interested in following my random ramblings I can be found here .

Having tried several different iteration lengths over the years, I now tend to recommend iterating weekly. It provides maximum flexibility and adaptability while being extremely intolerant of waste - problems are quickly surfaced with such a tight feedback loop. But it does not always work as I found out over Christmas. Our live system broke. Something ate some important files so the app collapsed. This was quickly traced to the Jetty servlet container deploying to the /tmp directory by default. Not a problem in itself, but there was a default cron script that helpfully tidies up /tmp by deleting anything that has not been touched for 10 days.... Of course, the Team was in Christmas shutdown for two weeks, and sure enough 10 days after our last live deploy...<BOOM!> We missed this because we were using weekly iterations. We were deploying to the various dev, QA, demo and live systems every week so the deployed files were never older than 7 days. So beware...weekly iterations can