FEATURED BOOK: Managing Agile Projects by Sanjiv Augustine

In his book Managing Agile Projects, Sanjiv Augustine defines Agile Project Management (APM) as   "... the work of energizing, empowering, and enabling project teams to rapidly and reliably deliver business value by engaging customers and continuously learning and adapting to their changing needs and environments." This is a mouthful, but hits on two of the most important concepts that Agile teams must learn: to empower teams and to deliver business value. To do so, Augustine proposes some core practices that managers should follow. APM is a very different approach from the traditional plan-driven project management approaches common to most IT projects, that focus heavily on costs and controls.  

This book advocates that companies should adjust these six pragmatic practices to fit the needs of their teams:

1. Organic teams: Enabling connections and adaptation through close relationships on small, flexible teams.
   
   
2. Guiding vision: Keeping the team aligned and directed with a shared mental model.
   
   
3. Simple rules: Establishing a set of simple, generative process rules for the team.
   
   
4. Open information: Providing free and open access to information.
   
   
5. Light touch: Applying intelligent control to foster emergent order and maximal value.
   
   
6. Adaptive leadership: Steering the project by continuously monitoring, learning, and adapting.
   

I'll confess that when I first spoke with Augustine about his APM ideas in the fall of 2003, I was quite skeptical. At that time, he positioned APM as an alternative to the Project Management Institute Book of Knowledge (PMBOK), the industry's de facto standard for what project managers and teams should do and deliver on a project. I agreed with the need to manage Agile projects differently from waterfall projects, {sidebar id=1} but I did not feel that managers should throw the PMBOK out the window. What most managers lacked was the means to integrate their management processes effectively with their teams' development processes. With the appropriate foresight, managers should have been able to adjust their PMBOK-based processes to work with Agile development processes - but few had figured out how. Moving to a completely different management process, while intriguing, would not solve the management/development process disconnect.

Fast forward three years and it's clear that both of our beliefs have played out. I see an emerging industry that is adopting these pragmatic project management principles and is trying to incorporate them alongside legacy PMBOK environments. It's clear that APM's concepts provide a high-level framework from which to build a modern and Agile management team and still leverage the skills and assets of existing managers.

The bulk of Managing Agile Projects drills down into the six APM principles and discusses how managers and teams can adopt them. However, one of the most interesting chapters (chapter 2) defines the role of the Agile manager and the core skills and values that drive success. Just this chapter alone can enlighten a management team and lead to significant change for any process, not just to support an Agile process.

The book ends by addressing my core 2003 concerns: how to transform a traditional (usually PMBOK-oriented) management process to one that can address Agile projects' needs. Some of the transition steps represent philosophical changes, such as replacing software engineering with software craftsmanship and leading through presence rather than power. Others are more prescriptive, such as replacing work breakdown structures with feature breakdown structures, using release plans instead of Gantt charts, and implementing time-bound iterations (called time pacing) rather than scope-driven (or event pacing) iterations. This is indeed pragmatic advice that can help managers succeed in the 21^st century.

{mos_sb_discuss:10}

Comments (0)

Write comment

Show/hide comment form