DSDM Atern Enables More than Just Agility Matthew Caine, Partner, M.C. Partners & Associates, Zurich 1st April 2011 Abstract The successful implementation of the DSDM Atern1 Agile Project Management methodology has improved delivery beyond expectations. However, it was in leveraging the framework that provided even greater results. This enabled Infonic to address typical estimation issues and eliminate Technical Debt. Together, these enabled the teams to focus on one job at a time and the business to extract even more productivity from scarce highly qualified and experienced resources. The cumulative results of this included measurably improved software quality and demonstrably improved teamwork and inter-teamwork - and so provided the basis for enabling successful innovation whilst all being done in an environment of fun. 1 DSDM and Atern are registered trademarks of Dynamic Systems Development Method Limited First, a True Story It is 4am. The lead Tester has just walked into the office to complete the automated test script. He has had less than 3 hours of sleep. His wife and two young daughters have not had quality time with him for a month. Neither have his two dogs. Slowly, his colleagues join him over the subsequent hours contributing to the task with various degrees of alertness, focus and presence - yet they all work through the day until finally the software works. It still had to be packaged, but it works. Everyone can go home and enjoy the weekend with their families. Wow, the adrenalin, the rush, the yes-we-did-it feeling. The teamwork and the personal sacrifice got the team over the set-in-stone deadline. The result was a very happy client. In the software IT business, life does not get much better or more rewarding than this. The date was the 6th: Delivery Day. Yet one simple fact was forgotten by most who had celebrated that release: It was the third attempt! The original date was the 30th April, then postponed to 31st May and then to 6th August, in all it was delayed three months. In making this particular release the company satisfied the demands of one major US client, yet significantly upset another very important international client. In commercial terms the company was forced to forego on revenue, which ultimately and negatively affected the year’s bottom line and everyone’s bonus. Not quite the success story one had originally imagined. In addition, the organization was no longer in a position to innovate as there was no longer the time to address new products because of the constant fire-fights being escalated and fought by management. This story is familiar to IT departments and vendors across the globe, and sadly is all too acceptable as daily business in today’s world of fatalistic IT Project Management, software development and delivery. Some would certainly say ‘typical’ or ‘inevitable’. The IT industry is blighted; after all it was we whom created and will continue to create our own history. How many projects come in on time, in budget, in scope and least not forget, in quality? Not many. Same old story – nothing new. Yet during the subsequent twelve months three releases were delivered on time, with demonstrated control of scope, in budget, in increased complexity and with quality rising like never before and with the same resources. The result was clear for everyone related to the company, staff and clients alike, to see and feel: Pride. Pride now permeates throughout the organization in all roles: Architects, Team Leaders, Testers and Developers, the CEO and the remote Professional Services staff on the front line at clients throughout Europe, the US and even Bermuda. This fortification has enabled the company to once again commit to innovation and leap-frog the competition in the product, in services and most importantly in reputation. Ultimately it is all of this, which allows future sales to provide sustainability and long-term equity growth for the partners and owners of the company. The Epic Story How then, was this turn-around achieved? What measures were taken to turn what was quite simply a potentially disastrous scenario into the success story of today? First and foremost, the company needed to change the way that software was developed. Clearly the current method was not working. The adoption of an Agile Project Management, Development and Delivery methodology was determined to be key. Although Scrum is prevalent the company and the product needed a methodology that provided rigour to Project Management, and robustness throughout the Project, whilst remembering the strategic and business objectives expected from the features of each release. This included the gathering and prioritization of business requirements from existing clients and new clients, and strategic product development and moving them from “Epic Stories” to user-stories for the Copyright M.C. Partners & Associates, all rights reserved, reproduced with permission of Infonic AG, Zurich, Switzerland Page 2 of 13 development teams to understand, debate and challenge – and ultimately to deliver with confidence and with quality. Thus the company chose to adopt DSDM Atern. Atern was the key, as the principals and concepts of the methodology could be used in ways not originally foreseen, these included: 1. Management continued to influence estimates yet when using Atern, team estimation sessions allowed management to step back. The responsibility for estimating and planning needed to be pushed onto the team members. Without that, there was no credible commitment to deliver. However, management had to play its part, by refraining from dictating the “solution”, “by when” and “how long”. 2. DSDM Atern allowed the organization to focus on new developments and plan time for the high-interrupt work. Previously the teams were rarely able to focus. New development was interrupted by defects, sales and infrastructure issues. It is necessary to allow for the reality that some defects are unfortunately only detected in a live client environment and it is necessary to address these immediately whilst at the same time allowing for a time period when necessary operational efficiency improvements can be implemented so that new development can proceed in a focused and un-interrupted manner. 3. DSDM Atern provided concepts to completely remove the deficit in testing coverage within three releases. During the preceding year however, the QC team could not close a single gap in their test automation scripts. The company knew that quality in the product needed to improve through timely deeper coverage of test automation. This in fact is instrumental to support continuous testing and continuous integration. 4. DSDM Atern’s focus on teamwork within timeboxes allowed cross-project functions to take a much more active role in the development of the product. A typical software house will have separate QC staff and Support. They are rarely involved, poorly trained, highly exposed and have little respect. The individuals performing quality control and support needed to work side-by-side with the development and analysts in the team. Atern ensures all staff contribute to the final product and thus enable company-wide high performing team-work. Adoption of the DSDM Atern Agile Project Management Methodology Infonic adopted the UK-based DSDM consortium’s Atern methodology2. DSDM Atern differentiates itself from other Agile methodologies such as Scrum as it provides greater guidance on Project Management and in management of the requirements from Epic Stories through to individual user-stories, which is essential for a software vendor to manage effectively. This is due to the fact that Epics will originate from multiple clients and from the company’s own strategic Product department. All these efforts must result in one single software version thus avoiding the crippling affects of supporting multiple productive versions. 2 http://www.dsdm.org/atern/ Copyright M.C. Partners & Associates, all rights reserved, reproduced with permission of Infonic AG, Zurich, Switzerland Page 3 of 13 The most powerful change in the DSDM Atern approach is to fix, manage and maintain the time, cost and quality of a release while still ensuring the complex scope can be variable to meet the dynamic demands of the business. This is 180° opposite to what usually happens on IT projects where scope is fixed whilst time, cost and certainly quality, are compromised – as identified in the example at the beginning of this paper. To control a variable scope, it is necessary to use “MoSCoW”3 prioritization (Must, Should, Could, Wont). It is this that provides both transparent high-level priority setting and also the method to control the contingency on the project. The scope itself however, must come from somewhere. Someone or some function within the organization adopting the DSDM Atern methodology must provide the list of what is to be built and make the call that across the whole release and within each Timebox feature A is a Must yet B is merely a Could. In Atern, this is called the Prioritized Requirements List (PRL). The PRL is the result of demand management which has to be managed by the Product Visionary. The Product Visionary must be focused on the market through market research by engaging both existing clients and potential clients for future demand thus focusing on the real business’ needs of the next 6-18 months thus driving innovation. At Infonic it is the Product Visionary and his team of Business Analysts and Business Ambassadors who are responsible for taking initiatives (new product, new features) from a Terms of Reference through a test on feasibility and through to grounding out the foundations resulting in the PRL. This is tough work as the PRL must include a certain amount of detail to allow progress to continue but not too much that it contains all the detail, just like a traditional Functional Specification.