The Software Project Manager's Bridge to Agility
The Software Project Manager's Bridge to Agility
Join the DZone community and get the full member experience.Join For Free
10 Road Signs to watch out for in your Agile journey. Download the whitepaper. Brought to you in partnership with Jile.
Michele Sliger and Stacia Broderick, the authors of the new book The Software Project Manager's Bridge to Agility, are certified Project Management Professionals and Scrum trainers that have built a bridge from the traditional PMBOK® world to the agile world. In this book, they focus on transitioning project managers to become agile by shifting focus from "command and control" to "facilitation and collaboration".
This is a book of experiences that should be read by, both, project managers and those that are being managed. Whether you are an experienced agile practitioner, a C-Level decision maker, project manager, or newbie software developer, it is vital that you sing from the same hymn sheet as the rest of the team. This book is your song book.
I recently caught up with Michele and Stacia and asked them about their work, opinions on software project managment and agile software development. It certainly was an interesting conversation that kills more than a few myths!
Aslam Khan: How long have you been certified Project Management Professionals?
Michele Sliger: I passed the test on January 20, 1999.
Stacia Broderick: I have been a PMP since 2003.
Aslam: When did you start with Scrum?
Michele: At a biotech start-up in Boulder, Colorado in mid-2000. I was a project manager at the time. Mike Cohn joined our company as the new VP of Engineering and introduced us to Scrum and XP. Talk about being in the right place at the right time!
Stacia: I started practicing Scrum in 2003 while working for Primavera Systems as a project manager. Ken Schwaber trained our management group and taught us how to deliver increments of product in 30 days.
Aslam: With a PMBOK® background, what made you look at agile methodologies in the first place?
Michele: I didn’t seek it out; but when it was explained to me I had no trouble embracing it. I had been dissatisfied for a while. I felt as though I had done everything a good project manager was supposed to do, and yet I still had to deal with cost overruns, scope creep, schedule delays, and jaded team members. I was happy to try something new to see if that improved things. And it did! I haven’t looked back since.
Stacia: I also did not seek it out, and when it was explained to me, it did make sense but I was too concerned about my own individual set of responsibilities at first to pay attention to the bigger message. I finally 'got it' after the third sprint or so, when I saw key stakeholders and senior executives collaborating with teams. Seeing it in action provided me that first 'aha!' moment.
Aslam: What are the key variables that PMBOK attempts to manage in a project?
Michele: Most people think of the iron triangle: scope, time, and quality. But the PMBOK® Guide continues with several additional knowledge areas that it provides guidance around in addition to scope, time, and quality: cost, human resources, communications, risk, procurement, and integration. In our book we discuss the differences between a traditional and agile approach in each of these areas.
Aslam: Scrum, XP and others are agile methodologies while PMBOK is methodology independent. Yet both attempt to manage software development projects. Can you briefly explain the gap between PMBOK and agile methodologies?
Stacia: Firstly, Scrum, XP and others are not usually referred to as 'methodologies'. Methodologies tell people what to do, when to do it and how to do it. Scrum, for example, is an inspect-and-adapt mechanism, a light project management framework. The main difference between agile and traditional approaches is that agile projects are value-driven: they provide a focused approach to deliver value to customers early using an iterative and incremental approach and a way of working in accordance with the Agile Manifesto values (Individuals and interactions, working software, customer collaboration and response to change). The PMBOK® Guide’s process groups can be, and usually are, layered onto agile projects; the biggest difference in an agile approach is that with the coaching and leadership of a project manager, a team self-manages. The main gap is the “translation”of the PMBOK® Guide content to imply a waterfall approach—people equate the two mistakenly, so the PMBOK® Guide gets a bad rap sometimes when thinking of it as separate and adversarial to agile methods. The PMBOK® Guide does not equal waterfall!
Aslam: Many evangelists for both approaches, PMBOK and agile, view them exclusively. Do you also view them exclusively, complimentary or one providing guidance or governance for the other?
Stacia: I believe it is generally good practice to take things that work from a variety of sources. Just as agile teams practice XP development practices with other agile frameworks, agile project managers can layer on PMBOK® Guide process group knowledge to help facilitate projects. The PMBOK® Guide does not specifically name agile practices, and agile practitioners don't readily relate to PMPs; often there is a rift between practitioners of the two sides. I don't believe that either provide guidance or governance for the other. With that said, however, the PMBOK® Guide advises project managers to use the techniques that best fit their project scenarios, and agile projects attempt to control mayhem by breaking down big projects into smaller pieces (iterations), thus executing iterations in a plan-driven, 'simple', manner which is a more traditional approach. As a project manager, I am still going to perform "Risk Management" whether the project is traditional or agile; it might mean that on the agile project, the team will also own that realm. "Scope Management", "Cost Management", etc., still occurs in agile projects, just differently, by a different "owner". One could say that the PMBOK® Guide provides a wrapper for the processes that should occur in any project, whether agile or not, whether formally or informally. Agile gives us the values - customer focus and internal values - as well as the lean approach to consider. One size does not fit all. Unfortunately, the PMBOK® Guide is thought of as synonymous with "waterfall" and this is simply not the case; I'd have to say that the PMBOK and agile practices can complement each other if done correctly.
Aslam: The ideals of the agile manifesto and agile methodologies (especially Kent Beck's Extreme Programming) are truly philosophical, laying foundations in strong human values, building up on principles and then bridging the value system and principles with core practices. How does PMBOK® cater for such philosophical foundations?
Michele: The PMBOK® Guide does not spell out a guiding value system. But that is not its purpose. It is designed to be a guide to generally recognized good project management practices—not “best” practices. In fact, it states on page 3 of the Third Edition that “Good practice does not mean that the knowledge described should always be applied uniformly on all projects; the project management team is responsible for determining what is appropriate for any given project.”
The PMI however does have a Code of Ethics and Professional Conduct that states their values: vision, responsibility, respect, fairness, and honesty. You can learn more by visiting their website at http://www.pmi.org/AboutUs/Pages/Governance.aspx
Aslam: Agile and PMBOK® both try to mitigate risk. How is the view of risk different between the two and how can we bridge that view, if there is a difference?
Michele: There is more of an overt interest in risk in traditional approaches because too often the methodology they’ve chosen does not intrinsically support risk management. In other words, they’ve got to work at constantly being on the lookout for risks and thinking of contingency strategies. Many times this results in infrequent risk planning meetings, with limited or no attendance by team members, to review a template or checklist of possible risks (which can lead to passive compliance rather than real brainstorming).
Agile frameworks on the other hand have multiple planning, inspect and adapt, and feedback cycles built into their approach, as part of their iterative and incremental delivery process. Therefore risk management is more of an organic practice, emerging naturally as the teams plan an iteration, and as they review and retrospect at the end of each iteration. Because of this, risk management in an agile team tends to lean more so to qualitative risk management rather than quantitative. This is not to say that agile teams can not do quantitative; it does mean that quantitative risk management in an agile team would be a more overt practice in an otherwise organic process.
In addition to agile’s empirical approach that intrinsically supports risk management, there is also an emphasis on team ownership and accountability—meaning the project manager is not the only one identifying risk events, triggers, and contingency plans. The team is also responsible, and does this as part of each planning and review meeting. Even the daily stand-up meeting can uncover a risk as team members share what’s keeping them from making progress.
Aslam: In my experience, there are two techniques that truly makes agile methodologies agile - stand up meetings and retrospectives which are great feedback mechanisms. How do these map to traditional planning and estimate management?
Stacia: These techniques are only parts of the agile framework. I can do a daily stand up and a retrospective all day long in a waterfall project scenario, and that does not make me agile. There are other things that go along with these meetings - values, delivery, optimizing the whole, removing waste, etc. To answer your question, however, the standup relates to planning and estimating in that it is the team's mechanism by which they synchronize and inspect and adapt their tactical plan to meet their iteration goals. It is the built-in daily risk mitigation technique by which the team asks "What did we do yesterday toward our goal, and how does that affect today? What is in our way of meeting our goal?" Everyday, the team will observe if their iteration status is 'burning down' - that is if they are completing all of the work that they selected during iteration planning. That's how it relates. The retrospective, on the other hand, is the meeting at the very end of the iteration when the team inspects and adapts its overall process. They want to know how the previous iteration went, and what they want to focus on for improvement. Hopefully, this will lead to more efficiency in delivering the next iteration's worth of functionality, which could affect future baselining and project schedule projections.
Aslam: When PMBOK exists in an organization, agile is often viewed as disruptive force. What's your recommendation: covert, overt or guerrilla tactics to get agile into the organization?
Michele: I don’t have a standard response, other than to ask those with interest in agile adoption what they think. They know their corporate culture better than I, so I take their opinions seriously.
There’s nothing wrong with the stealth approach (covert), as it allows a team to try it out and quietly learn from their mistakes and improve in a safe environment. However, once they begin to deliver in a regular cadence, the rest of the organization will take notice, and they’ll be stealth no more.
Overt is fine as well, particularly if it is the management group that wishes to implement agile. They should be very open about their plans and expectations, and give their staff time to ask questions, voice concerns, and get prepared for the coming changes. Openness and honesty are key agile values, and it’s best if the management team embraces these values from the beginning.
When you say guerilla, are you speaking of inserting an agile practice here or there without calling it agile? That’s fine, too. Any legal/ethical technique that improves quality and customer satisfaction and time to market is usually a good one to use, regardless of what we call it.
But if you are using guerilla to refer to the marketing of agile in the organization, then no, I prefer a viral marketing approach. Let the results of the stealth teams speak for themselves.
Aslam: Agile has a very strict focus on managing quality and many agile hard-liners take the position that scope can be sacrificed for quality delivered against an immovable milestone. What is your opinion on this position?
Stacia: We believe that cobbling the 'right' release is a continuous collaboration effort by the team and the product owner. The rate of burndown in a release backlog must be made visible so that the product owner can make decisions regarding scope, time and cost. Sometimes, there is a 'minimally credible' set of functionality that must be delivered; it is up to the product owner to work with the team to come up with the best release approach given the constraints. We are of the opinion that good code quality must never be sacrificed; making quality trade-offs for time will only get you in the long run. Someone once quipped that "Quality is when the customer returns and the product doesn't." We buy into that.
Aslam: With a resource based view of a project, PMBOK® is reasonably good at cost estimations, while agile teams will hardly plan past the first couple of iterations. That is just one key item that stakeholders want
to see - "What is it costing us?" What, in your experience, has been a good balance in providing such feedback to stakeholders when using PMBOK® in an agile project?
Michele: I’d first like to point out a couple of common misconceptions. First, agile teams can and do plan past the first couple of iterations. Teams that we work with plan for the iteration, the release or quarter, and the product owner prepares a product roadmap that looks at multiple quarters (usually four). In agile, the detail is greater the closer the time horizon—therefore iteration planning is detailed to the task level, while roadmaps simply cover a high-level theme and a few key features.
Second, a resource-based bottom-up cost estimation isn’t necessarily a reliable indicator of cost. Most projects will run over their initial projections, or include quite a bit of padding and contingency funding to make sure they can finish. If the budget is inspected and modified on a regular basis to reflect new knowledge, then it is a useful tool.
Agile budgeting is regularly inspected and modified, but without the waste (in terms of time and effort) in a bottom-up approach. We accept that there will be uncertainties and unknowns, and use a top-down approach to derive our cost estimates. This is done through the use of a gross-level estimation of the relative size of each item in the product backlog, and then calculating cost based on the team’s loaded labor cost and velocity. Here’s a quick example: a team is using points (the Fibonacci sequence) as their gross-level estimation tool, and they can do 100 points of features on average in an iteration. Their loaded labor cost to the organization for an iteration is $300,000. Divide the total loaded labor cost by the total points, and you’ll have each point costing $3000 to implement. So the total cost of your project, based on what you know today, is $3000 times the number of points in your product backlog.
I’d like to add that the gross level estimates of the items in the backlog are submitted by the entire team using the wide-band Delphi method. It’s commonly referred to in the agile community as “planning poker”. You can try it yourself for free by visiting www.planningpoker.com
Aslam: In your opinion, how should teams start with agile ... take the plunge or dip a small toe in the water first?
Stacia: My approach is to simply start with the Scrum framework. This puts the focus on deliverable product increments, which is easy to talk about and quite difficult to implement. It is difficult because Scrum pinpoints all of the difficulties with delivering product - these are impediments. This two-layer Deming approach is quite effective to help a team uncover the practices it should be doing in order to deliver product increments every iteration. Those discoveries often - usually - lead to the implementation of XP practices within the iteration. We prefer this method of a team utilizing iterations to learn for themselves how to more efficiently and effectively produce good software. Cramming everything down a team's throat all at once is usually not the best way to go, and doesn't fit the paradigm of self-managed teams!
Aslam: As a Scrum trainer what would you tell your PMBOK® project leader in the elevator ride to the top floor?
Stacia: Gosh, there are so many things I'd tell this person, and it would fully depend on how much that person really wanted to hear from me. Some things I've said in the past (in a non-elevator statement way): Learn something new. Expand your horizons. Learn how to gain more visibility into your projects by empowering teams. Turn projects into valuable endeavors that keep your customers coming back for more. Accept the fact that we cannot predict the future. Have fun and don't be afraid.
Aslam: Michele, Stacia ... thank you for your time and sharing your experience and knowledge with us. Good luck with your book and keep on helping us bridge old divides :-)
This chapter, Scope Management, is excerpted from the new book, The Software Project Manager's Bridge to Agility (http://www.informit.com/store/product.aspx?isbn=0321502752), authored by Michele Sliger + Stacia Broderick, published by Addison-Wesley Professional, May 2008, ISBN 0321502752, Copyright 2008 Pearson Education, Inc."
Opinions expressed by DZone contributors are their own.