Agile Project Management Tomas Gustavsson Sanoma Utbildning
1
Sanoma Utbildning Postal address: Box 30091, 104 25 Stockholm Visiting address: Alströmergatan 12, Stockholm Website: www.sanomautbildning.se E-mail: info@sanomautbildning.se Order/Information about educational materials Phone: 08-587 642 10, telefax: 08-587 642 02 Editor/Project manager: Amanda Schött Franzén Cover and graphics: Anna-Karin Nilsson and Filip Rensfelt Translation: Linnéa Holmén, Calyptic AGILE PROJECT MANAGEMENT ISBN 978-91-523-5743-9 © 2019 Tomas Gustavsson and Sanoma Utbildning AB, Stockholm First edition. First printing. Copyright This work is under copyright protection. Copying without a teacher’s authorization to copy for educational purposes according to the BONUS Copyright Access agreement is prohibited. This type of agreement is signed between copyright organizations and representatives of educational providers, e.g., cities/universities. For information about this agreement, please refer to the educational provider representative or BONUS Copyright Access. Anyone who commits a copyright infringement may be prosecuted in a court of law and sentenced to a fine or imprisonment for up to two years, as well as be obliged to reimburse the author/copyright holder. Printed in Lithuania by Balto Print, 2019
It isn’t this book that will make you an agile project manager. Yes, you read that right. Being agile actually means testing, evaluating, and improving your way of working every day – and only your own performance can make you become a successful agile project manager. However, I promise that this book, through suggestions, advice, and exercises, will serve as a good source of support, if you have the courage and willingness to change the projects that you lead or the organization you manage. Here, you can both gain inspiration and get practical guidance on your journey toward becoming a project manager in more efficient, stress-free, and flexible projects. For those of you who are curious about the philosophy and ideas behind the agile way of working, I hope the book will provide a solid foundation. Thank you to everyone who has reviewed, discussed, and philosophized over the contents of this book with me! A special thank you to my friend, John Johansson, who has the ability to turn a perspective on its head and question the obvious. My colleagues in the field of Project Management at Karlstad University have also earned a big thank you. Of course I also want to thank you, dear reader, for wanting to learn more about this area, so close to my heart. I wish you a pleasant read and ask you to contact me if you want to discuss what I have written. This translation is based on the third Swedish edition of the book and I am thrilled that so many people have shown an interest in agile project management. Some of those who have shown a particularly large interest are managers. They often ask questions about how their situation will change when the operations become agile. In recent years, a version of the agile framework, called Kanban, has gained popularity in many arenas. I therefore included more information on that area in this edition. I am very grateful to get the chance to develop and improve the book with new editions. Because that’s what agile project management is all about: improving your way of working, every day. A challenge for any company that wants to use an agile way of working is that it must change both its values and practical aspects of the project teams’ work. Both changes are important, but it is difficult to change values without seeing what this means in practice and it is hard to get practical details to have an effect without understanding the values. In this edition, I have therefore included more detailed descriptions of both values and practical details. Tomas Gustavsson, April 2019, Karlstad
Content Chapter 1. What is agile project management? 7 What does agile project management give you? 9 The agile view of time and result 13 Project phases 17 Summary 21 Chapter 2. The agile manifesto and the history behind the methods and framework 23 The history of project management 25 Lean 26 The creation of the agile mind-set 29 The agile manifesto 32 The 12 agile principles 36 Summary 40 Chapter 3. Roles 41 The team 43 Project manager and scrum master 48 The product owner 57 The steering group 63 The reference group 67 Suppliers 68 The manager’s role in agile projects 69 Summary 70 Exercises 71 Chapter 4. The pre-study 73 Often overlooked, but not to be neglected 75 The questions in the pre-study 77 Stakeholder analysis 78 The vision 83 Plan your communication 87 Workshops 91 Summary 93 Exercises 93
Chapter 5. Planning 95 Planning in the short or long term 97 Roadmap 99 Delivery plan 104 Sprint plan 106 Product backlog 108 Sprint backlog 114 Time estimates 119 Summary 128 Exercises 128 Chapter 6. Execution 131 Project board 133 Stand-up meeting 138 Presentation at the end of a sprint 145 Retrospective 147 Continuous 150 More on Kanban: working without pulses 153 Practices 154 Summary 165 Exercises 166 Chapter 7. Project closure 169 Closing an agile project 171 Handling over or not – that is the question 174 Project closure 178 Summary 179 Exercises 179 Chapter 8. When is the agile approach suitable? 181 Good conditions for agile projects 183 Poorer conditions for the agile approach 185 The agile approach in large projects 188 A damaging culture 191 Appropriate project types 195 Distributed teams 197 Summary 200
Chapter 9. Templates and checklists 201 Supporting documents 203 Checklist – Is agile project management suitable? 204 Checklist – Questions to consider 205 Checklist – The product owner 206 Checklist – Getting started with agile project management 207 Template – Project analysis 208 Template – Roadmap 209 Template – Overall delivery plan 210 Template – Detailed delivery plan 211 Template – Product backlog 212 Chapter 10. Project manager stories 213 Sven who work at an IT consultancy firm 215 Elin who performs event projects 218 Peter who works at a call centre 222 Summary 225 Literature 226 Image list 229 Index 230
Agile project management offers a website with handouts, templates, and checklists, as support for teachers, students, project managers, and project teams: www.sanomautbildning.se/agile
What is agile project management?
7
Agile project management is about executing projects in a more flexible way. The word “agile� means to move quickly or easily. Being agile means that an organization has the flexibility needed for continuous improvements and development of its operations. Among all the things described and defined about what agile is, there is one overarching principle: Each day, trying to do things better than they were done the day before. The agile approach means that the project team has a mandate to make its own day-to-day improvements, and is allowed to make mistakes, learn, and change its way of working throughout the entire project.
8
Chapter 1
What does agile project management give you? Many operations have gained great success by shifting to an agile approach. The company Yahoo!, in an internal survey (Benefield, 2007), describes an increase of its productivity by on average 34 percent, just from changing its way of working. A number of factors set agile project management apart and can help companies achieve this As to methods there may kind of improved efficiency. Here are some of the most important ones: be a million and then
Managing changes
some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.
Agile project management is focused on an obvious truth: There are always changes in projects. Big ones and small ones, well and poorly planned: all projects are subject to changed conditions. In many projects, the project manager is criticized if the project (Ralph Waldo Emerson) does not go according to plan – as if it was expected that the future could be predicted in every detail. Many project managers complain about the administrative burden of changing and updating plans when a difficult reality makes itself known and a project doesn’t turn out the way it was expected. Furthermore, changes due to new insights or market conditions are often what make a project a success – not the original plan. An agile project manager has the support of a framework that means changes can be dealt with in a much more efficient way than under most traditional project management methods. Working in an agile manner means working in shorter steps, which are often less than one month long, where the project’s requirements and goals can change in each step.
More customer value throughout the project Within traditional project management, there has always been an awareness that the customer’s or sponsor’s participation is vital. But few have been able to explain how this should be achieved. An agile project manager has a way to
What is agile project management?
9
involving the customer in the project, regularly and in a structured way. Since results are delivered after each short sprint, the customer is “forced” to have an opinion at each stage of the project. A customer or sponsor will know that everything can be changed at the end of each sprint. The customer does not have to worry if all the requirements have not been noted down in detail, as there is an opportunity between each step to change, increase, or remove requirements or goals in the project. This means that the customer’s value from the project is maximized and that there is no need to worry about what will happen at the end of the project, thanks to the regular, frequent involvement throughout the project. The customer can also end the project at any time and need not worry that too much money is invested in it. An agile approach can thus give more value per invested monetary unit. In most agile projects, this also means that value is delivered frequently and on a recurring basis, not just at the end of the project, as is often the case in more traditional projects. The project team tries to deliver a working project result that the customer can apply and earn money on, at the end of each short step, even at the early stages of the project.
A motivated project team The phrase “project management” might make you think of a project manager, the role that is usually in charge of the project’s results. The concept of roles is slightly different in agile project management as compared with in traditional project management. The focus in agile project management is primarily on the team’s ability to manage a project, not the project manager’s. The agile perspective means that the team should be independent and decisional, as the team members are the ones who know most about the details and problems in the project. Agile project management has often originated as a reaction to environments where all the decision-making has rested on the project manager and the voices of the team have not been heard. By getting the project team to feel responsibility and have a mandate, the project manager’s time and energy is freed. The project manager can work on things that result in real efficiency: clearing obstacles and paving a way for the team. Anything that obstructs or prevents the team is a waste of time, money, and results, and should be prioritized by the project manager to ensure that the project work is as efficient as possible.
10
Chapter 1
A stable and reasonable workload Agile project management means shared decision-making and influence from all members of the project team. The opinions of each participant are taken into account when deciding how work will be performed. It is not just a right, but also an obligation, to have opinions and suggestions on how to create the best solution for the project. In each short stage of the project, the project members also get to show what they have done and get direct feedback from sponsors and customers. Naturally, this makes agile project teams highly motivated in their work. They will also be happier, as they get the respect they deserve. This is because each short, defined step has an even workload. Many years of project research has (finally) shown the quality problems that arise if a project team is pushed to work unreasonable overtime and is pressured to hand over project results that could have been much better with a few more hours’ improvements. If you have a project team under extreme pressure, you will often reap accordingly at the end of the project, when errors are discovered, which usually leads to delays. In an agile project, the team strives for a stable pace in their work, with a focus on completing each step before beginning the next one.
An airplane cockpit for projects Many complain about the unclarity of status and progress in projects. Project sponsors yell and project managers despair at the unclarity regarding the actual status of their project. In agile project management, there are a number of metrics and visualization tools that facilitate for everyone involved to see how far the project has progressed, down to the second. This can be likened to an airplane cockpit full of instruments that show the current status in different aspects. These instruments are based on simple techniques that do not require a lot of administrative work. One of these tools requires no administrative work at all, as it relates to closer, more structured communication between team members, which means that everyone knows what everyone else is doing at any given time. For the stakeholders, the instruments provide a simple, efficient insight into the project’s immediate status.
Appropriate for many industries Agile is a collective name for a number of frameworks, with Scrum and eXtreme Programming (XP) being the most common ones. Some of these
What is agile project management?
11
frameworks are based on lessons learned from projects that succeeded against all odds. For projects that have undergone crises, where control has been regained, the question has been: “If this works in a crisis, why wouldn’t this work in a regular project too?” Other agile ways of working have arisen from studies of values, principles, and technologies in the manufacturing industry, which have been refined and adapted for performing projects efficiently.
The agile frameworks were developed in the IT sector for software development. This does not mean that you have to be in the IT sector to use an agile project management. Whether you work with non-profit projects, sub-projects in a small organization, or in a global corporation with a tried-and-tested project model, you can benefit from adopting an agile perspective. Today, many and diverse operations use agile project management, from event companies and call centres to units within the national defence developing various military strategic concepts. Still, the frameworks are better suited for some situations than others, which is described in greater detail in Chapter 8, “When is the agile approach suitable?” Depending on the situation, you may not be able to use all aspects of the agile approach, but the underlying concept can be applied everywhere, regardless of the project type.
12
Chapter 1
The agile view of time and results In the next chapter, some descriptions are presented comparing the agile way of working with traditional project management concepts.
Time-boxing Time-boxing means defining a goal for a certain time period and then letting that time be the ruling factor. Making the best of the situation within a given time period is what time-boxing is all about, and is a fundamental part of the agile way of working. The short work cycles, with frequent stops for showing project results and reflecting on opportunities for improvement, are time periods in which the project is making the best of the situation. Time, not requirements, is the non-negotiable factor. By working toward a deadline, you are forced to prioritize what is important and less important. This prioritization is a crucial part of the sponsor’s or customer’s work with the project team. As the customer cannot always be present and give information on details, the project team needs to know what is most important from a value perspective in order to make the right prioritizations during the course of its work.
TIME-BOXED BIRTHDAY PARTY Imagine that you are throwing a 60th birthday party for a relative. The birthday is on a Saturday in two months’ time, and the party will be held on the big day itself. However you plan, there is one factor you can never change: the timing. This means that you have to make sure the most important things are solved and that less important things can be eliminated if you run out of time. If the Brazilian napkin rings take three months to deliver, you can remove them from the plan without it being a disaster – the party will be just as fun without them. However, the cake is expected and high up on the wish-lists of everyone participating. Deciding on and ordering a cake must therefore be done at an early stage, so there is no risk that it will be deprioritized later because of time constraints.
What is agile project management?
13
The project management triangle A common way to define a project is based on the three parameters time, cost, and result or scope. These can be said to create the boundaries for the project and are, for pedagogical reasons, often presented in the form of a triangle. The project management triangle springs from traditional project management methods.
Result
Time
Cost
A PROJECT HAS THE FOLLOWING BOUNDARIES: Time Cost Result or scope Within the American organization for certification of project managers, PMI (Project Management Institute), the project management triangle is also called the triple constraints, as it shows the constraints for the project goal. These constraints become particularly important when the project deviates from its original plan.
14
Chapter 1
This option shows how we change the cost boundary in order to perform the project with unchanged boundaries for time and result.
EXAMPLE – CHANGED BOUNDARIES
The project “A wooden bridge over Black River” “The goal of the project is to build a wooden bridge over the river for less than SEK 200,000 and the bridge should be open for use no later than June 30.” The three constraints defining the project are: Time: June 30 Cost: SEK 200,000 Results: Wooden bridge Let’s say that the project activities have taken a long time and delivering on the proposed date will be difficult. The project manager must raise the problem with a project sponsor and present different options based on changes to the three boundary conditions: Option 1: The project could deliver on time if more members were added to the project team. However, this would mean a higher cost than planned.
Option 2: According to the plan, a fancy woodworked railing was supposed to be made. If the project team instead makes a simple, functional railing, it will be able to deliver on time and within the planned budget. In this option, we are changing the result boundary in order to perform the project with unchanged boundaries for time and cost. A third option could show how we change the time parameter to retain the boundaries for cost and result. However, this is often difficult in practice, as the number of hours worked and the total cost are usually intimately linked in projects. Another option might be to change both the time and the cost boundaries in order to get the desired result.
Time is sacred Agile projects operate based on the time-boxing principle, meaning that the timeframe of each stage of the project is fixed. This means that the project team always adjusts the result parameter. The instances when the plan does not match reality are thus managed by cutting back on the project’s results or scope. Some would immediately react to this principle and say: “What does ‘adapting the result’ really mean? You wouldn’t know what will be delivered if you adhere to such a principle! That’s no way to perform a project, especially not when a customer has ordered it, and you’ve already promised what
What is agile project management?
15
the results will be.” I’d advise any reader who reacts in this way to take a deep breath, relax, and read the following description of the agile approach: The agile approach with time-boxing means that a project team in each short cycle (or sprint) sees time as being sacred. This means that the right things are prioritized first and that things that aren’t finished will simply not be done within that sprint. But that doesn’t prevent the sponsor from moving the project deadline. The approach provides very clear early signals on how the project is going. If the project decides to use three-week sprints and the entire project is expected to be done in ten sprints, everyone can see how the project is progressing after each three-week sprint. If the project has only achieved eight out of ten planned sub-objectives after the first sprint, the organization can make a decision for the entire project based on the project management triangle. WHEN NOT ALL SUB-OBJECTIVES ARE NOT ACHIEVED
The project can be granted more resources, for instance corresponding to twenty percent, in order to complete all the work required. Parts of the project result, which were planned to be created later in the project, can be scoped out. The project can warn recipients of the project results that it currently looks like it will take for instance twenty percent longer than expected. This changed overall planning is made easier through time-box thinking, as it provides an honest and clear advance warning. The concept of time being sacred applies to each short sprint. For the project as a whole it is up to the sponsor to decide if the project should be extended, shortened (by scoping out requirements), or granted more resources in order to achieve all the requirements on time. Projects in which everyone has been working too hard to meet all the requirements ahead of each deadline often suffer from problems with project quality. Burning the midnight oil can often lead to people making mistakes or choosing the simplest solution they can think of, without questioning if it is appropriate or not. If you have many short deadlines instead, the quality will be improved because each aspect will be properly done, and the negative effects of not meeting certain requirements
16
Chapter 1
on time are minimized, as the next deadline is only three weeks away. Chapter 6, on execution, will describe in greater detail how to prioritize if there is a lack of time within a sprint.
Project phases One of the strengths of traditional project management is its clarity regarding structure and the bigger picture. The traditional project structure is relevant also to anyone choosing to work in an agile manner. Many of the terms used there have become standard, although some things have several names. Therefore, it is appropriate to define some basic concepts that will be used in this book to describe the different parts of a project. Traditionally, a project is divided into different phases.
Pre-study
Planning
Execution
Handover
Closure
Traditional project model with typical division into project phases. THE UNDERLYING ASSUMPTION OF BENEFITS FROM DIVIDING A PROJECT INTO PHASES:
It is easier to focus your energy on a limited area than having to handle many things at once. Through the use of defined steps, you can finish one part before beginning the next.
Pre-study phase Pre-study
Planning
Execution
Handover
Closure
The pre-study serves to provide an answer regarding what the project is supposed to achieve. This is usually where we define the project boundaries, setting up limits for time, cost, and scope.
What is agile project management?
17
Planning phase Pre-study
Planning
Execution
Handover
Closure
In this phase, the goal is to provide an answer to the question of how the project is to be executed. The results of the planning phase include a time plan, a budget, an organizational schematic, and often a risk assessment.
Execution phase Pre-study
Planning
Execution
Handover
Closure
Here, the project is executed for the second time. During the planning phase, the project was executed in theory. Now, it is executed in reality. The project management work is focused on follow-ups and adjustments.
Handover phase Pre-study
Planning
Execution
Handover
Closure
When the project has been executed, the project results are often handed over to another party. An office building is handed over to the maintenance crew and the newly developed product is handed over to the manufacturing department to begin production.
18
Chapter 1
Closure phase Pre-study
Planning
Execution
Handover
Closure
Being in the closure phase of a project entails tying up all the loose ends and sometimes returning resources and writing final reports. In a project with an external customer, rather than one in-house, this may include the final payment.
Decisions at phase transitions At each phase transition, there is usually a decision point. This means the steering group or sponsor must make two decisions: 1. Shall we initiate the next phase? 2. Shall we end the preceding phase? Many would see this as a single decision (ending one phase to begin the next). However, to get a better grip on the project and its resources, there are benefits to gain from dividing the decision into two parts. Consider the example of a road construction project that is at the end of a planning phase, with the end of the work week drawing near. A tar boiler has been ordered and will be delivered to the site on Monday morning, when the execution phase is supposed to begin. When the steering group, on Friday afternoon, reviews the documentation that was the result of the planning phase, they realize that the budget calculations must be improved before the plan can be approved. If they see the decision point as a single decision (ending the planning phase to begin the execution phase), the project may become overly expensive. Delivery of the tar boiler would need to be rescheduled, as would the crew that was supposed to start working on Monday. If the phase transition is seen as two decisions, the steering group could give the following answers to the above questions: 1. Yes, we will initiate the next phase. 2. No, the documentation needs to be improved before we can end the preceding phase.
What is agile project management?
19
However, problems are often larger than in this example. In many project organizations, decision points are seen as things that simply pass by, rather than chances to make real decisions about initiation and closure.
Flexibility at phase transitions Through the use of phases and decision points, the project can gain a structure and better possibilities of good steering. However, there is a risk inherent to this technique: you can get an overly simplified idea of projects as things that move along in tidy, exact steps, making you think that if the project does not follow these exact steps, something is wrong. With a steering group that is overly focused on the project following certain steps, the project manager may end up focusing mainly on ensuring that the project fits the model. “But why is that a bad thing?” might be a natural question. Let’s say we have a project with the goal of creating the most awesome bike ever. We know that the competitor Superbike is working on a new type of bike, so time is short. The project AwesomeBike needs to plan for four different parts: frame, gears, steering, and wheels. During the planning phase, the project manager realizes that a sub-contractor in two months’ time will be releasing a new gearing system that will astound the world and which could be used in the project. Therefore, the project manager cannot finish the project during the planning phase, as she wants to include the new gearing system in the AwesomeBike project. When she suggests that they initiate the project without an important part of the project planned, the steering group scoffs at her and says: “If the planning phase isn’t finished, we can’t start the execution phase. Surely, you realize that?” Dejected, she plans for the use of the existing, less impressive gearing system – in order to get the planning approved, so she gets permission to start the execution phase. This flawed view of the project as a series of distinct phases is one of the things that has led the agile movement to reject the traditional way of performing projects.
20
Chapter 1
Summary The main principle of agile project management relates to flexibility and an ambition to continually improve the project result, as well as the way of working within the project. This is achieved through short sprints consisting of cycles in which you plan, execute, review, and then act based on conclusions drawn. In agile project management, you do not change the length of the sprints. Because the work is divided into sprints, it becomes obvious at an early stage if the required results and time boundaries are reasonable. Agile project management is not really about the project manager as a decision-maker, but rather about getting the team to manage the project by giving it a mandate, so it can become self-organizing. The project manager’s main focus will be on removing obstacles, so that the team can achieve maximum efficiency.
What is agile project management?
21
The agile manifesto and the history behind the methods and frameworks
23
What was it in the traditional way of executing projects that did not work and meant that the need for new, agile ways of working was born? How did the Lean framework arise and how is agile project management related to it? It is a slight simplification, but you could say that the agile ways of working have developed both as a counterbalance to the traditional project management and with the values of Lean as an inspiration and model. Understanding this background is a key to understanding the agile principles.
24
Chapter 2
The history of project management Most of the methods, tools, and procedures used in traditional project management date back to the Cold War era. The most commonly used scheduling tool, the Gantt chart, is even older. It was developed for large US construction projects History does not flow in a broad in the 1910s. The aim of the project management river, but in many small streams. methods devised after the (Alberto Moravia) Second World War was to complete defence projects before “the other side� beat you to it. NATO was competing against the Warsaw Pact members in everything from space flight to long-range ballistic missiles. The main focus was on lead time, i.e., the calendar time it took from the beginning of a project to its conclusion. The more activities that could be done in parallel, the shorter the lead time for the project.
Large projects, large resources Some of these enormous military projects involved more than 200,000 scientists, engineers, and military personnel. The resources were almost unlimited and the challenge for project managers was to coordinate the massive numbers of people, activities, materials, and resources. The tools that were devised during this era served mainly to minimize lead time and coordination. They include the Work Breakdown Structure (WBS) and logical networks using the critical path method. The same principles are still used in large projects, for instance when the company Ericsson is rolling out a new mobile phone system. In less than 24 months, the project must grow from just a few individuals who perform a pre-study up to 2,000 people during the busiest phase. The work force in the project then decreases until it is phased out entirely, with a single project manager handing over the final report.
More and smaller projects The traditional tools for planning and follow-up are now taught in projects of all kinds. But the main strength of these tools (coordinating a large number of people and getting the shortest lead time possible by conducting
The agile manifesto and the history behind the methods and frameworks
25
238