ND8 DEVELOPMENT
Best Practice Software Development
© ND8
Thursday, July 23, 2009
After a sometimes tortuous three-year attempt to outsource and off-shore, the development of its next generation customer engagement systems, my client, a household name, has decided to bring back home the development, and base it on a Scrum inspired agile approach.
The transition from in-house, to off-shore and back again, is a story in its own right. This article attempts to unpick the reasons off-shore failed, and why Agile has been embraced so readily by the IS and business community. The analysis is based on five measures of operational performance: efficiency, speed, quality, reliability and flexibility.
Efficiency - The outsourcing model, and commercial framework that underpinned it, required fully defined Use Cases and corresponding test cases to be developed before being accepted by the off-shore supplier. Immediately Pereto’s 80/20 rule was broken and the analysts initial productivity became bogged down by detail and complexity. An extended review process (at one stage incorporating 21 review points) added to the problem. Initial metrics of 10 days effort to define an average Use Case doubled, trebled and quadrupled. When the decision to adopt Agile was taken, many Use Cases remained incomplete.
Speed - Not only was the process inefficient, it was tremendously slow. The review process itself imposed a 4-week minimum elapsed time to write and approve the simplest Use Case. Pushing several Use Cases through together caused bottlenecks. Inefficiencies and re-work combined to bring the process to near standstill. The problems were mirrored on the technical side. The design / code / review cycle became protracted. Fixes, improvements and extensions that should have taken minutes, took days and weeks. A planned 16 week Elaboration phase doubled to eight months before the programme hit a much reduced set of Elaboration KPI’s.
Quality – Counter to popular belief, poor speed and inefficiencies had a direct detrimental affect on quality. Motivation plummeted. People’s ability and enthusiasm, to read, absorb and comment critically, on 15 page use case specifications, let
alone define them correctly in the first place (if this is possible) was severely questioned. To meet quality gates, focus skewed toward standards rather than content and fitness for purpose. The focus on detail diverted attention from the bigger picture. From a technical perspective what should have been a controlled evolution and maturing of the technical architecture and designs, became an exercise in simply getting code to integrate and work. Extended time frames to design, build and test, meant that what set out to be an exercise in achieving the optimal balance between speed, scale-ability and extensibility, was diluted to the point where working code became good enough.
Flexibility – The outsourcing model and commercial framework, immediately imposed restrictions on flexibility. The problems of speed, inefficiency and quality, described above exasperated to the problem. Who would want to change something after struggling for weeks and months to gain approval, no matter how worthy the reason? With a geographically distributed team extended lines of communication added to the problem. Every change became a change control. A change to a Use Case name required an impact analysis. Every document had to be version controlled and configuration managed. Change happens. 25% of requirements change on a typical project. Waterfall / Off-shore simply aren’t designed to cope with this. Change clogged the system.
Reliability – Problems of speed and inefficiency can sometimes be forgiven, lack of flexibility understood, and issues of quality grudgingly accepted, but continuous failure to deliver on promises killed any trust and faith the customer had in the ability of the programme team. A 16 week Elaboration phase doubled, slipping by the week as the programme repeatedly failed to meet its objectives.
Clearly, the programme was in trouble. Something had to give and for one project team the crunch came sooner rather than later. After struggling for four months to defined use cases and define an acceptable technical design, the team gained agreement to complete the
Elaboration phase in-house and left to its own devices adopted an Agile based approach.
The team immediately introduced weekly iterative development cycles ending with demonstrations back to the users, full time business representation, daily stand-ups and continuous integration techniques. Use Cases, defined to outline level, were decomposed into stories and features to drive the iterative cycle. Details were discussed directly between developers and business experts and built into the software. The team worked as a single unit, developers, analysts, testers and business experts combining to produce high quality, tested code, and constantly re-organising to meet the needs of the next iteration. Communication problems ceased. Only work required to meet the iteration objectives was competed.
Within weeks the improvement was obvious. Rather than being confronted with written specifications and models, users could see the actual solution emerge and were encouraged to provide feedback that could immediately incorporated into the next demonstration. Presented with working functionality, details important to usability such as tab orders, alt key functions and field layouts could be tested and improved.
Targets were hit. Trust increased. Momentum grew. Across the board, speed, efficiency, flexibility, reliability and quality were up. A vicious circle became virtuous. The contrast in performance between this team and the rest of the programme was striking and could not be ignored.
To find out what happened next read Part 2 - The final chapter
Bringing it Home - From Off-shore Waterfall to In-house Agile - Part 1