The link in Scott’s tweet takes you to this chart.

I’m honored to be in the company of Chet Hendrikson, Ron Jeffries, Jeff Patton, Ashley Johnson (my scheduled co-presenter who gave this session last year), Jonathan Rasmusson, and Mary Poppendieck — agile rock stars.

To put this in perspective, 16oo people attended a reported 300 sessions over 4 days. That puts our session in the top 1%. What’s that mean? An ownership mindset and culture is on lots of people’s minds.

Download a PDF of this presentation.

This workshop was part of a Managed Leadership Gift Adoption program to develop an culture of responsible leadership so agile and lean methods will flourish in the enterprise.

I firmly believe that the software development movement — and now business movement — known as “agile” is a mindset and culture, not a set of tools and processes (see this related post). Agile coach Michael Sahota is writing a set of articles about agile and culture that are worth a look.

I summarized my thoughts in a comment on his blog post Agile Fits Better in Some Company Cultures Than Others.” In part, I said:

I love that agile thinking, lean thinking, Scrum, Kanban, WIP, TOC, complexity theory, all challenge people at work to think — some a little and others a lot — about what they are doing at work. I do believe the agile movement is causing a sizable shift world-wide at the level of individual discipline. I think it is beyond critical mass and irreversible. I tell my clients that if they – like me – came of age in a world of linear thinking (i.e., waterfall-like planning and execution), and they don’t embrace agile, it is very likely that someone who today is 30 years-old and has been practicing agile thinking for 8 or 10 years will soon be taking their job and running their department and company.

What do you think? Comment.

Everyone says they want to be on a winning team. And nobody ever says they want to be on a lousy team. So how come we end up on frustrating teams much of the time?

Here are the steps you can take to make sure that being on your teams remain the worst, most frustrating experiences ever. Master each of these four steps and then be sure to pass them to others so they, too, can bring all their teams down.

These steps are especially important if you want to bring agile practices to a standstill…

Step 1: Assume someone else is responsible for team building

Never, under any circumstance, should you allow yourself to feel a sense of ownership for the quality and productivity of the whole team, collaboration, partnership, or relationship. By all means, let someone else do that, preferably someone you can despise for not having as much technical competence as you. Also, assume team building is black magic instead of a skill set composed of straight-forward, repeatable conversations anyone can bring to any relationship any time.

Why? Someone — anyone, regardless of their role in the team — who cares about the productivity of the team will make a huge difference in putting into motion the conversations and ideas that build the team. But when no one does, then it’s completely up to chance whether the team develops effective dynamics.

Consider this: 15 years ago I had the opportunity to interview dozens of science and engineering staff in a couple of large, failed programs. Everyone was a “top 10 percent” graduate from a “top 10” university, the crème de’ le’ crème. When asked, “To what do you owe your participation in this failed program?” the No. 1 response was: “I got put on a bad team.”

Memorize that line so you can repeat it in your next review.

Step 2: Resist attending to anything other than the most narrow description of your role

Whatever you do, refuse all invitations to meetings, orientations, or informal gatherings where the team’s overall mission might be discussed. If you do, you might get sucked into caring. And if you actually cared, then you might feel a sense of ownership, and next thing you know you’ll be sub-optimizing for your own role and optimizing for the whole.

Why? The No. 1 point of leverage for team building and team leadership is to talk together about the larger goal. I call it the what-we-must-do-together-that-is-bigger-than-any-of-us,-requires-all-of-us,-and-none-of-us-can-claim-individual-victory-until-it-is-achieved conversation.

Step 3: Don’t care whether others on the team and extended teams are winning or losing

By all means, whatever you do, maintain a constant vigil of nonchalance about how what you do affects others on the team or beyond. This is relatively easy to master. Besides repeating the mantra “I don’t care” you can also:

1. Assume the only way to motivate anyone is with the carrots and sticks of management, which peers on teams don’t have available, thus you can’t affect other’s commitment.
2. Never, ever ask “What’s in it for you — beyond a paycheck — to work on this project?” That way, you can continue to not care, and you also don’t have to know whether you are stepping on someone’s win.
3. Never own up to having any inspiration at all about why you come to work other than for continued employment and a paycheck. That way you can maintain low interest and commitment to most things.
4. Finally, assume that other people and departments should do what you think they should do because you all get a paycheck from the same company.

Why? Most people say they want to be on a winning team. That means actually practicing win/win/win at every level and juncture, which requires some caring, knowledge, and effort. And that means understanding how peer motivation works and committing to generate as many wins as possible out of every decision and action.

Step 4: Make only agreements you must in order to get others to leave you alone, and don’t worry about keeping them.

Since there is a fuzzy authority system in teams, collaborations, and partnerships, feel free to say and do anything you can to get people to leave you alone. That usually means resisting opting in and engaging until they twist your arm and then saying whatever you must in order to end the pain and move on. Making agreements you never intend to keep is a great way to ensure continual frustration and failure.

Why? Teams, collaborations, and partnerships operate on a different frequency than the hierarchical functions of an organization. Where authority structures create the fabric of the institution, making and keeping agreements of all types, from operating rules to delivering work, creates the fabric of the team.

Practice, practice, practice

Repeat these four steps over and over. I promise you will be a whiz at bringing down any team without even trying.

What steps did I miss?

Did I mention or miss a personal favorite of yours? Let me know.

Christopher Avery, Ph.D. wrote the popular book Teamwork Is An Individual Skill: Getting Your Work Done When Sharing Responsibility — which Fortune Magazine claimed is the only teamwork book worth reading. He is a recognized authority on how individual and shared responsibility works in the mind and an advisor to leaders worldwide. Master leadership or build a responsible team (or family) with The Leadership Gift Program for Leaders.

• Start shining the spotlight on the whole, not the pieces
• Solicit help shining the light
• Know the standard you are striving to achieve

Building on that theme, I’ll tell you why the project team is the easiest team to build compared to the management team: The laboratory definition of a team is “a small group of people working together toward a common goal” — laboratory being the operative word here because most of the definitive research conducted on team dynamics occurred in lab experiments.

Researchers would give randomly formed groups various tasks to accomplish together and then observe their dynamics. The famous four-phase model (forming, storming, norming, and performing) by Bruce Tuckman [1] followed from such experiments.

Of all the groups you hope would develop effective team dynamics, the project team is most like the groups in that original research. Think about some key similarities:

1. A collective focal point for the group that requires their collective effort,
2. A clear beginning, and,
3. A clear ending.

These three similarities create what I sometimes call a “container” (or even a “vessel” as in “get the individuals feeling like they are in the same boat together”). This is an excellent recipe for successful engagement and effective dynamics to emerge. In a healthy organizational culture and with some good basic facilitative support or servant leadership, many project teams will develop fairly effective dynamics.

So why are management teams, staff groups, and departments so much more of a challenge to build?

Because they don’t fit the laboratory definition of a team. They seldom have:

1. A collective focal point for the group that requires their collective effort,
2. A clear beginning, and
3. A clear ending.

What’s a team-minded manager to do?

Do you want to know the most basic prescription for developing effective team dynamics in management teams, staff groups, and departments? Here it is: Develop a rhythm of serial (i.e., one after the other) collective focal points for the group that requires everyone’s collective effort to achieve. The focal points should be realistic, challenging and “winnable” for the group.

For example, you could set monthly (i.e., iterative) group results that cut across and require the collaboration of all members of the management team, staff group, or department. Then shine your biggest spotlight on that collective goal and shine your pen-light on the individual accountabilities. Hold monthly planning meetings to set and plan for these collective targets. Use weekly and daily meetings to adjust plans and focus on the collective targets. And “retrospect” (a term from agile software development for process improvement meetings — see the previous blog post) at the end of every iteration about how you could improve for the next iteration.

With a relatively healthy organizational culture and a little facilitative support and/or servant leadership, your management teams, staff groups, and departments will naturally develop effective team dynamics if they are challenged to work together — and high-performance results should accrue. That’s how you build successful, dynamic, collaborative leadership and happy team members.

Reference: 1. Tuckman, Bruce. (1965). Developmental sequence in small groups. Psychological bulletin, 63, 384-399.

Christopher Avery helps leaders worldwide to operate their business — and lives — far more productively and successfully. Find additional resources to master leadership and build responsible teams at ChristopherAvery.com and The Leadership Gift.

The basic process for an iteration retrospective is to gather the team for an hour (more or less as required by the length of the iteration), ask the team to generate two lists (what worked well and what the team would like to improve), then prioritize items in the list and commit to one or two small changes during the next iteration that, in the estimation of the team, will generate a large difference in product or process.

This process is simple and powerful. It follows an old, continuous improvement process for meetings called “plus/delta.” In the plus/delta process the group will reserve the last five minutes of any meeting to list pluses — or things that worked well — for that meeting (e.g. facilitation, staying focused) and deltas, or things the group would change to improve (e.g., too noisy, missing key people).

There are a number of obvious benefits to the retrospective (and the plus/delta), as well as some more subtle benefits that are powerful.

The Subtle Benefits Provide the Real Leverage

An obvious benefit to the retrospective is that it provides the team with a scheduled opportunity to reflect on the recent past and illuminate events, choices, procedures, and behaviors so each can be sustained or changed as the team desires. Successes and positives can be pointed out, checked for relevance, celebrated, or reinforced. Mistakes and disappointments can also be called out and assessed. Team members can agree to course corrections while individuals who may have committed a faux pas can be granted a second chance. In this way, the team and its members can claim ownership of how it executes its work, and it can exercise and reclaim that ownership during every iteration.

There is one situation that rises above all others in giving any team an opportunity to demonstrate team spirit — that place is team meetings.

Three related developmental benefits to the retrospective that are not so obvious:

1) Enactment: we create our reality by “acting as if.” The retrospective is designed for members to demonstrate that they are a team. The iteration retrospective is designed for

• high participation
• every voice to count
• individuals to combine and integrate their perspectives and interests and
• to reach a workable consensus about how to go forward together into the next iteration — to commit individually and as a group.

The key is participation. If a group doesn’t act like a team in team meetings — because of controlling leadership, disengaged members, horrendous meeting etiquette, or lack of opportunity to be heard — then it’s not likely to act like a team elsewhere. Encourage and make time for retrospectives and your team will be more likely to work well together. People who feel like their voice is being heard and that it matters are usually eager to do a great job and to support their team members to excel.

2) Reflexivity: the act of reflecting together for the sake of learning, correcting, and improving. Individuals who create time, space, and permission to reflect are able to grow and develop faster than individuals who don’t. The same is true with teams — in fact, some team experts consider reflexivity as one of the greatest predictors of team effectiveness. Any team that devotes face time to talking about how it is working together as a team is practicing reflexivity and will give itself a better chance to reach sustained high performance. Keep doing retrospectives well, and your team will be more likely to develop, grow, and be a learning team.

3) Closure: it’s difficult to start something new when something else remains mentally or emotionally unclosed. Win or lose, all teams (and all people) need closure. If a project or initiative abruptly ended without warning and you were expected to report to work the next day and “continue” with your work as usual, it probably felt awkward. That’s because you felt incomplete. So, while an iteration may be a short period of time, it’s still a whole cycle of intention and deserves to be completed. The retrospective is an excellent place for people to say what needs to be said — win, lose, or draw — so they can let it go and move on to the next iteration.

Claim All The Value Retrospectives Offer

Retrospective meetings are extremely valuable, not just for the obvious reasons of looking back with an eye for improving operations in the future but also for the contribution they make in developing the cherished qualities of team spirit. You won’t be sorry to invest time in retrospective meetings — they create trust, goodwill and cooperation, and respect for individuals — three key predictors of high performance.

Want a Good Resource?

I recommend Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larson to my clients for a useful and practical book of tools for keeping retrospectives fresh and engaging.

Christopher Avery, PhD, supports agile leadership and business practices with the only how-to approach for taking and teaching personal responsibility. He is an advisor to leaders worldwide. Find additional resources for mastering agility and leadership or building a responsible team at The Leadership Gift.

Shared Responsibility

Early in my speech I asked how many in the room are in a position of “shared responsibility” in their workplace. I asked: “Are you in a position where you are  not in charge of them and they are not in charge of you but your own performance depends on what you do together?” Every hand went up. This is a challenging situation for most as the setup leaves us vulnerable because we can not guarantee that our teammates are doing a great job. If they don’t, their bad performance reflects on us.

As an organizational scientist I have spent the last 30 years researching the phenomena of people having a hard time taking personal responsibility. When things go wrong, we immediately find excuses and blame others for the poor performance. Why is that? In my speech I went into detail about what actually happens in those situations.

It is fascinating what goes on in our brain and how we are hard-wired to respond in a predictable fashion. There is a natural mental process that plays out dozens, maybe hundreds, of times every day that protects our egos from our own painful mistakes. More importantly, it keeps us from solving problems, adding value, and making forward progress.

The mental process is simply this: each time something goes wrong, we do our best to avoid owning it.

We all do it, no matter how responsible we attempt to be. It matters not whether the problem is big or small — the mental process is the same. The existence or lack of personal responsibility is not so much a character trait (or flaw) as it is a well-developed and practiced mental process. People who are well practiced in avoiding ownership for their actions are usually quite effective at it. The level of a person’s intelligence or other professional skills make little difference. In fact, the smarter someone is, the more creative that person will be to avoid ownership. Have you ever noticed that the most intelligent people tell the most elaborate stories?

“Who took my keys?”

Here’s an example to see this response in action. What’s the very first thing you think and maybe even say when your car keys are not where they are supposed to be? I’ll bet you it is: “Who took my car keys?! ” That’s not just a figure of speech. That’s the communication of a thought rooted in an assumption of cause and effect.

I call this Laying Blame, and it is the first of six ways we avoid owning it when something goes wrong. The other five ways are: Obligation, Shame, Justify, Lay Blame, and Quit. These are the positions of irresponsibility you’ll find illustrated on my Responsibility Process poster. You can download it for free at ChristopherAvery.com.

Why does our mind work like that? I’ll get into why we justify our behavior when our competence is challenged in my next blog post in this series. In the following weeks I will explain the whole Responsibility Process and point out why it is so important that we master to overwrite these initial responses in our mind with taking responsibility — because if we don’t change our behavior we will always be dependent on other people changing, and that is unlikely to happen.

You can see the whole video of the Agile Day NYC keynote speech here.

Christopher Avery, PhD, is a recognized authority on how individual and shared responsibility works in the mind and an advisor to leaders worldwide. Learn more about mastering leadership or build a responsible team (or family) at The Leadership Gift. Enjoy a more productive way to live and lead.

I’m familiar with both of these issues. Let me set up the video for you, then watch it below…

What if we’re solving the wrong problems?

Participants in the Leadership Gift program for leaders discover how most of our life we have been trying to deal with our anxiety about a problem rather than identify and address the real problem. As a painful example, if we work in a company culture of blame or rely on laying blame as a coping mechanism, and we participate in a root cause analysis, then we are likely to conclude our assessment with who was the problem.

Blaming a scapegoat temporarily relieves our anxiety, but it doesn’t find and address the real problem. The root cause remains to be found whether it is the system, process, design, information, training, or something else — like the company culture maybe.

This is a little deep, but consider it: Most of our coping strategies for dealing with problems simply address our anxiety about the problem rather than the real problem. However, when we identify and address the real problem, then we always learn and grow, becoming ever more free and powerful. I know which I prefer.

You have complete freedom of choice about how you define a problem.

Could the simplest solution really be the best?

From the agile approach to software development and project management I’ve learned that the simplest solution is often the best solution. This principle is an elegant response to a number of issues, including scope creep and over-engineering. It doesn’t actually mean to always go for the quickest fix — no not at all.

Here’s what it does mean: Examine and re-examine the goal (value) you are trying to achieve as you examine and re-examine the work (cost) you are proposing for fulfilling the goal. This is best done in dialog with others. Success is realizing the greatest value for the least cost.

My takeaway from this principle has led me to be a better buyer and a better supplier. How? Because whichever side of the conversation I am on (goal and value, or work and cost), I do my best to have an open and transparent conversation about the real value sought and the best (simplest, most direct) way to deliver that value.

Whichever side of the conversation you are on, you win by participating.

Simply solve the real problem, watch…

For Rory’s bottom right quadrant, I propose “agile” or the “Leadership Gift.” What do you think?

Give the video below time to load. It’s worth it. This short talk ranked 8th out of 150 presentations at the XP2010 international conference earlier this month in Trondheim, Norway.

Turn up your volume, you’ll like it…

Enjoy Sergey Dmetriev’s 7 minute rendition of the Responsibility Process and how to master it

A Russian born agile evangelist living and working in Oslo, Norway, Sergey even gives you an application game.

Follow Sergey on Twitter.

Interested in learning more? Register for a free Leadership Gift preview webinar.

Sergey did a great job didn’t he? Comment on your favorite part or slide…

With the advent of lean thinking and agile methods, the old command-and-control structures are giving way to self-directed teams. Uncovering what makes these teams function effectively and what enhances or inhibits  collaboration are questions of growing importance.

Teamwork does not depend on group-bonding or a facilitator’s magic art. Teamwork is actually based on individual skills and attitudes that each team member can learn and master. Great teams are built around a series of conversations that help to define each individual’s role, agreements, and commitments to the team.

Becoming skilled at doing more with others may be the single most important thing you can do to increase your value.

How Does This Apply To Agile Methods?

Agile methods promote self-organizing  teams that require  personal—and team—responsibility. Methods like Scrum and XP advocate and depend on high-degrees of collaboration, yet these high-touch, low-tech methods give us very little guidance on the fundamentals of collaboration. The art and science of  effective teamwork is a set of skills that can and should be developed. Knowledge Team Leadership teaches you these fundamental skills.

Read more about how to develop your Knowledge Team Leadership skills for personal, team, and organizational agility.