I recently made a trip over the seas in order to rescue a very critical project out of missing deadline syndrome. The project timelines were very aggressive with many parallel work streams. When I was involved remotely, I could not figure out why a bunch of sharp developers can not deliver as agreed. More painful was not able to estimate correctly for the remaining work and commit to next deadline. When I sat down face to face and talked, I discovered a shocking truth - people are wasting most of the time in waiting on each other. There were defined custodians of different parts (or services if you may) and almost everybody was dependent on each other. The problem was everybody was too busy with their own priorities and not able to get the time to help out others. To fill the waiting time, they did stubs and mocks, but it all contributed to the wastage.
I read recent blog entry by Martin Flower - http://www.martinfowler.com/bliki/ServiceCustodian.html and I think it is very interesting solution to such problems. He proposes to adopt the 'Open source' strategy within the organization. Rather than waiting on custodians to enhance or fix their services, go ahead and change the code as per your requirements. Send the patch to custodian who will review and merge with the main code. It is always easier to review and merge, rather than code and test. Now, I am aware that it is not as easy as it sounds, otherwise, there would have not been any need of custodians. However, if it works for open source world, it should sure work within your own organization. I guess, it depends on maturity of the existing code and developers as well. It may be possible after the initial versions of services are released. It is MUST that you have a mechanism for knowledge sharing and collaboration, otherwise, no other option than waiting on others.
The key here as you mentioned towards the end is maturity. To me the open source way and the Agile way of working are the better ways to work since they surface any issues upfront. The concern though is how many of us are ready to face this head on early in the project. Traditionally we are used to looking at issues later and slog it out then rather than throughout the project. It needs people coming out of the "comfort zone shell" which most of us are not ready for yet at all levels in the organization.
ReplyDeleteYes.. 'Open sourcing' is easier said than actually done, especially when organization culture has been hierarchical and bureaucratic.
ReplyDelete