An Alternative Agile Triangle, Revised

March 31, 2010

I recently blogged about my Alternative Agile Triangle, seeking a triangle that reflects Agile development, attempting to move beyond the traditional Project Management Triangle. The reason that it is called an Alternative Agile Triangle is that Jim Highsmith has already put forth an Agile Triangle – one that serves a different purpose than what I’m shooting for.

However, I ran into a problem with my Alternative Agile Triangle, courtesy of Jim Highsmith. Jim made an astute observation about the use of the word empowerment, and how he’s now using autonomy in favor of empowerment. It was one of those “slap yourself in the forehead moments” for me. Jim is right. And I had included Empowerment as one of the dimensions of my Alternative Agile Triangle.

Therefore, this is:

Revision #2 of the Alternative Agile Triangle.

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.

The Alternative Agile Triangle is 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.

Autonomy is about individuals and teams operating independently, making informed decisions without the need for constant managerial direction. Wikipedia defines autonomy as “self” + “law” – and as teams operate by initiating change and improvements on their own, a benefit will be that the team will embrace change because they are closely involved with the change. This will be in the form of the business discussing the need for change with the team or the team initiating change themselves as part of a retrospective, where they collectively determined what change is needed so that they can improve.

Another benefit of autonomy is the speed at which problems can be solved. As a manager, I can’t be everywhere and solve every problem. By enabling and expecting teams 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.

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 possess 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 independent, autonomous 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 autonomy. 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-autonomous 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.


Anonymous said...

Hi Dave,

This is an interesting approach to Agile that I’d love to share with our members. Likewise, we are working on an open source Agile Information Development solution and would love your take on it when you have some time.

April 6, 2010 at 6:57 PM
Dave Moran said...

Feel free to share this with your members. All that I ask is to quote your source! I'll take a look at your solution -- it appears that you have quite a bit of information available.

April 6, 2010 at 9:07 PM
Anonymous said...

Great! I'll bookmark your site for them.

April 7, 2010 at 11:29 AM

Post a Comment