Introduction to CiCS Agile Projects

Transcription

1 Introduction to CiCS Agile Projects This is an introduction to how we run CiCS projects. It s written for people who will be involved in our projects, but may be of interest more generally. Background For some years we have used the industry standard PRINCE2 methodology as the basis for running all projects in CiCS. We adapted it to the needs of the University, using the minimum level of bureaucracy necessary for getting the job done well. We are now building on our experience and moving towards an explicitly Agile Project Management approach. So what does that mean? Our approach has always been more collaborative than in most places, and the Agile methodology builds on that. The customers and users are much more closely involved throughout the project, ensuring the results fit better. We have increasingly tried to break projects into clear phases, and where possible send things live in a phased way. The Agile approach is based on this approach, with well defined timescales and benefits being delivered as soon as practicable. Increasingly we will stand back at the start of a project and assess what are the real needs and benefits and what are the processes involved, rather than jumping straight to building a system. The Agile approach strengthens this approach and defines requirements as user stories (see below) so the whole project is shaped by what we are trying to achieve and the real benefits, rather than by the system which may get us there. We have always had a just enough approach to project bureaucracy. The Agile approach systematises that, with a clear definition of how much detail and control is needed at each stage of the project. Responsibility in an Agile project is delegated to the best people to deal with it, so the Solution Development Team (which involves users and developers) can decide on the best way of meeting the real world requirements which have been allocated to them, using their technical skills and understanding of how things really work on the ground. There is lots of prototyping and refinement so that what emerges will work in the real world. Like everyone else we have had trouble with project scope creep, where projects just keep growing and last forever. The Agile methodology focuses on getting something decent out the door on time rather than something marvellous in the ever disappearing future. Scope creep is not just frustrating, it means that other work which may be more important isn t being done. The aim of effective Agile project management is to enable change, continuously correcting course, whilst maintaining the aim on the target which is a usable solution on the agreed date. Key Features of an Agile Project 1. Deliver on time 2. The Prioritised Requirements List What tends to happen in traditional project management is that the requirements are a given (or they keep expanding) and the time taken and cost are what give way. The Agile approach reverses that, with the flexibility being in the features the Prioritised Requirements List (below) is central to how that can work. We get more benefits from a project that delivers something adequate on time, which can then be improved, than from a project delivering something splendid two years late when things may have changed anyway. The Prioritised Requirements List (PRL) is central to the definition of what the project is for, and to guiding development. Each requirement is a user story along the lines of As a... I need... so that.... For instance: As a student I want my calendar to show teaching events so that I can plan my time, be there when needed and avoid wasted journeys. 1

2 When the Project Definition is first drafted there will only be a few high level requirements, then later in the project these will be expanded into more detail, but still in the same format, ie saying what needs to be achieved rather than how to get there. MoSCoW prioritisation Each requirement is prioritised as Must have, Should have, Could have or Won t have this time. Must have means absolutely essential. There s no point carrying on if this isn t done. So if you were making a car the engine would be a Must have. Should have means it s necessary for this to be a decent result. You ll not be happy without it, but the result won t be completely useless without it. So for a car that might be the glass in the windows. Could have means it s useful but you could live without it like audio or air conditioning in our car. Won t have means it s relevant and might be a good idea but it s out of scope for this project. Once the requirements are agreed the developers (not necessarily all technical) do an estimate of how long each will take. There are techniques to help with this, but inevitably the estimates will be very approximate early on in the project and become more accurate as the requirements are fleshed out and experience is gained. For a good project you should have a maximum of 60% of the estimated time on the Must have requirements and at least 20% of estimated time on Could haves. That is because the more Must haves and fewer Could Haves there are, the less contingency there is and the less flexibility the Solution Development Team have. A project with 90% estimated time for Must have requirements is a high risk project. NB The PRL is not set in stone, and in particular the priority levels may well change through the project. But any change to the high level PRL (in the Project Definition) must be agreed by whoever commissioned the project, including CiCS SSB, as the high level PRL defines the purpose of the project. 3. People Everything done by and produced by a project is agreed and 'owned' by the Project Board and working groups. The Project Manager doesn't 'own' the project they are one of the team, there to co ordinate the project and make sure it is run properly. So if you're worried about something, say so it's your project. This is the classic diagram for an Agile project structure. The Project Board The Project level roles are those on our Project Board. The term Business refers to whoever is wanting and using what the project is producing typically academic and other professional services departments One Project level role which is new is the Business Visionary. They own the vision for the project and the wider implications of any business change. They will be a key person for communicating outside the project, and an important contributor to the Prioritised Requirements List. The Solution Development Team The team is typically 5 9 people. The Team Leader is a facilitator role, it s not a command and control management function. The team works closely together on analysing and coming up with solutions to meet the requirements which they ve been given (see Timeboxes below). It s essential that the Business Ambassador is a member of the team, usually with daily contact and sometimes working for periods alongside the technical developers. Committing time Both the technical and business sides need to commit time to the project more of a time commitment from the business side than we have perhaps been used to. But the benefit is that we end up with a solution that really 2

3 works and meets the real world needs which the project was set up to address. It s an excellent investment, and is essential for a successful project. 4. Project Stages: Feasibility, Foundations, Evolutionary Development, Deployment Gateways There is a Go/No go gateway at the end of each stage Feasibility, Foundations and Increment. The Project Board takes stock and decides if they are happy to embark on the next stage. Key senior people outside the project, including CiCS SSB, should also review it. Feasibility stage This is the first stage of the project, when interested parties are brought together by the new Project Manager to consider the shape of the project, who should be involved, what the core aims are and how practicable it all is. They will start with the approved Project Proposal and if they are lucky this may just need fleshing out. But it s important to challenge the assumptions and think laterally about the issues which the project is trying to address. The Project Board is set up, representing the key interest groups, and they agree the Project Definition or possibly recommend that the project does not go ahead as it is impracticable or not what is needed. Products: At the end of Feasibility the Project Definition has been defined, including the high level Prioritised Requirements List, a detailed plan for the next stage (Foundations), and a high level plan for later stages. Foundations stage This where the how we are going to do it is discussed and agreed by the Board and the Solution Development Team. This includes fleshing out the Prioritised Requirements List, so you might end up with perhaps 100 detailed user stories instead of say ten high level ones in the Project Definition. You will need to consider if it s possible to deliver in coherent stages. Each of these stages will be an Increment (see below). Products: Some of these may be folded together, and in a very small project there may just be the one document outlining the key points and plan. Executive Summary summarising the proposal. Business Foundations includes high level expectations, and a detailed business case. 3

4 Prioritised Requirements List expanded from the high level PRL in the Project Definition, with priority and high level acceptance criteria. Solution Foundations includes business processes before & after, information used, deployment strategy, initial solution architecture design etc, quality (technical & maintainability). Management Foundations includes governance, solution development life cycle, communications. Delivery Plan includes schedule of Increments, and defined timeboxes for the first Increment with expectation of what is in each timebox (though this will inevitably change). Delivery Control Pack includes risk log, change control records, issues log etc. Increments and Timeboxes A project Increment delivers a coherent set of requirements. That means developing and testing the solution, with technical and customer staff working closely together. The results should if possible be deployed at the end of the increment, so the University is getting benefits as soon as possible. Also the experience of deploying the partial system in the real world often helps clarify the rest of the project perhaps significantly changing the priority of the remaining requirements. Each increment is broken up into Timeboxes. Each Timebox is two to four weeks long (usually the same length throughout an increment). The Solution Development Team is given a set of requirements to solve in the timebox, and they can work together creatively to come up with solutions. If they only have one large Must Have requirement they will need to break it up into Must/Should/Could have elements so they can focus their time appropriately. Obviously the Must Haves normally get done first, though there may be sequencing issues which shuffle things around a bit. Any Could have and particularly Should have requirements which haven t been done go back up to the Project Manager and need to be scheduled into future Timeboxes, or dropped. 5. Evolutionary Development Evolutionary Development refers to the repeated cycle of exploration engineering prototyping which allows the Solution Development Team (SDT) to come to an optimal solution to the problem (given their time and resource constraints of course). It avoids the situation so common in traditional projects where the users define up front what they want (the specification) then the developers go away and build that, but when it emerges it isn t actually what was needed at all, or is a bad match. Detailed specifications up front almost always lead to disappointment at the end because we can t understand all the options and implications before we ve started exploring what it means, and what good would really look like. Evolutionary Development is essentially creative and collaborative, and the SDT must be delegated the authority to come to a solution themselves. 6. The Project Definition Every project has at the outset a Project Definition stating what is being done, when, for whom, by whom, and what might go wrong on the way. This document is crucial to the success of the project, and the Agile Project is no different in that sense from any other project. The shape of the Project Definition though will be a bit different from what you may be used to if you have been involved in a CiCS project before. If you are involved in the Feasibility stage it is essential that you read and understand the draft Project Definition carefully and raise anything that you are unsure about or feel is wrong or missing. And be clear about your role within the project if you are not happy with your responsibilities (which should be detailed in the Appendix) raise it now. 7. Change Management All projects have problems and/or new issues arising along the way, and managing those changes has always been a key part of a Project Manager s role. In Agile projects we welcome change, and indeed structure it into the project, as you ve seen above. As was noted at the beginning, the aim of effective Agile project management is to enable change, continuously correcting course, whilst maintaining the aim on the target which is a usable solution on the agreed date. So the constant change is not about darting about all over the place, quite the opposite. It s about having the flexibility and room for creativity which allows the project to successfully keep on track and do what it was set up for. Good communication and control is essential in all this, so if you are aware of a problem or opportunity do raise it straight away. 4

5 Of course if there is to be a change in the core aims of the project the Prioritised Requirements in the Project Definition then this must be agreed by the Project Board and whoever commissioned the project, including CiCS SSB. 8. Handover and Closure When the project deploys things into the live environment this has to be managed, with people and systems in place to look after the new or changed service. We have a Service Design & Launch Checklist to help manage this, and this should be considered right from the start of the project or increment to ensure the handover and go live works well. And eventually every project must be closed properly. There is a formal Project Closure document for every project, detailing what was delivered, any outstanding minor issues, how the system will be maintained and so on. Again this must of course be agreed by the Project Board. And a few months after closure there is often a formal review of the project. This gives everyone an opportunity to review the project's outcomes and identify future developments. This is the responsibility of the system owners rather than the Project itself, which has of course closed by this point. Often the CiCS Service Manager may be responsible for organising it, perhaps working with the original Project Manager. The form of the review will vary according to the type of system and/or changes which the project has implemented. For large systems there may even be a standing group set up to meet regularly to oversee how the system is used and can develop. Further Information The CiCS Projects website includes further information and resources. For more background on the Agile Project Management methodology the DSDM Atern website is an excellent place to start. If you would like more information please the CiCS Programme and Project Unit 5