dsdm delivers more than just agility - final en 2 - for ......1. management continued to influence...

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

Copyright M.C. Partners & Associates, all rights reserved, reproduced with permission of Infonic AG, Zurich, Switzerland of 13

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


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/


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. This is a challenge and requires mind-set change yet it is extremely important to focus on the business’ needs.

3 http://en.wikipedia.org/wiki/MoSCoW_Method


“Focusing on the Business Need” is in fact one of eight principals of DSDM Atern, which are introduced below:

# Principal Example 1 Focus on the Business

Need Every single delivery must have business value. After every timebox the value is demonstrable to clients. No longer are developers focusing on framework changes or other ‘interesting tasks’ that keep them in their comfort zone but don’t deliver value.

2 Deliver on Time Timeboxes are set to three week periods planned in advance. The dates never change. This allowed Infonic to pre-determine webinar dates, the beta release date and the final release date. Clients could then plan around them.

3 Collaborate Each team has engineers, Business Analysts, business ambassadors, and testers/supporters. All work together and when needed all help each other. The teams are thus cross-functional. During the regression testing timebox, teams even help each other out. At such a point, fearsome egos begin to evaporate.

4 Never Compromise on Quality

Whatever is developed during a timebox, it must work. It must be fit for purpose. If it does not work, the webinar will surely fail, providing a great incentive for the team.

5 Build Incrementally from Firm Foundations

Only start development if it is proven to be feasible and it is what the company and the client want and the information available is in enough detail to proceed.

6 Develop Iteratively Deliver functionality in stages by focusing on ‘quick-wins’ to gain early confidence and early business support. Momentum gets built. The business’ expectation then raises and unlike ‘normal’ software houses that have to fight hard for clients to upgrade, the clients want to upgrade, almost immediately.

7 Communicate Continuously and Clearly

Every team has daily stand-ups and tools such as Skype are used to integrate remote team members. Clients are also integrated through regular Webinars and demonstrations.

8 Demonstrate Control There is no excuse for not knowing well in advance when a particular feature will not make the release.

Adopting the Atern methodology requires time, and commitment yet the process is simple:

Ensure that Senior Management buy-in to Atern as the right choice. Train the staff members with a DSDM Atern Awareness Training Course (1 day) Train key staff and Team Leaders with a Practitioner’s Course (3 days) Start by creating the first Prioritized Requirements List (PRL) for a release and then let

the team estimate and plan the timeboxes. Provide a reasonable tool such as Jira that supports an Agile methodology, and put the

PRL into it. Start development of the release following the principals above!

After a short period of time, perform a Capability Maturity Assessment to learn and understand what area needs improving and which areas should be promoted as Best Practices. Maintain the pressure on learning the Atern methodology and adopting it where the organization benefits most. Push the Team Leaders through the Agile methodology’s in-depth and industry recognised Certification training.


Leveraging the Principals and Concepts of DSDM Atern Once DSDM Atern was up and running, the company was able to look at other areas that needed addressing. It was recognised that the Atern concepts and principals could be leveraged to resolve these as well. 1. Estimating and Planning by the Team – Not Management Traditionally it is the seniors that estimate the time to do a task. This is then fed into a Project Management Officer (PMO) where, with input from the seniors, a project plan is produced which reflects known dependencies. The PMO is then responsible for tracking progress and the critical path by interrupting people doing their work, trying to break down tasks not understood into reasonable time frames whilst forever trying to extract transparency on the status of the project for monthly reporting to management. Many issues arise from this arrangement: The people doing the work are unhappy as they did not provide the estimates but they have to do the work, the PMO is seen as a policeman or auditor. Empowerment is ultimately impossible as management dictate the “what” and “by when”. When DSDM Atern was introduced, much of the above is resolved as those doing the work estimate as a team using techniques such as estimation-poker – and this is fed back to the seniors of the business in an environment of open and consistent communication. Once established, the productivity of the entire Business and IT team is measurable which leads to more reliable planning for that team and thus the ability to demonstrate control and commit to delivery. However, it may remain very tempting for management to attempt to continue to influence estimating. They may want Man-Day efforts or may insist that a task may take 40 days “because that is how long it would take me if I did it” or “the team said 75 days, you must do it in 75”. A second example could occur during contract negotiations with a new client: To push a team to estimate a piece of work even though the details are not understood (at times even by the prospect) is a clear indication of poor acknowledgement of reality. None of this ultimately, delivers quality to the project: Such approaches are neither necessary nor acceptable and are plainly poor management. It is for management to negotiate with clients and to manage client expectations. It is necessary to understand that initial plans are exactly that, and that they can and will change once the team doing the work has explored the implementation options. Above all they must remember that historically the code base was much smaller and less complicated; so what may have taken the manager 40 days “back then” is no longer the case and that the code base has since then grown in all dimensions. 2. Introduce Regression and Quality Timeboxes In the DSDM Atern agile methodology, a release consists of a number of timeboxes. Usually, new functionality is built and delivered within each timebox. However, as a software vendor with delivery cycles and multiple clients to please this may not be ideal, and for two reasons: (a) In reality, developers focus on new functionality and not on defect resolution, and so bugs do not get fixed unless they are escalated and (b) the whole product-suite would never get tested as a single unit.


The first part of the solution was to plan at the start of a release one Quality Timebox, which is a period during which no functionality is built yet allows for early defects to be identified and resolved. These defects generally have two distinct sources: Source Description & Benefits Client User Acceptance Testing (UAT)

There will always be issues found by clients during their UAT on their data-set and customizations so the organization needs to be geared up to resolving these rapidly.

Backlog of Non-critical Defects

By fixing as many defects as possible during the Quality Timebox these will no longer hinder the organization whilst it is building new functionality, e.g. “Work-arounds4” no longer need to be remembered and catered for. It simply improves efficiency of the whole organization. In addition, existing clients who experience these defects will know that they are already fixed and will find it hard to resist upgrading. It is therefore, easier to persuade clients to upgrade to the latest version thus older software versions are decommissioned faster.

Other long awaited operational improvements can also be made during the Quality Timebox such as development environment software upgrades, new build processes, hardware upgrades, and even training courses. In fact this is the perfect time to carry out any activity that is not related to new software builds that would otherwise interrupt the focus on new features. The second part is the introduction of a Regression Timebox which is the last period of the release during which, just like the Quality Timebox, no functionality is built (new functionality should already work as Principal Nr 4. states that “Quality is Never Compromised”) so the whole organization is focused on executing tests on the product as a whole and stretching its robustness. In addition, no team wants to be in the position of having to continue testing new functionality as it will require other teams to help them out – thus a healthy inter-team competitive edge prevails. At the same time, a Release Candidate (aka “Beta Release”) can be deployed for clients to start familiarizing themselves with the new release, issues can be resolved extremely quickly and the new functionality in the Release Candidate can be demonstrated to the community via Webinars. Taking the concept of demonstrating new working software before release, the Business Analysts on each team are also responsible for demonstrating the new functionality of every timebox, in person or via Webinars. Ensuring that the client and business are consistently engaged like this has led to clients actually wanting to get their hands on the software earlier than ever. This is fabulous: It allows clients to familiarize themselves and report issues earlier than ever which reduces time-to-market as clients will want to upgrade quicker than ever before. By combining the two timeboxes of Regression, which ends and Quality which starts, a sustained period becomes available during which Architects and seniors may engage the Product Visionary to work on the content of the next release’s PRL.

4 http://en.wikipedia.org/wiki/Workaround


This pattern is simply repeated as shown below.

The result of adding the Regression and Quality Timeboxes has had an impressive and positive effect on the open defect count statistics. The following chart shows all created and resolved defects over the year5. In April 2010 a release was made with only regression testing. This simply increased the number of defects found (a good thing) and the number resolved matched it. However, it was the introduction of the Quality Timebox that resulted in the switch to resolving more defects than those detected.

To be in the position of fixing defects faster than they are reported and in a consistent and controlled manner and consolidating this position, is a great moral booster for the entire company: Frustration is lifted everywhere releasing even more energy which is now focused on new functionality and the resulting innovation.

5 The HedgeSphere Product Suite consists of 75+ man-years of effort. Transparency is important, thus the defects illustrated in the chart include all those found by clients plus those found during internal testing. The chart is produced by the JIRA system.

Just regression testing is not

enough…

... combining regression & quality timeboxes provides the “leap”


3. Automated Test Coverage At the corporate-level, sales reference calls prove to be extremely challenging if the product is full of defects. The need to reverse the trend is obvious. It is necessary to resolve the defects as close to the point-in-time that they are created as possible. So, all automated tests are repeated every night to reveal the defects the day after being “created”. However, automation suites may have ‘gaps’ through which new defects escape. These ‘gaps’ needed to be closed and this was done in five stages: 1. Identification of major features developed in older versions that had no end-to-end

business test cases. 2. During subsequent Regression timeboxes, all staff are assigned a subset of the untested

features to be “Must” manually tested, they “Should” write the test script and “Could” write the automation. At Infonic, the following was observed with each subsequent Regression testing timebox:

a. During the first Regression testing timebox, all the functionality was manually tested,

some manual test scripts will be written and a few got automated. The manual test scripts were to be reused in the next release’s Regression timebox.

b. The next Regression timebox resulted in more automation of the manual test scripts from the previous timebox and even more of the gaps had manual test scripts.

c. This is then repeated until the gap is closed. Astonishingly, Infonic closed its gap within three timeboxes. Thus over time, manual effort is reduced and automation increases:

3. Allow the sequence of automated tests to be configurable. The most troublesome areas

are always configured to be tested first to get as early feedback to the developers as possible.

4. Once all the features had at least one automated test case, additional ones were added, again focusing on problematic areas first.

5. Add non-functional test cases such as system performance and load testing. As Atern states and ensures that Quality is never compromised, the ‘gap’ never grows. New functionality is always delivered with automated end-to-end test cases6. A result of this work was greatly improved engineering efficiency as side-affects could be addressed at the time of development rather than in weeks or months after they had been created – as had previously been the case.

6 These end-to-end test cases are provided as part of the Foundations phase of the DSDM Atern methodology.


Yet ultimately, it is our clients that benefit: One major client reported a 76% reduction in issues found in the product during their regression testing campaign, as illustrated below:

The slight increase to Q1 2010 to Q3 2010 was due to the fact that the client could test more depth than was previously scoped in the same amount of time. 4. Merge Quality Control and Support Typically, a vendor or IT department will have separate support staff and testers, resulting in:

Supporters never being able to influence the product that they support; Testers never being in contact with the business users that rely on their work; Supporters rarely receiving training or getting to know the product in depth; Testers never really knowing the end-user’s pain; Both sets of individuals never gaining true status within the organization and High staff turnover.

By simply merging Support and Quality and making them part of the DSDM Atern team, the individuals can constantly and consistently influence the software being designed as they are now part of the team. They know what hurts the client and thus they know which areas are problematic (e.g. to use, configure, report on). The support function understands how an end-user applies the software, and so can ultimately influence the design of the software. They often actually know better than the developers, who traditional hold the power-base for deciding how the software will look and operate. This cross-functional role provides job-enrichment resulting in high engagement levels, individual satisfaction and lower turnover, all of which is rare within a traditional silo setup.


It is all about Teamwork, Quality, Innovation and Fun In the year, the quality of the product had improved with each release. Frustration had been lifted, and there was a considerable up-lift in discretionary energy levels and the belief in innovation and teamwork was second to none. New products could be developed in a focused manner, and all clients became positive references for the business. An important addition is that the company also became a fun place in which to work. In fact, Teamwork, Quality, Innovation and Fun are the company’s core values. Infonic surveyed its entire staff to measure if they perceived improvements. This was the result:

Value Improvement Teamwork Up 40%

Quality Up 40% Innovation Up 50%

Fun Up 40% On a final note, the lead Tester is now Head of Client Services, encompassing Support, Quality and Knowledge - and these days he is enjoying his private life with his family (his third daughter is about to enter this world) and his two rather fitter dogs.


About Infonic AG Headquartered in Switzerland, and with offices in Zug, Zurich, London and New York, Infonic AG is the leading provider of front, middle and back software solutions to the global fund of hedge fund industry. It’s HedgeSphere product range debuted in 1999 and has been adopted by the largest and most innovative players in the industry. With many thanks, this story has been reproduced and supported by Infonic AG.

Company History & Mission M.C. Partners & Associates was founded in 2011 by Matthew Caine, an award winning software veteran of 20 plus years. It is his passionate belief that people are at the core of the software business. If given the freedom to work as a real team and at the same time, to commit to deliver as a team, then high performance will be achieved. The adoption of an agile methodology encompasses these basic principles. Yet its adoption has to be done correctly and the organisation surrounding that change must also be aligned with the methodology. This is why M.C. Partners & Associates was founded: To enable organisations adopt an agile methodology and make it culturally sustainable. Matthew has worked in companies such as Logica, Swiss Re, Avaloq and Infonic. During his professional career he has experienced all the major roles of software; from support to business analysis, development, consulting and sales bid-‐management to managing large co-‐located and virtual teams plus process improvement programmes such as the adoption of DSDM Atern at Infonic. Contact Us Let’s see if we can help you help your people through agility. Website: www.mcpa.biz Email: [email protected] Mobile: +41 79 936 7060 Address: Matthew Caine M.C. Partners & Associates GmbH Voltastrasse 9 CH-‐8044 Zurich Switzerland

dsdm delivers more than just agility - final en 2 - for ......1. management continued to influence...

Documents