Over the summer of 2012, I decided to go for the Project Management Institute (PMI) launched an agile project management certification, the PMI-Agile Certified Practitioner (PMI-ACP®). PMI recommended some 10 books to read in preparation for the certification. I found the books very helpful and informative. I learned some new terms and new methods of working. Even though I have several years of experience with different agile methods, it was difficult to align those new ideas with the project management practices I was already using. I kept thinking, what now. If I started a project tomorrow, what would I do different from on my last project. Therefore, I decided to jot down my ideas and thoughts in short reference book. The book "Going Agile Project Management Practices" is the result.
"Going Agile Project Management Practices" is an extensive review of the literature with the content selected and influenced by my 30 plus years of experience. Agile and project management field consultants helped to review and form the structure and content of the book. They also added their expertise in the form of case studies and personal experiences.
The book is not specific to any one agile methodology. It synthesizes definitions, concepts, and practices that would be applicable to an executive, manager, or project manager that wants to be informed about agile.
The book is divided into four sections: A definition of agility, its benefits, and practices; a description of the agile practices as aligned with the PMI Project Management Body of Knowledge (PMBOK®) Guide—Fifth Edition; an overview of the considerations for selecting and implementing an agile methodology; and a reference guide of selected methodologies, terms, and people.
The key topics included in the book include:
The originality in "Going Agile Project Management Practices" book lies in its structure. First, it is a reference book or pointer to guide people on getting started with agile practices. Second, it approaches the going agile topic from two directions: adding agility to traditional projects or de-risking agile projects. Finally, it covers "agility" in projects as a topic and not one specific agile methodology.
For example, one of the key questions I had about agile practices related to cost management. If the agile teams are self-managing, deciding their own definition of done, and agreeing what scope they can complete, how does that relate to cost management? In my world, projects have budgets that are established and agreed at the executive level. The executive expectation is that the project will deliver "all the required functionality" for the agreed budget.
It turns out, agile projects use of "functional contingencies" and the review meetings to manage budget expenditure. A functional contingency is a reserve of features that may not be implemented should the project not be able to realize all product features due to budget or time constraints. The review meetings are used to evaluate progress against expectations and authorize or decline further investment in the project.
The following excerpts from "Going Agile Project Management Practices" are related to managing project scope and costs.
Chapter 6 - Integration: Scope is managed by prioritizing features to deliver the most valuable features first, establishing business rules for addressing changes, and deciding on the iterations scope at the last possible moment.
Chapter 7 - Scope: Functional contingency is defined based upon the feature prioritization. It is a reserve of features that may not be implemented should the project not be able to realize all product features due to budget or time constraints. [Dynamic Systems Development Method] DSDM suggests that the contingency is the effort to implement any features beyond the "must have" features and that the "must have" features should represent 60% of the total project effort. In this scenario, the contingency is 40%.
Chapter 8 - Time: Schedule contingency is a time buffer that is added to the schedule baseline to account for adjustments and fluctuations based upon risks or unknown events. The method for estimating the contingency will vary depending upon the estimation method used for sizing the project and a range to the velocity [the rate at which the team can deliver the features]. The simplest method is to calculate the expected project duration and add a percentage of time for contingency (e.g., 20%). For example, if the project was expected to complete in five iterations, a 20 percent contingency would have it completing in six iterations.
Chapter 9 - Cost: The costs baseline includes all the costs and the contingencies, including staff costs and other costs. Since the scope is delivered in iterations, the burn rate per iteration and burn rate per size unit are perfect for evaluating the cost performance. When the budget is at risk, the functional contingencies can be used as a tool to adjust the features delivered and maintain the project within its costs (Chapter 7).
Chapter 10 - Quality: The Test Plan should consider using Continuous Integration, Test Automation, and an Agile Tester as part of the quality processes. These practices are necessary to maintain a high throughput of user stories, minimize the build of technical debt, and deliver a high quality solution.
Chapter 11 - Human Resources: At least 10% of the team members should be experienced with agile practices if pair programming is being used; if not, at least 25% of the team members should be experienced. Splitting teams, training, and [external] coaching are effective methods for including experience into the project team.
Chapter 12 - Communication: Team space should be organized to facilitate free flowing communications amongst colocated and distributed team members. This may require adapting the facilities, using collaborative technologies, or undertaking additional activities.
Chapter 13 - Risk: Risks are scheduled for resolution by placing them in the product backlog during release planning, planning the risk actions during the iteration planning, and working on risk during the project iterations.
Chapter 14 - Procurement: The scope, change management, acceptance, termination, and deliverable sections of agreements should be adjusted to fit the operations of an agile project, including evolving scope, adapting to change, and early termination.
Chapter 15 - Stakeholders: The project stakeholder will have different interests in the project and will come from inside and outside the organization. Map the interests of stakeholders onto the project events, artifacts, and information radiators that will be used to engage them in the project or inform them on the project status.
Summarized altogether, the project budget should consider 100% of the functional scope, risks actions, quality infrastructure, facility changes (e.g., team space, collaboration tools), training and external coaching, and schedule contingencies. Change management involves establishing rules for when and how to use the functional or schedule contingencies. The project reviews become important milestones for stakeholder engagement and for monitoring and managing budget expenditure. Figure shows the budget considerations in agile projects.
There is no one right way for organizations or projects to transition to being agile. Projects are unique undertakings, and organization have different cultures for decision-making and management controls. Therefore, the book lays out the facts, describes the agile practices, and then gives the choice to the reader on how to best approach agility depending upon their situation.
The following are some things to do and to avoid for those considering adopting agile practices for the first time.
Select and customize the methodology based upon the environment. Do not assume that any one methodology will work out-of the box. Spend some time to understand the method and how it would fit into your environment. Understanding it, might mean applying it in a few iterations before customizing it.
Educate the leadership team. Management support is key and needed to implement and sustain agility. Invest time in getting the leadership team on board. They need to understand what changes and how they can support the team.
Define success. Define what a successful agile project looks like and manage expectations along the way. From Scrum, we learned about the term "definition of done." Define and agree what it means. Otherwise, the team may think they are successful while management may not.
Set-up the infrastructure. Being agile requires an investment in having infrastructure that supports quick changes. Define what infrastructure is needed and set it up.
Adapt management reporting. Projects need to be evaluated more on their functional scope coverage than they do on their on-time performance. Adapt the expected management reports and performance metrics.
Hold a retrospective and tune the processes. Review often what is working well and worth repeating, what could use optimizing, and what should never be repeated. There is no cookbook for going agile.
Avoid software-driven approaches. Avoid new project management software solutions until after the first two or three projects. Work without introducing new project management technologies until you learn about being agile. Introducing technology too early makes the transition about the technology and not about the practices.
Avoid confusion. Avoid trying to keep old practices while adapting to the new practices. It is tempting to try to keep old practices in place and not make the radical changes required. For example, going from a command and control project structure, where there is a project manager in charge, to a self-directed team means that the distributed authority can cause some uncertainty on who is in charge. Avoid trying to make the agile coach the project manager to avoid this discomfort. Agile practices do work, but they have to be given a chance.
"Going Agile Project Management Practices" is 442 pages is available at amazon, Barnes and noble, and other e-tail outlets for 18,10 euro epub and kindle and 23,99 paperback.
Gloria J. Miller is the founder of MaxMetrics, a Management, and Information Technology Consulting company that is specialized in providing experts and expertise in international projects and programs. She has more than 20 years" experience providing consulting in managing complex projects and realizing organizational change. Gloria has a master"s degree in business administration and undergraduate degrees in computer science and electronic technology. She is a Certified ScrumMaster (CSM), a PMI-Agile Certified Practitioner (PMI-ACP®), and a Project Management Professional (PMP®). Maxmetrics has offices in Heidelberg, Germany and Atlanta, Georgia, USA.