The fact that ths book “Agile Project Management” by Jim Highsmith is already at his second edition after a first publication in 2004 says something about its value. In one of his definition of Agile, Jim Highsmith says, “Agility is the ability to balance flexibility and stability”. I will say that his book balances nicely high level thinking and a pragmatic approach. The book provides a framework for running agile projects and gives also insight in some more neglected related topics like managing projects portfolios or measuring the success of Agile projects.
Jim Highsmith starts by defining what Agility is and emphasizes that Agile is about “delivering value over meeting constraints”. The book describes the Agile Project Management (APM) framework, discussing its values and presenting the phases (Envision, Speculate, Explore, Adapt, and Close). The core values of the APM are:
* Delivering Value over Meeting Constraints
* Leading the Team over Managing Tasks
* Adapting to Change over Conforming to Plans.
All these aspects are covered with both a high level vision (after all values are values), but also by describing daily project activities: Key points that will help you understand the author message are put in evidence. Example: A coaching leader’s attitude is reflected in the question “How can I help you deliver results?” The micromanager’s attitude is reflected in the question, “Why isn’t task 412 done yet?”
The final parts of the book deal with topics related to Agile project management: scaling, project portfolio management, measuring performance and fostering innovation. “Agile Project Management” by Jim Highsmith is definitely a book that I will recommend to every people involved in project management, agile or not. I always think that learning Agile practices should be preceded by understanding Agile values. This book provides insightful material for both values and practices.
Related websites: Jim Highsmith Website
Reference: “Agile Project Management”, Second Edition, Jim Highsmith, Addison-Wesley, 392 pages
Quotes
When Ward asked Toyota’s American engineering and managers how much time they spend adding value (i.e., actually doing engineering work), their response averages 80%. The same question asked of engineers and managers at American automobile companies averages 20%. How can you compete with companies that are getting four times as much value-adding work from their development engineers. (referenced from “Product Development for the Lean Enterprise”, Michael Kennedy, the Oaklea Press, 2003)
As a software development consultant, I’ve never encountered a successful software company (although my sample size is limited) in which the team and project leaders were not technically savvy. […] Championing technical excellence requires that the project leader, and team members in general, understand what technical excellence means – in the product, the technology, and in the skills of the people doing the work.
Agile leaders lead teams, non-agile ones manage tasks. How many project managers spend hours detailing tasks into Microsoft Project and then spend more hours ticking off task completions? Unfortunately, many project managers like this task oriented-approach because it is concrete, definable, and completion seems finite. Leading teams, on the other hand, seems fuzzy, messy, un-definable, and never complete. So naturally some people gravitate to the easier – managing tasks.
Self-organizing teams are at the core of the agile management, but the concepts have become corrupted – and counterproductive – in parts of the agile community. Although self-organizing is a good term, it has, unfortunately, contingent within the agile community who encourage an anarchistic management style and have latched onto the term self-organizing because it sounds better than anarchy. As larger and larger organizations are implementing agile methods and practices, the core of what it means to be agile – an empowering organizational culture – may be lost because large organizations will reject the cultural piece of agile.
When we “plan”, we expect the actual project result to conform to that plan, and then deviations become team mistakes or sign of the team’s failure to work enough. When we “speculate”, we take the opposite perspective – it’s the plan we suspect was wrong. The plan, or speculation, is a piece of information, but it is only one piece that we will examine to determine our course of action in the next iteration.
Software is the most malleable product. Companies need to use this characteristics to their competitive advantage, and sticking to traditional waterfall development negates this advantage.