As Agile becomes better known, many troubled teams are deciding to adopt Agile practices to help fix their problems. Most clients seeking our help in Agile adoption want to start by pursuing process and tools. The more dysfunctional their teams, the less tolerance they have for focusing on individuals and their interactions.
We have found that the most effective teams—those that show a tremendous improvement in productivity and value to their organizations—have individual team members who take ownership, act responsibly, and are disciplined in recognizing and responding to change at a personal level.
These individuals adopt Agile practices because they have made a conscious decision to do so. They do what it takes to make things work.
Why Adopt Agile Practices?
Why do teams adopt Agile software development practices? The answer varies depending on the situation. They may have adopted Agile methods to reduce bug count, improve time to market, or reduce the overall cost of development. Or, maybe there was a vague lsquo;something is seriously wrong' feeling in the way they were producing software and they or someone in their organization read about this new-fangled technique called Agile that is supposed to help. Or, increasingly as Agile becomes mainstream, someone in management thinks it is a good idea and has mandated that the department or organization will adopt Agile. Management was trying to help and not hinder software development in some way. All these reasons have a common thread of wanting to make software development better and ultimately deliver more value to the organization.
What is a Successful Adoption?
We adopt Agile development practices to build better software and deliver more value to the organization. Is this adoption always successful? {sidebar id=1} Well, that would depend on the definition of lsquo;successful', wouldn't it? If successful means lsquo;we are practicing one or more Agile development practices,' chances are, most adoptions are successful. But that is not a very satisfying (or useful definition). We really should go back to the original goals that we used to justify adopting a new software methodology. That is, have we decreased our defect rate? Have we reduced our time to market? Have we become more productive? Are we more productive at creating better software that is providing increased value to our organization? THAT should be the measure of successful Agile adoption and that will be the definition of success we use here.
Problem: Many Unsuccessful Agile Adoptions
Unfortunately, fewer and fewer Agile adoption efforts are successful by our definition. In the early days of the Agile development community, frequent reports of 2x, 3x, 5x, and more in productivity gains were reported. These teams made progress in leaps and bounds and delivered software that truly helped their organizations move forward. Why aren't all teams seeing this improvement?
Cause: It Depends
So why aren't many seeing productivity improvements upon adopting Agile practices? Why are they unsuccessful - is there some secret? Is there yet another practice that only the successful know? Well, unfortunately, the answer is no. The causes are as varied as the teams themselves. There is no one solution to our problems. But there is a commonality that we find in all successful teams; their members take ownership for tasks and do what needs to be done to make them work.
The Responsibility Process Model
Now we'll switch gears for a bit and come back later to tie the different ideas together.
Figure 1 represents a model that we find invaluable in helping individuals become agile rather than simply going through the motions of acting agile.[i] It explains the mental process we, as human beings, go through when we avoid responsibility and destroy the ownership behavior essential to self-organizing teams.
Figure 1: The Responsibility Process
Imagine you're leaving home for a critical meeting. You're not late yet but you have no time to lose. You grab your laptop bag, reach for your keys, and... they aren't there! What's the first thing that crosses your mind? Who moved my keys? Or, honey - did you take my keys? Regardless of the exact words, most of us instinctively look for someone else to blame when something goes wrong. This behavior is a strategy we use unconsciously to avoid taking responsibility for our situation. (In the diagram, you are on the bottom behavior - laying blame.)
Now, imagine you arrived at the meeting. You're five minutes late. As you walk in the door, what do you say? quot;Sorry I'm late, I lost my keys?quot; Or perhaps, quot;Sorry I'm late, traffic was bad?quot; Why not stop at quot;Sorry I'm late?quot; Why continue with an explanation? According to Avery's research, the next instinctive response we have once we escape blame, is to justify. It's not my problem - the universe is at fault.
When we get past blame and justification, the next natural response is shame. When coming from blame or justification we externalized the problem - we believed we had no responsibility for it. When we get to shame, we now acknowledge that we're part of the problem - but instead of taking constructive action, we beat ourselves up. Regardless of the words out of our mouth, we're flogging ourselves for blowing it again. This is not a resourceful state of mind; this is another detour keeping us from responsibility.
When we get past shame, we have one more way to avoid responsibility - obligation. An example: quot;Honey, I'm sorry I won't be home for dinner tonight. I have to join the boss for dinner with a client.quot; No you don't have to go to dinner with the boss - you choose to. You own your life. You make your choices. Obligation is rule following behavior - using explicit or implicit rules to relinquish your ownership of your life. This doesn't mean you should go home for dinner. It means you should be conscious of your choice.
Assuming we get past each of these potholes, we find ourselves at responsibility. This is a state of mind where we take ownership for our situation. If things aren't as we prefer, we take action to change them. This state is the starting point for personal agility.
I want to be more responsible, how can I do it?
So you've decided you want model responsible behavior - now what? There are three keys to adopt this process in your life. First you must have an intention to act from a position of responsibility. Avery and McCarley's research suggests that our NATURAL response is not responsibility; the intention alone isn't enough. You have to learn new behaviors/responses. Therefore, the second step is to become aware when you are coming from any of the non-responsible states. For example, if you hear yourself saying quot;I have to....quot; then you are probably in the obligation state. Third, when you find yourself in one of the non-responsible situations, you must confront yourself with this issue. It is as simple and as difficult as this.[ii]
My teammates are stuck in blame, what shall I do?
One interesting aspect of the Responsibility Process Model is that it can only be self-applied - period. If your teammate (or worse your spouse) is stuck in blame, they do have a problem. However, if you point it out to them they now, they have two problems - and YOU are the immediate of those problems.
If you want others around you to be responsible, there are two things you can do: 1) you must model responsible behavior, and 2) you can share the model with them but not in moments of conflict. The rest is really out of your control;. change comes from within.
Potent Agile
Now let us come back to Agile development. How does the Responsibility Process Model fit in with Agile development? Specifically, can it help our Agile adoptions be successful? If so, how?
Successful Teams Have Responsible Members
One of the principles in the agile manifesto is that:
The best architectures, requirements, and designs emerge from self-organizing teams.
Consider teams you've worked with, from dismal to hyper-productive. Would you agree that massively-productive teams have members that embody responsible behavior, that take ownership and drive to the goal. Would you agree that mediocre teams consistently display one or more of the responsibility killers listed above? (This, by the way, is completely independent of Agile practices and methods.)
Recognizing and Responding to Change Requires Responsibility
Another of the principles in the agile manifesto is that:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Consider teams you've worked on that successfully adopted one or more development practices. Did those practices just fall in place or were they tuned for your particular environment? Who tuned them? Was the tuning lsquo;mandated' or was it taken up by one or more individuals of the team? If you decided to write tests first as a team, didn't that require discipline from each and every team member to do so effectively?
Recognizing changes as they happen is at the core of successful Agile development. Responding to change is often difficult and painful. Successful changes require the individuals on the team to step up, propose solutions, act on those solutions, and frequently admit that those solutions were not effective and need to be changed. Teams who are successful at tuning and adjusting behavior do so at individual level. Team members are responsible. They take ownership and act accordingly.
Successful Agile Development Begins with the Individual
Self-directed teams aligned to a clear goal are the essence of agile behavior and the engine behind the stunning results some teams claim for Agile. We believe that individual responsibility, as defined by Avery, is a prerequisite to such agile interactions. That is, responsibility, as defined by the Responsibility Process Model, is necessary (but not sufficient) for successful Agile software development.
Personal Agility
The Responsibility Process Model is one tool that we've found useful in helping teams achieve success - but it is only one of many. It doesn't have much to do with software development. It is a life skill that can be used virtually anywhere. It is not our model, nor are any of the other tools in the personal agility toolset - they come predominantly from the psychology, business, and management worlds. The works of Peter Senge, Franklin Covey, and others help one attain personal skills that make them more effective. None of them are useful until you take 100% responsibility for yourself.
These tools all focus on the individual. Which, if we go back to the Agile Manifesto's very first line, is the very core of Agile development:
Individuals and Interactions over Process and Tools
The values and principles in the Agile Manifesto were not lsquo;made up;' they were reverse-engineered from several years of successful development using lightweight practices and methods to deliver working software that met the users' needs. The Agile Manifesto can be seen as a set of observations and principles that have been found to be a common thread in writing successful software.
Personal Agility brings back the focus on individuals. Individual responsibility is the bedrock of Personal Agility. Without team members being responsible, there is little chance for Agile development practices (or any practices) to have a significant positive effect upon a teams effectiveness.
Observe teams at your organization. Which ones are most successful? Do their team members act from responsibility? We expect you will be able to validate what we have presented here with your own teams.
About the authors
Amr Elssamadisy is a Principal Consultant with Valtech, where he helps clients build better software using the latest technologies and, of course, adopting and adapting Agile practices. As a software practitioner, he plays multiple roles on different teams including coach, instructor, developer, architect, tech-lead, Scrum master, and project manager. He is also author of Patterns of Agile Practice Adoption: The Technical Cluster which guides the reader in crafting and implementing an Agile adoption strategy.
Ashley Johnson is VP of Business Planning and Strategy for Valtech Skill Development, an organization focused on guiding clients to successfully adopt modern development processes and technologies. In this role, his time is split between refining new service offerings and consulting with senior IT management to facilitate organizational optimization. Ashley is passionate about applying lean and agile techniques, and using simple metrics to improve visibility and eliminate waste. He has taught, coached, and consulted with thousands of individuals and is an acclaimed presenter. Ashley began developing hardware and embedded software in the early 1980's when he couldn't understand why people would pay him to have so much fun. Under pressure to get a life, he learned to enjoy backpacking, skiing, scuba diving, and radio control soaring. These hobbies are now eclipsed by his wonderful children.
[i] See the research of Christopher Avery and Bill McCarley. According to them, this instinctive response crosses age, gender, and race.
[ii] To read more about the Responsibility Process Model and its effect on teams, we refer you to Teamwork is an Individual Skill by Christopher Avery.
