Jim Highsmith introduced the Agile Triangle, creating a new triangle to reflect Agile development practices, moving beyond the traditional Project Management Triangle (a.k.a. the “Iron Triangle”):
Agile Project Management: Creating Innovative Products (2nd Edition)
I don’t disagree with the concepts that Jim Highsmith puts forth with his Agile Triangle at all. He’s advocating that Agile projects should be measured against delivering value to customers, doing so with quality, using constraints as important project parameters, but not the goal.
However, the inclusion of the Project Management Triangle as a dimension of the Agile Triangle bothered me from the outset. My main concern is that there are distinct differences between how traditional project management and Agile projects are approached.
The constraints of the traditional Project Management Triangle are important because traditional project management is geared towards achieving predictability in one of these dimensions. And when one dimension changes, and another dimension is affected; the constraints are interrelated.
And while the Project Management Triangle models the key constraints associated with predictability, it does not attempt to describe everything that goes into making a project successful. Entire books have been written about what goes into achieving success in a software project, and the Project Management Triangle is always a part of that equation. The point is that it is that the Project Management Triangle is by no means the entire picture.
As I thought more about it, I began to struggle with the Value and Quality dimensions of the Agile Triangle as well. Yes, Agile methodologies focus on delivering value and quality, but any project wants these, regardless of the methodology used. I ultimately ruled out Value and Quality as proper dimensions of an Agile Triangle.
Since being a critic is easy, I felt that if I disagreed with the Agile Triangle, I should put some thought into what I feel is an appropriate Agile Triangle. For me, it came down to a question of focus and emphasis.
Agile development is all about expecting, embracing, and responding to change. Agile is about people over process, and placing trust in those people to produce results. Agile also recognizes that software development is learning.
I therefore focused my Alternative Agile Triangle as a model of adaptability and productivity achieved through people:
Agile development embraces continuous learning, such as learning about the true business needs through frequent dialog, inspection and adaptation of delivered software. Retrospectives are another way learning takes place: the team reviews what works well and what can be improved.
Empowerment is the trust and granting of authority so that the team can act independently. One benefit is that the team will embrace change because they are closely involved with the change – either through the business discussing the need for change with the team or the team initiating change themselves as part of a retrospective, where they collectively determine what change is needed so that they can improve.
Another benefit of empowerment is the speed at which problems can be solved. As a manager, I can’t be everywhere and solve every problem. By trusting people to put their brains together to solve a problem, a situation won’t linger until I can get around to it – it can be resolved immediately by those who have the knowledge and experience to make the call. There will still be exceptions, naturally, but the goal is to place the trust and authority for making calls about their work in those who know the most about the work.
Competency concentrates on the knowledge and skills of the people, another important dimension to Agile development. This favors “individuals and interactions over processes and tools”, to quote from the Agile Manifesto. Both individuals and teams must be competent in order to embrace change and improve the productivity of the team.
Because of the highly collaborative, self-directed nature of Agile teams, people must have both technical and interpersonal skills. Ultimately, teams must function as more than a collection of individuals working on project tasks; effective collaboration is a sharing of knowledge, skills, and the willingness and ability to hold each other accountable.
Each Dimension Affects the Other. Learning affects competency. The more you learn from both project work and professional development outside of project work, the more competent you become.
Competency is affected when a manager fails to truly empower the team or fails to guide a team towards an empowered state. People certainly won’t strive to learn as much in environments where someone else is calling the shots and controlling every aspect of the job.
Competency can affect empowerment. If individuals and teams aren't fully prepared to operate independently due to deficiencies in their technical expertise or ability to self-organize, they will require more direction and coaching versus operating in a hands-off, fully-empowered mode.
Ultimately, highly competent teams learn faster and can embrace and respond to more change than less capable teams – and they will likely want to introduce change at a faster rate in order to continually improve.
I’m sure that you can think of other scenarios. The key is, I feel that the dimensions of the Alternative Agile Triangle are both interrelated and reflect the spirit of Agile development.
What about the Project Management Triangle?
The traditional Project Management Triangle can stand on its own. It's useful for non-Agile projects, and it is certainly a great tool to use when considering and explaining trade-off decisions, like why everything can't be a priority, even with Agile projects.
In the end, Agile development approaches projects differently, and that is what should be emphasized.
The Alternative Agile Triangle is about the people and their ability to embrace and respond to change whereas the Project Management Triangle is about planning, constraints, and predictability; accommodating change through altering one of its constraints.
Measurements in Agile should be focused on the people and teams, the knowledge, skills, and abilities of people and things that they need to do in order to produce results. As Jim Highsmith stated, “… it’s much better to have fuzzy measures of really important things that precise measures of less important things.” I’ll cover more on measurements in a future post.
I’ve outlined my opinion about the Agile Triangle and presented an alternative. After reading this, what is your opinion?
When is it OK NOT to Develop? Hint: Never.
10 hours ago