Services, clients, chickens and eggs

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 involving the client-service combo, and make it work end-to-end. Then pick the next piece of functionality, make it work, thickening the slice. Iterate until sufficient. By all means use mocks to make life easier, but don't mislead yourself and your customer into thinking that if it works with the mock it’s ready to ship. Only ever demo as complete using a real client and service.

By approaching the problem in this way you get all the usual benefits - ability to ship working functionality as far as has been implemented, fast identification of design problems, ability to finish when there is just enough functionality.

The principle underlying this approach is simple. Done is DONE. No smoke. No mirrors. No excuses. If it can’t ship it ain’t finished.