Agile and PRINCE2 - The Best of Both Worlds

Agile and PRINCE2 - The Best of Both Worlds

• 1.
  3GAMMA INSIGHTS AGILE &PRINCE2: THE BEST OF BOTH WORLDS Tony Davis
• 2.
  Taking the rightapproach in project and programme management is often half the battle. Wise choices early on can set you on a course to success. However, an inappropriate choice can leave you wasting valuable time. In this white paper we use a recent project to explore the pros and cons of using agile and waterfall methodologies, and highlight the advantages that can be had from adopting an agile development approach, but supported within an overall PRINCE2 framework. May 2015
• 3.
  BACKGROUND TO THISCASE STUDY Aimia is a global leader in loyalty management running loyalty programmes for some of the most visible global brands including Sainsbury’s. 3gamma works with Aimia helping deliver a multi million pound portfolio of projects. This white paper references a development project for the Nectar brand that delivered a cost effective way to integrate systems and bring together data and content ­— creating value for collectors and partners, promoting innovation and opening new revenue sources. The project used an agile methodology, including Kanban, within a PRINCE2 pro- ject management environment to develop Open APIs (Applica- tion Programming Interfaces) for the Nectar Loyalty platform. ABOUT THE AUTHOR Tony Davis has over 20 years experience as a senior IT Project Manager managing IT Infrastructure, Network Security and Sys- tems & Business Transformation projects. WATERFALL AND AGILE The traditional approach to managing projects is to use a ‘water- fall’ model ­­— a sequential, document driven process in which progress is seen as flowing steadily downwards like a waterfall through concept, initiation, analysis, design, build, test, imple- mentation and support/maintenance. It originated in the heavy industries producing physical deliverables where there was little scope for change during the process. It depends on a strong initial brief and a detailed understanding of the requirements. Although some would argue differently, PRINCE2 is generally viewed as a waterfall approach with sequential stage gates that strive to get to a clearly defined, fixed scope of work, with detailed designs and estimates, before embarking on develop- ment or implementation. It has a strong emphasis on project controls that support and enforce the methodology. Agile is an iterative, collaborative process that is responsive to change, allowing for continual adaptation of the brief and response to user experience. It seeks to harness the knowl- edge, experience and creativity of the users of the solution as well as those developing it — supporting the way that reactive businesses work. Implemented correctly, it delivers quickly, yet robustly, in increments to gain an early return on investment. Two common approaches to agile are Kanban and scrum. The key differences are summarised in the table on the next page. We used the Kanban approach rather than scrum sprints. The team had previously tried sprints but experienced unstable velocity as we were working within a very dynamic environment with changes requested mid-sprint. Kanban provided us with more flexibility because of its continuous process. THERE IS MUCH DEBATE ON THE RELATIVE MERITS OF DIFFERENT APPROACHES TO MANAGING PRO- JECTS, PARTICULARLY AGILE VERSUS WATERFALL. MANY ARE ARDENT ADVOCATES OF ONE OR THE OTHER. HOWEVER, KEY TO SUCCESS IS TO UNDERSTAND THE PROS AND CONS OF EACH APPROACH AND HOW THEY ‘FIT’ WITH THE PROJECT IN HAND. 3 WATERFALL Is best for projects when: But has some downsides: Good understanding of requirements exists and change is not volatile Requires a lot of work up front to define scope and schedule before work begins Delivering physical objects e.g. construction or computer hardware Scope changes can be slow and get progressively more expensive as the project progresses Work must be completed in a specific sequence e.g. bridge supports before the deck If the project is cancelled, early money and resources will have been consumed but no usable value delivered The team is distributed and hence control via defined deliverables, milestones and dependencies is appropriate Distributed teams communicating through documentation can reduce collaboration Specific resources have limited availability so their input needs to be focused over a short timescale Less effective if detailed requirements are not known or are subject to frequent change e.g. responding to a volatile market or in fast paced markets Plans are repeatable for identical or similar projects A strict change control process is required to avoid ‘scope creep’
• 4.
  4 AGILE Is best forprojects when: But has some downsides: The detailed requirements are unknown or subject to change Difficult to reconcile with business desire for fixed price, time and scope contracts The ability to make quick course corrections based on stakeholder feedback is necessary Uncertainty around scope and schedules can make stakeholders nervous if not familiar with the approach themselves The deliverables are adaptable and readily modified Fluid nature of backlog refinement can make change difficult to track and manage An iterative delivery approach is appropriate Less effective if the ‘team’ is distributed The team is co-located and can work in a collaborative, creative and efficient way Requires vigilant management and prioritisation of the backlog Early return on investment by regular delivery of usable capability is necessary Can result in a poorly structured solution if some early framing architectural design work is not carried out first was monitored, measured and reported using Jira. We moni- tored cycle time and looked to improve throughput. ​4. Make policies explicit. We used Jira to publish standards for how we documented and developed stories, including agreed acceptance criteria. The test team had a set of agreed use cases for functional, performance and security testing. Jira integrated with Bamboo, an automated deployment solution used by Pro- duction Support to deploy the new functionality. 5. Implement feedback loops. Through our daily stand-ups (as well as across the desk) the team fed back to each other. In addi- tion, we received input from the business, Production Support and Account Management on behalf of our customers at the meetings. 6. Improve collaboratively, evolve experimentally (using models and scientific method) We ran lessons learnt sessions, tracked improvement through the statistics that Jira provided us and ran other ad hoc work- shops. One particular was on the ‘Theory of Constraints’ (the THE SIX PRINCIPLES OF KANBAN Kanban was developed by Toyota to improve productivity. Essentially there are six principles that need to be applied for an implementation of Kanban. 1. Visualise. We used the software tool Jira to provide a visual representation of the workflow so everybody could see where we were and could understand the impact of change. 2. Limit work in progress. The work was split down into user stories capturing the ‘who’, ‘what’ and ‘when’ of the require- ments in a simple concise way. For our project, the capacity was an agreed number of stories allowed for each step in the workflow dependent on resources available. With experience the team became adept at breaking down work into stories of consistent, manageable size. This allowed us to take advantage of the pull system ­— when a later step had capacity, it pulled the next piece of work from the previous step. 3. Manage flow. Each transition between steps in the workflow KANBAN SCRUM Continuous delivery, does not assume you can fit everything into a sprint Time-boxed sprints, good for supporting committed time constraints Work is ‘pulled’ through the system (single piece flow) Work is ‘pulled’ through the system in batches (the sprint backlog) Changes can be made at any time with agreement No changes allowed within the sprint Measure cycle time Measure velocity Developed from operational environments and deals well with high degree of variability in priority More appropriate in situations where work can be prioritized in batches that can be left alone
• 5.
  rity Analyst, Developers,Production Support, Functional, Perfor- mance and Security Testers ­— all working in a very collaborative way. Most of the team sat together except for one member who was located off-shore. Everybody attended a daily 15 minute stand-up, either personally or via video conference. We had the shared goal of progressing stories through our delivery process. Every day we checked how things were going and if there were any bottlenecks the whole team focused on what could be done to release them. Sustainable development environment. There are many exam- ples of large software projects going massively over budget and time, or just not delivering what the business expected. The teams can come under pressure to work harder, cut corners etc. With an agile methodolgy and frequent delivery schedule we had all the statistics about the duration, effort and cost for each step in the process that a story went through. This enabled the business architects to size up and cost stories so we became better and better at estimating. Hence when the business came up with a new or changed requirement it was relatively easy to determine the impact and have the business state the priority, allowing us to respond with a realistic overall plan. Our Kanban process was key to this. Jira helped us manage the process and produced statistics for keeping track of ‘cycle times’ (how long it takes for a story to successfully go from end to end), with a mean and standard deviation so we easily could see how we were doing and take steps to hold a good pace, and also look for opportunities to improve by working smarter, not harder. Continuous improvement. We worked on small, discrete pieces of work at a time, each of which delivered working functionality. When we came to subsequent pieces of work we had the knowl- edge of recent deliveries fresh in our minds and the business had up to the minute experience with using it. We also had continuous visibility of our cycle time statistics. Hence we were in a great position to get together and brain- storm the best way to approach the next bit of work, focusing all of our respective views. These were often only 15 to 30 minute workshops but at the end we could bring our product owner in, go through what we had come up with, and get an instant decision which items we could then progress with. After each release we did a quick lessons learnt to see what went well and what we could improve upon. “These were often only 15 to 30 minute workshops” Trust and relationships. This worked at two levels. Externally, through our frequent communications, regular delivery of 5 study of bottlenecks). This was a very hands-on exercise that awakened us to vulnerabilities in the team e.g. what would happen if someone was ill for a long time? We followed up this workshop with another one to investigate how we could cover for each other. This in turn led to further training and skills transfer between particular staff that we put into practice over the holiday season. We accepted that there would be a drop in productivity and allowed for this in our plans. OUR BENEFITS FROM USING KANBAN We had significant benefits by using Kanban for the project. Early return on investment. We provided early return on invest- ment for Nectar, our sponsors and partners by delivering usable functionality on a monthly cycle, with an intermediate fort- nightly release if necessary. However, to achieve this required close co-operation with the business to prioritise the work into small manageable pieces of work with clear and agreed accept- ance criteria. We also required the business to be an integral part of the pro- ject undertaking an active role. The role of Product Owner was key to this. This was a senior, empowered specialist with appro- priate authority and responsibility within the business who set the vision, prioritised the work, arbitrated on requirements and was available for consultation and decisions. An ability to respond quickly to the business’ changing needs. With a conventional ‘waterfall’ project the business would have had to predict many months in advance exactly what they would need in great detail. With the agile approach we used the concept of “just enough design”. The stories were identi- fied in broad terms initially, prioritised using MoSCoW (Must, Should, Could, Won’t have this time) and a budget and timescale established. The stories were only analysed and specified in detail immediately before the developers were ready for them. The business were able to make early use of the developing solution. This often resulted in them changing their views on later stories or indeed deciding that they would like changes to stories already delivered. This is no problem for an agile project. The buffer of stories feeding the project was just re-prioritised and no time was wasted. Reduced risk. With agile projects the overall time, cost and qual- ity are fixed and the scope is allowed to to vary. With frequent delivery of relatively small increments of working scope, there was never that much at risk. The business could stop a project and still have working functionality delivered. If a waterfall project is stopped part way through there may only be whatever documentation has been produced and nothing usable to show for the investment. Increased productivity. The team comprised: Product Owner, Team Leader/Coach, Business Analyst, Technical Architect, Secu-
• 6.
  6 working solutions andresponse to evolving requirements, the business and our management developed trust in us. Internally, the joint ownership and collaboration within the team were key. They challenged each other if opinions differed, but in a very constructive manner, as they also supported each other totally. There was one example where a team member raised a par- ticularly difficult issue which was holding up progress. I’ve seen other projects where the response would have been that it was his problem and other members would have backed away as long as no blame could attach to them. With this team they all looked to either provide advice or see how they could contrib- ute to a solution. It can’t have taken more than 10 minutes and was a joy to behold. One thing to understand as a project manager working with a well performing team is that the role is to manage the big picture, external dependencies, senior stakeholder engage- ment, the overall plan and budget. The team leader and project manager were there to observe and support (both worked on multiple projects). Essentially the project manager was focused 80% external (dependencies, budgets, resourcing and overall plans) and 20% internal, whilst the team leader was the reverse (primarily in a coaching role). We focused on dealing with factors that could impact the team’s productivity and made sure the business kept their priorities up to date. Initially it takes time to train and develop such a team. This is where all involved need appropriate agile training, stakeholders included. There are agile courses available for all levels. If stake- holders take the wrong mental attitude to dealing with an agile team, their expectations could be contrary to the agile approach and this could lead to a breakdown in relationships and success. Motivated and engaged team. The pride and commitment of the team kept things going effectively. As a project manager of an agile team it is important to recognise that the knowledge workers within the team have the greatest understanding about their work and are best qualified to plan and organise it. Hence, together with the product owner, we set a broad strategy of which stream of stories we should target for each release. We had contractual commitments to get other streams completed by further particular release dates. The team, under the team leader, worked together to confirm that this was viable and how they should organise the work to achieve it. AGILE AND PRINCE2 The standard PRINCE2 processes were used to provide the overall framework for managing the project. The Startup and Initiation stages were still used to give the project its overall structure and governance. Likewise the Closing A Project stage was there to complete the loop and the check back to the initial THE KANBAN BOARD The work was managed in a series of swim-lanes. From top to bottom they were: • Expedite/blockers: These items take priority over all others. • Time sensitive work items: e.g. items with a con- tractual commitment to a delivery date • Bugs, tasks and user stories with an external dependency: Where there was an external dependency e.g. infrastructure or a deliverable from another team. • Release preparation: We delivered a release to production every two weeks. A separate story was created a few days before go-live, gathering up all the stories that were ready i.e. in Publish. • Bugs, tasks and user stories: Standard work that was wholly within the team’s responsibility. Principles applied: • The work flowed from left to right through a number of process steps, each having set Work in Progress limits and was delivered when ready. • To maintain resource utilisation we had buffer steps (Ready and Development Complete). How- ever, if these started to build up we knew we had a problem and looked to increase capacity down- stream. This was part of the collaboration and multi-skilling we instituted e.g. we could switch a developer into test as long as they were not test- ing their own code. • The board was in Jira; clicking on a story opened up the detail. The whole team had access to the stories which included sub-tasks for each skill. As they progressed there was the ability to comment so it encouraged collaborative working.
• 7.
  7 goals and benefitsoutlined at the start. The agile approach operated within the Managing Product Delivery stage, as indi- cated in the diagram below. Some of the elements of PRINCE2 were applied in a “light” way as there was only a need for “just enough” planning and design. However, this framework and its documents gave the business the high level visibility and control it wanted in order to have confidence in the governance. In addition, the infrastructure elements of the pro- ject were delivered using a more traditional waterfall approach and also sat within the Managing Product Delivery stage. Agile and waterfall approaches were therefore used within the project as the different needs played to their respective strengths. Close Project Direct Project (Sponsor & Project Board) Controlled Start-Up Control Stage Work package oversight; Monitoring & Reporting; Budget/Finance Tracking; Risk & Issue Management; Prince2 Process “Light” Prince2 Process Agile/Kanban Process Team Lead Non-Agile team(s) using standard work packages Manage Product Delivery Start up Project PM PM PM SB SB Initiate Project Planning PM PM PM SM TA BA DEV TEST Team Lead - Agile Team: Key PM PO SM TA BA SB WP PB DEV TEST Notes: “Light” Prince processes are to reflect that there is “just enough” planning and design up front. Detail is left to the Kanban process. Further the Agile team is largely self managing so ‘Control Stage’ is light. Project Manager Project Owner Scrum Manager Tech Architect Business Architect Developers Testers Work Package Product Backlog Manage Stage Boundary MANAGING AN AGILE PROJECT WITHIN PRINCE2 CONCLUSION The nature of our business is that it is constantly evolving. In such an environment we can’t spend time going through an extended specification, high level design, detail design, build, test and then deliver on a large scale. What we would deliver might have been fine if it had gone live 6 months ago but may be useless now. Having said that, there is still a place for the waterfall approach where it is appropriate or necessary as described earlier. Using an agile approach enabled us to be very responsive to business needs whilst the PRINCE2 elements meant we did so without losing control and discipline. However the agile approach only works if everyone understands and is committed to fulfilling their respective roles in an agile way.
• 8.
  ABOUT 3GAMMA 3gamma isa leading professional services firm focusing on IT management. As an independent specialist in IT management, 3gamma provides advisory, consulting services and fact-based insights to many of the world’s most respected companies. 3gamma operates globally from offices across the Nordics and UK. 3gamma is a knowledge firm that bases its expertise of six core capabilities: • IT strategy and governance • IT sourcing lifecycle • IT legal advisory • IT risk and assurance • IT operational excellence • IT project management and delivery 3gamma Insights brings leading-edge thinking at the intersection of IT and business, illuminating central topics relevant to CIOs and decision makers. GROUP HEAD OFFICE 3gamma Sweden AB Drottningtorget 5 SE-411 03 Göteborg Sweden Phone: +46 31 309 7910 STOCKHOLM 3gamma Sweden AB Drottninggatan 92-94 SE-111 36 Stockholm Sweden Phone: +46 8 748 0330 DENMARK 3gamma ApS Frederiksborggade 15 DK-1360 Copenhagen K Phone: +45 53 700 400 MALMÖ 3gamma Sweden AB WTC Teknikportalen Skeppsgatan 19 SE-211 19 Malmö Sweden Phone : +46 40 627 04 05 UNITED KINGDOM 3gamma UK Ltd River Court, 3 The Meadows Business Park Station Approach, Blackwater Surrey GU17 9ABL United Kingdom Phone +44 192 879 6800 UNITED KINGDOM 3gamma Ltd Manchester Business Park 3000 Aviator Way Manchester M22 5TG Phone +44 192 879 6800 FINLAND 3gamma OY Sentnerikuja 2 FI-00440 Helsinki Phone +358 50 3 748 371 3GAMMA INSIGHTS