We have recently started working with a new client on changes to their testing and delivery practice. The aims is to increase the throughput of development and at the same time accelerate delivery and maintain quality. This has been running for a few weeks now and enough time has elapsed for us to start hearing stories about previous projects and what went well and what was problematic.
Today we had a planning session for a project that involves the connection and interoperation of two systems. In this session it became clear that their experiences of this type of endeavour were very similar to ones we have seen elsewhere. Connecting systems is always more complex than expected, there is always lots of stuff that is not adequately prepared, lots of things that go wrong and it always takes far longer than anyone thought.
On the plus side it was reassuring to hear their head of development recounting similar experiences and holding a similar position to my own on how what has to be done next time if there is to be any chance of avoiding the same fate. There was a common understanding of the need for someone being accountability for getting things to work. There was similar alignment over the need to use virtual teams, the importance of preparation, the risk from environmental problems and the need for hands on technical capability and determination.
It was some years ago that we identified integration as one of the number one issues affecting projects both large and small. A distinguishing aspect of our thinking is the major distinction we make between the act of getting it working and the act of testing whether it is working, We always try and get clients to think of the discipline of Integration (see Integration Papers ) as something that stands apart from testing; even from testing called Integration Testing.
No comments:
Post a Comment