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.