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:


Learning
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
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
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.

Working Smarter Means Measuring Smarter

March 26, 2010

Last year I posted a blog entry titled Essential Metrics. If you read the post, you’ll discover that I was not advocating measuring the outputs of software project work as much as I advocating measuring what goes into producing results. Software Development = Knowledge Work, and we need to measure those things that matter to knowledge work, some of which is generic to all knowledge workers and some is specific to software development.

The difference-makers in knowledge work like software development are the people. It is their knowledge, their skills , and the technical and teamwork practices produce the results. Unlike a manufacturing plant producing standardized, pre-defined widgets, the outputs of knowledge work like software development are variable; attempting to measure outputs is an exercise in futility.

Some of the more traditional software metrics like measuring lines of code, function points, and defect rates don’t work for me. If you want lines of code, you’ll get more lines of code! But will this tell you that you’re more productive than ever before? And what about a case where someone refactors code that actually reduces the lines of code, making it more readable and maintainable?

When it comes to software metrics, there are simply too many variables involved to make good comparisons across different projects in one company, let alone making comparisons across a world full of software developers and projects. I also prefer direct, lightweight approaches that don’t detract from the most important activity of producing working software.

We’ve adopted Agile/Scrum development, using the delivery of working software as the primary measure of progress. How do we know that we're improving? We certainly didn't change our development process because we felt like it; we want to improve.

The term used to describe how fast a Scrum team produces software is known as velocity, and this can be used as a realistic measure of a team’s improvement.

Since Agile/Scrum teams are supposed to be delivering with quality at all times, and if each user story is accepted as complete and “done,” then the size of the story counts towards the total velocity of the team. If a team improves its practices, the velocity should increase – providing a simple and direct measure of improvement.

The caveat is that velocity is only applicable to a given team. User story sizes are relative to each other, making them comparable to other stories that the team is working on. This makes the resulting velocity figure for each team unique to that team.

I’m good with this, because other factors come into play when measuring productivity. The nature of the work can vary from project to project, as can the size and composition of the team itself. Changing the composition of a team will change its velocity. The conclusion is that one of the real measures must involve the practices used to produce results. The better that teams are with their practices, the better their results – the outcomes – will be.

We need to make sure that we’re building the right thing.

We need to make sure that we’re doing things right.

Building the right thing is all about providing a solid return on investment – business value. This requires a product backlog that is prioritized by business value. And before a team commits to a collection of user stories, they should make sure that they have a clear understanding of those user stories. A second part of this is to ensure that customers (or proxies) are available to the project team to answer questions that arise about business functionality as the project progresses.

Everything else falls into the category of making sure that we are doing things right. Use of technical practices such as Test-Driven Development and Pair Programming ensure that common development mistakes are avoided. A practice like Root-Cause Analysis will inform teams where process breakdowns are occurring. Scrum practices like Backlog Grooming, Sprint Planning and Daily Stand-Ups help teams understand and monitor their work.

At the individual level, employees who are knowledgeable about their profession, who are technically proficient and embrace continuous learning and improvement, who can communicate and collaborate well, and who are willing to hold themselves and others accountable are equally essential.

Measure what matters, and with knowledge work like software development, measure – assess might be a better word – those skills, abilities, and practices that go into producing results.

(Photo by aussiegall)

Book Review: Great Business Teams

March 19, 2010

Great Business Teams: Cracking the Code for Standout Performance
Great Business Teams: Cracking the Code for Standout Performance by Howard M. Guttman

As a manger, are you interested in raising the performance bar for your teams? As a team member, are you interested in how you and your team can become a high-performing team? If so, I highly recommend this book!

The “code,” as viewed from 50,000 feet doesn’t appear very different from many other books or blogs that are out there. You need to be a different leader, discarding the hierarchal organization and implementing a flat, horizontal organization that embraces collaboration. What makes this book different is the level of detail that it goes into. The book is a treasure trove of information about what it takes to be a leader and a team member on a high-performing team.

What I liked about the book is the two-fold approach of providing very good, specific information and supporting case studies. Guttman has real-world experience and examples that he brings to the table, and he very effectively weaves in stories and practical advice on what it takes to get to a high-performing state.

Just some of the advice and information contained in this book:
  • On great business teams, candor is king. If you have a point of view, you should be free to express it. If you have feedback, provide it – depersonalized.
  • For horizontal accountability to take hold, leader must role model the desired behaviors.
  • While members of a great business team share responsibility with the leader for dealing with underperforming peers, the leader plays a critical role. It must be an up-or-out approach. Those who cannot adapt and thrive should take their game elsewhere.
  • Mindset alone does not create high performing teams. Everyone needs the right skills to play and win. Today, most people’s experience is working vertically. Working horizontally feels unnatural.
As I’ve explored the role of agile leadership and reflected on my own experience, I’ve come to one conclusion: There is no one leadership style that fits every situation. You must adjust your leadership style based on the needs of your employees.

In the book, Howard Guttman indicates that leadership behavior involves analyzing two factors:

ENAGAGEMENT: An individual’s commitment to being a team player, his or her willingness to take ownership of and be held accountable for the team’s success; his or her intention to embrace the attributes of high-performing teams.

SKILLS: The knowledge and skills an individual brings to a goal or task; education, experience, and/or ability; the individual’s appropriate utilization of his or her technical leadership, interpersonal, and strategic skills in the context of meeting performance goals.

The book offered some additional advice, and that is defining the leadership style to adopt based on the level of engagement and skill set.

Engagement and Skill Set Stage
Recommended Leader Behavior
Low level of engagement and/or skill set
Prescribe/Direct
Moderately low level of engagement and/or skill set
Coach/Instruct
Moderately high level of engagement and/or skill set
Collaborate/Partner
High level of engagement and/or skill set
Inspire/Empower

A quick description of the leader behaviors:

Prescribing/Directing: Telling players the what, where, when, and how of an issue.
Coaching/Instructing: De-emphasizing the how in favor of the why.
Coordinating/Partnering: Working alongside the player.
Inspiring/Empowering: Allowing team members to run with the ball.

Finally, for those of you who are interested in the Characteristics and Behaviors of High-Performing Team Members:
  • Be personally accountable and hold others accountable.
  • Be coachable: adapt, move, change, and lead others to change.
  • Be collaborative: open, above board, direct.
  • Be trusting: let go so others can lead.
  • Have integrity: keep your word.
  • Be committed: act as an owner, really engage/add value.
  • Follow up/act upon decisions.
  • Keep commitments.
  • Follow conflict-resolution protocols.
  • Be good listeners.
  • Be open/transparent.
  • Act as coaches/support each other. 
The book covered a lot more ground than I’ve discussed. It’s really a great book about building high-performing teams. If you haven’t read it, I highly recommend it.

Bruce Lee on Software Development

March 12, 2010

Before his untimely death in 1973, Bruce Lee managed to shake up the martial arts world with his theories of combat and training. Why? Because he felt – much to the chagrin of his peers – that the traditional martial arts were too rigid and formalistic to be practical when applied in an actual fight.

Lee referred to this rigidity in the martial arts as a “classical mess” that wasted time and energy. His real concern was that concentrating on a specific style as the only way of fighting prevented someone from becoming a truly capable fighter. This is because focusing solely on any one style of fighting restricts your options.

For example, a style like karate leads to specialization with punching and kicking techniques, but a karate man is unable to handle a wrestler if the wrestler succeeds in getting the karate man on the ground. Conversely, a wrestler is helpless against a karate man if the karate man is successful at keeping the wrestler at arm’s reach.

Bruce Lee was regarded by many as being years ahead of his time. And while computers were in their infancy by today's standards, much of what Lee advocated regarding the martial arts can be applied to software development. For instance, do we spend too much time and energy on our own stylistic “processes,” losing sight of what software development really is?

As an industry, we’ve certainly had our share of silver bullets. We’re not alone in this respect. The martial arts industry has its silver bullets, too. Pick up a martial arts magazine and peruse the ads. You will find someone advertising a “fighting method” that is guaranteed to make you a “killing machine” by using one simple move. No need for all of that hard training!

If you believe that, I’ve got some land to sell you… Or perhaps a “killer software development productivity technique,” hmmm…

Getting back to the subject at hand, it is interesting to examine how Bruce Lee resolved the stylistic issues involved with the martial arts. His journey resulted in the development a system that he called Jeet Kune Do.

Bruce Lee was clear on one point, stating: “I have not invented a ‘new style,’ composite, modified or otherwise that is set within distinct form as apart from ‘this’ method or ‘that’ method. On the contrary, I hope to free my followers from clinging to styles, patterns, or molds.” In short, Jeet Kune Do is not a style of fighting, it is a system.

Lee stressed that you didn’t want to assemble techniques from a variety of styles and slap them together to form a new style. The goal as a martial arts practitioner means that you should discover what works best for you, because what works for one person will not necessarily work for another person.

Lee was all about exploration and continual learning. Recognizing and respecting that everyone was different, he felt that practitioners should interpret and evaluate techniques for themselves, adapting the techniques is necessary to meet their own circumstances. The caveat was that those decisions should be based on realist combat, because those decisions should have a strong basis in reality.

Lee sought to understand the true nature of fighting; he sought to understand what each style had to offer, but in doing so he strove to avoid being trapped by the limits of any one style. His approach of “absorbing what is useful” and discarding anything that was merely ritualistic is great advice to this day.

Bruce Lee’s research and thinking was all about how to become a better fighter. He wanted to understand the knowledge, skills, and attributes that went into being a great fighter.

When it comes to software development, it’s all too easy to devote time and attention on the process – the style – of software development, and too little time focused what it takes to produce great software in the first place: good, capable people and teams using proven, professional practices.

Does process alone make a team a high-performing team? What advice would you have for someone who wants to become a better programmer? I would HOPE that it isn’t along the lines of, “Follow process XYZ and you will become a great programmer!”

In the end, follow Bruce Lee's advice: Examine what others have to offer, take what is useful, and adapt it if necessary. I'll close with an old quote: "The style doesn’t make the fighter, the fighter makes the style." Or should I say: The process doesn’t make the developer, the developer makes the process.

A few references about Jeet Kune Do and Bruce Lee:

http://en.wikipedia.org/wiki/Jeet_Kune_Do
http://www.worldjkd.com/
http://en.wikipedia.org/wiki/Bruce_Lee

An Alternative Agile Triangle

March 5, 2010

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”):

Figure from 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:


Learning
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
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
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?