The usage of agile planning practices, like product backlogs, planning games and stand-ups impacts the way that projects can be planned, and how portfolio planning in project management offices is done. Eduardo Miranda, associate professor at the Master of Software Engineering program at Carnegie Mellon University explains the need for planning in agile projects, and describes various planning techniques that can be used with agile.
He also looks on the impact of agile on project management offices and on the role of project managers in agile projects.
InfoQ: Eduardo, thanks that you want to do the interview with InfoQ. Could you briefly introduce yourself to the readers of InfoQ?
Eduardo: Hi Ben, thanks for this opportunity and the interest in my work. I am a software professional with over twenty years of experience in the development and management of software and process improvement programs. I spent my last ten years in industry working for Ericsson in Canada, and now I am an Associate Professor in the Master of Software Engineering Program at Carnegie Mellon University. I have published numerous articles on software development, estimation and planning and a book on Project Management Offices, Running the Successful Hi-Tech Project Office, which was published by Artech in 2003..
InfoQ: Newer methods in software development like agile and lean are changing the way that planning is done. Some even question if there is still a need for a plan. Are plans still useful?
Eduardo: Plans serve several purposes. First they help us think how we are going to approach the work before we start it, second they communicate the stakeholders when they should expect the project outcomes so they can plan their own activities, third they help coordinate the work among team members. Iteration and daily meetings fulfill this last function but not the first two. So yes, plans still useful. The problem I think is many people confuses a plan with an activity network or a task precedence diagram which are just a tiny fraction of the planning work.
InfoQ: Are there planning techniques that agile teams can use in their planning games, and stand-ups. Could you name some, and explain shortly how can they help the teams?
Eduardo: There are many techniques that can be used. Milestone planning is one of them. Milestone planning is planning in terms of intermediate and end goals to be accomplished by the project. This is the plan that could be used to communicate with the project sponsor and other stakeholders. It will specify when they should expect to receive some functionality or provide information and resources to the team. This plan is typically very stable, can be built early on the project and will make visible the impact of changes. With regards to “making visible the impact of changes” it doesn’t mean “not embracing change”, it simple means that when you change something other parts will move, and you want to be sure your customer understands the choices he or she is making.
Another one is the paired comparison technique for estimation. The idea is the same as in the planning poker to establish the relative size of user stories or features. Unlike the planning poker, paired comparisons forces you to compare one user story to several others, this triangulation of estimates reduces the possibility of getting the numbers wrong and is later used to compute a consistency index and average sizes. In several experiments I have performed in industry and in the classroom paired comparisons provide more consistent estimation at the expense of more questions. The planning comparison method is described in a number of articles. One by Martin Shepperd and Michelle Cartwright - Predicting with Sparse Data - and another by me: Improving Subjective Estimations Using Paired Comparisons.
There is also a tool that implements the method, that can be downloaded: The paired comparisation estimation tool. In both articles the idea of using comparisons, which was first proposed by Thurstone in 1927 to measure social values, is the same but the underlying math is different. In any case the “math” part should be isolated from the estimators and is only relevant to those wishing to develop a tool to support the method.
Eduardo: I know milestone planning from projects that didn't work agile. When we adopted agile at Ericsson, managing milestones as we had been doing with iterative projects became difficult and didn't really help the agile teams. Can you give examples how to use milestones with agile, product backlogs, and changing priorities that impact scope?
Eduardo: As you know I also worked for Ericsson. The milestone plans we prepared there were task oriented and dates in which they were due calculated using an activity network that started the first day of the project. The milestones I am talking here are different. I will try to summarize the idea in 5 sentences but for the interested reader I will recommend an article and a book, both written by Erling Andersen. The article title is “Warning: activity planning is hazardous to your project's health” and the book’s is Goal Directed Project Management. The difference between what Andersen proposes and what we did at Ericsson is that milestones in his approach correspond to things that are relevant to the sponsor and the team; they are chosen to represent the state of commitment between them, for example let’s say the sponsor needs to provide a special device for the team to prototype a GUI on it, this will be a milestone.
Following with the same example, let’s say the sponsor needs to arrange a marketing campaign around the new GUI, he will need to have a demonstration – not the complete GUI - finished before the end of the project so he can incorporate some images in his campaign. These two dates cannot be in total flux. The first one because the team cannot complete the prototype until the device is delivered by the sponsor, the second because the people running the campaign have lead times for contracting publicity spots, etc. In this example notice that the relationship between the first and the second milestone is a finish-to-finish relation: it says the prototype cannot be completed until the device is delivered. It does not say we cannot start working on the prototype until we receive the device. This is a fundamental difference with what we used to do at Ericsson.
Tasks are planned from the milestones backward. So for example when you plan an iteration, the prioritization will have to take in consideration this “global view” of the project and not only the immediate concerns alone. If you need to change the milestones, so be it, but you need to be aware of how that could impact other things down the road. The first milestone is what I call a “soft milestone”, a milestone that is under control of the team. If the delivery of the device is delayed it might have an impact on other commitments the team has made or increase the risk but the world will still be there the day after. The second milestone is of a different nature, it is a hard milestone. It is imposed externally by the advertising agency running the campaign. If the images are not submitted the campaign might not be lunched and that bring us to the next point: timeboxing and commitments.
InfoQ: Ok, let’s talk about timeboxing. Agile teams use time boxed sprints, to prioritize schedule over the deliverables. It helps teams to deliver at regular intervals. Do you think that timeboxing and sprinting are also an effective way to plan the work into projects or releases?
Eduardo: Fixed length iterations are good to help the team keep the pace and receive timely and regular sponsor feedback but dividing the total available time in two or four week chunks is not, by itself, something I would value as a sponsor. Timeboxes without agreed outcomes and decisions made two weeks in advance are at best, an expression of good will on the part of the team. If as an sponsor, I am counting on the software to launch a marketing campaign I need something more solid than the “4th iteration will be completed by the 3rd week of March”, I need to know what is the team can guarantee me I will have by that week in terms of functionality, level of service, support, etc.
InfoQ: Isn't this conflicting with agile concepts where the product owner and not the team takes responsibility for the scope to be delivered? And where the team only tries to deliver something in 1 sprint, and doesn't even commit to delivery, which is what the latest version of the scrum guide of Beck and Schwaber states?
Eduardo: I do not subscribe to this concept. I think we can do much better than discovering what needs to be done in a project two weeks at a time. Sponsors and teams need to have an idea of what they will be doing and by when. Do they need to know if they will be unit testing the “xyz” class on April 21st at 9:30AM? Definitely not. Do they need to know that they will receive the special device of the example the second week of April if they are going to have the prototype ready by the first week of March? Definitely yes. The fact that you might not know when a given task will be performed or if a particular feature of a deliverable will be included or not, does not mean that you don’t know when the overall work leading to a deliverable will have to be performed nor when the deliverable is needed or expected. The owner can take responsibility, but the team must bring to bear its knowledge and experience to commit. That is the difference between a professional and an amateur.
InfoQ: Some agile teams use MoSCoW to prioritize their backlog. Product Owners assume that a team can finish the "must haves" and probably also the "should haves" before the delivery deadline, but they sometimes don't know if it's possible. Is there something they can do to increase the certainty about the scope that will be ready on the deadline?
Eduardo: I have proposed two methods I have successfully applied in industry and academia based on the ideas of incremental development and the critical chain project management developed by the late Elyahu Goldratt. I called the first approach SPID (Statistically Planned Incremental Deliveries), a bad name looking back, and the second Buffered Moscow Rules. The ideas behind both approaches are the same, but the second requires only addition and subtraction of man-hours versus the aggregation of statistical distributions employed by the first. The simplification is not free. It comes at the expense of the claims we can make about the likelihood of delivering a given functionality and the overestimation of safety. Documentation for both methods can be downloaded from my web page Eduardo Miranda Publications.
InfoQ Getting better insight in the certainty when user stories will be finished sounds good. But customers, and also marketing and sales are used to fixed deadlines with an agreed upon scope. How can you deal with that?
Eduardo: The Buffered Moscow rules and the SPID method that I described above can provide the certainty required. The members of the team estimate the uncertainty in terms of normal and worst case development effort for each feature or user story and then ask the sponsor what are the things you must absolutely have by the end of the timebox, what would that be? Now, if you must absolutely have it, you would only commit to those things you can do in the allowed time under the worst case scenario. That is how you guarantee you can deliver what you say you would deliver. Of course if the worst case scenario is not the worst case scenario, then you might still not be able to deliver. Once you have selected the things you can accomplish under the worst case scenario, you will incorporate them into the plan using the normal case effort. This will effectively create a white space within the timebox you can fill now with “should have” features by repeating the procedure. If during execution worst come to worst, you will push out the “should have” and reuse the space left for the “must have features”. Because the total effort you have now corresponds to the sum of the worst case scenarios by definition you should be able to deliver on your commitment.
InfoQ: Many organizations use project management offices (PMOs) to manage their project portfolio. When they want to adopt agile, how does this impact their PMO?
Eduardo: As you know there are different types of PMOs. Some are in charge of enforcing a “standard process”, others are aggregators of information for the executive levels and others are involved in the balancing of resources and the management of the project portfolio. Given the space constraint of this interview I will concentrate in the last function: managing the project portfolio. One of the big challenges of managing a project portfolio is to avoid the propagation of delays from one project to the next through the links created by using shared resources, i.e. the developers working in one project are not available to work on other. To do that there are several things that can be done, the first is to separate projects that are amenable to timeboxing from those that are not and not using resources allocated to projects of the second class in those of the first class without considerable lead time. The second is to use “resource countdowns” and clear priority rules among projects to minimize multitasking and to let shared resources know in advance they will be needed somewhere else soon, so them and their teams can get ready.
InfoQ: Does this also mean that the role of the project manager will change when an organization adopts agile?
Eduardo: Definitely. In many cases project managers, in the traditional sense of the word are no longer required. Take for example the role of the project manager as pace keeper. In this role the project manager helped the team keep the pace of work through a combination of organizational and personal power using tools and techniques such as inspiration, status meetings, time reporting, recognition, rewards, warnings and sanctions. In agile projects, this monitoring and controlling function is replaced by the peer pressure implicit in the practice of daily meetings and illustrated by two of the three questions: what did you do yesterday and what are you planning to do today?, to be answered in a scrum meeting. Another example would be the change of task allocation from a push to a pull mechanism and the collective ownership of backlog.
InfoQ: So project managers will not be planning projects in detail, and following up on the activities when they work with agile teams. How do they manage scope, time, and money in agile projects?
Eduardo: As I said before the traditional role of the project manager as owner of the plan and task expediter does not exist in most agile approaches. The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework (2 Apr 2012) Sutherland states that in a Scrum project the scope, cost and completion date are “set during the project”, i.e. projects using the agile approach only commit to doing their best. According to the literature, what gets done is decided at the beginning of each iteration, with regards to time and money there are two approaches: one is when you run out of time and money you are done, this would be the timeboxing approach. In the other approach you keep going on until the sponsor says is enough, this would be more a time and material approach.
InfoQ: Thank you Eduardo for doing this interview with InfoQ
About the Interviewee
Dr. Miranda is an Associate Professor at the Master Of Software Engineering program at Carnegie Mellon University. Before joining Carnegie Mellon, Dr. Miranda worked for Ericsson where he was instrumental in implementing Project Management Offices (PMO) and improving project management and estimation practices.
His work is reflected in the book “Running the Successful Hi-Tech Project Office” published by Artech House in March 2003.Dr. Miranda is a certified Project Management Professional and a member of the PMI and the IEEE.