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