Numărul 144
Numărul 143 Numărul 142 Numărul 141 Numărul 140 Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
Numărul 10
Abonament PDF

Prezentarea cărții: Going Agile de Gloria J Miller

Gloria J. Miller


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.

What is the book about

"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 applicability of agile, its benefits, and failures
  • Description of selected methodologies (Scrum, Kanban, Lean, XP) and agile practices
  • The agile techniques and skills needed for an agile coach
  • Agile practices aligned to the Project Management Body of (PMBOK®) Guide Edition 5 knowledge areas
  • Personal experiences from agile coaches and team members
  • A glossary of terms used in the book.
  • Profiles of agile and management experts referenced in the book.

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.

Book excerpts supporting cost management

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.

Recommendations from the book for going agile

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.

About Gloria J. Miller

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.

NUMĂRUL 143 - Software Craftsmanship


  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • BoatyardX
  • .msg systems
  • P3 group
  • Ing Hubs
  • Cognizant Softvision
  • Colors in projects