AgileIQ Blog

When the bottleneck of an Agile team is the team itself

  

 Email Article  

Tweet  

  

by Jayaprakash Puttaswamy

Most often, we have observed that agile implementations fail in spite of putting efforts towards educating the team about Agile principles, training the team on Agile practices, and getting the right people for Agile roles. Have you ever wondered why? There are chances that the culprit is the team itself.  The team could be plagued with several dysfunctions (refer to  “the five the dysfunctions of team” model from Patrick Lencioni). If you discover this in your teams, how would you go about dealing with it? How can we overcome the dysfunctions and thus help the team implement agile successfully?

Well, there are ways to do it. There are instruments and techniques to do it. But all these would fail if you don’t have good leadership skills. I would like to share my experience with similar situations, with success stories, challenges and the lessons learnt. Here is a case study which I would describe in three sections:

1. SITUATION: Problem statement
2. APPROACH: Key skills used
3. SOLUTION: Results obtained, challenges faced, lessons learnt

SITUATION

The situation was exactly as outlined below. It was a nine-member team, suffering from dysfunctions (mentioned inside the pyramid). As a result, the team was exhibiting the dysfunctional characteristics (mentioned on right hand side of the pyramid).

Problem statement

• The team was slipping on deadlines, unable to fix critical issues and could not removeits  high dependency on two key technical people.
• There were also side effects:
  • Decrease in the morale of one of the key technical people
  • The other key person not being able to focus on continuous improvement

APPROACH

The team members were trying to follow Scrum as their way of implementing Agile, and there was a technical person who was struggling to play the ScrumMaster role. I had joined this team as a development manager. Irrespective of my role, I had to take charge of the situation to identify the bottleneck. The first thing I did was to take out the teams for a couple of lunch sessions (we decided not to wait for company sponsorship with the budget approval).

Those sessions, coupled with a team assessment instrument, helped us figure out as a team what the dysfunctions were that were affecting us. The rest was all about leadership skills (refer the inverted pyramid below).

Key skills used:

• Situational leadership
• Conflict management
• One-on-one feedback
• Time management

SOLUTION

As a responsible leader, I had to drive the team in a slow and steady manner on the following aspects:

• Making retrospective meetings effective
• Open evaluation of team dysfunctions
• Consensus on tackling “trust” and “conflicts” (which were affecting the team most)
• Enabling the team to share personal details (strengths and weaknesses)
• Effective sprint planning
• One-on-one discussions between me and other team members

Results obtained

After a period of 6 months of continuous experiments (I call them experiments since there was no single way to address “trust” and “conflict” issues), we achieved the following:

• Completion of tasks on-time, with better quality
• Significant reduction of technical dependency on individuals
• Improved “self-organizing” capability of the team
• Increased morale of the team, as well as the “key technical people”
• More critical issues were identified and fixed
• The other key technical person got opportunity to improve his “leadership” skills

Challenges faced

• Convincing the people on abstract concepts like “dysfunctions”
• Time management
• Dealing with different personality styles

Lessons learnt

• Most of the radical changes require “paradigm shifts”
• “Going first” or “being vulnerable” is the first step
• “Constant focus” is needed to bring real changes

Conclusion

Any successful Agile implementation requires a good leader who can drive the team by identifying dysfunctions, helping the team overcoming them, and facilitating the process of change management if needed. Any of the team members (especially management people) can do this and they should do ONLY this and nothing else. Rest, the team figures itself out. Ending with a quote from Henry Kissinger:

“The task of the leader is to get his people from where they are to where they have not been.”

Sharing Values, an Agile Team-Building Exercise

  

 Email Article  

Tweet  

  

by Dhaval Panchal

A few months ago, I was facilitating sprint retrospective for a multi-cultural team that had members of different national origins (UK, South Africa, Angola and United States). We started gathering information regarding their first sprint. I realized that this team was struggling to simply get along! We took a step back and created a focus for our retrospective. We elicited the following goal for our retrospective:

During the course of this retrospective, team members discussed how they can improve trust, respect & communication within the team. The fact that the team had individuals from different cultural background was not missed. The crowning moment during the retrospective came when one of the team members said:

“In my culture, we have to be friends, for me to do good work. In the western culture, I have to do good work, for us to be friends.”

These words have echoed in my head for a very long time. His insight has been a great learning experience for me. I have learned to acknowledge and appreciate differences in individual values. But what are these values?

Exercise: Sharing Values

Step I: Identify a pair (optional)

Ask your team members to identify someone within the team that they are comfortable with. Ensure all pairs have been identified and if there are odd numbers of people, the facilitator can pair with the lone individual. Ensure that every one has some index cards and a sharpie.

Step II: I don’t like it …

On a single index card, ask each team member to complete this statement:

“I don’t like it when someone/people …… “

Encourage each team member to write down 2-5 such statements on separate index cards.

I have found that it is easier for us to identify behaviors that we don’t like, especially when we have been at the receiving end.

Step III: Exchange Cards

After everyone is done writing, exchange all your cards with your partner.

Variation: If you have opted not to do Step I, then place all these cards in the basket/hat. Now randomly pick cards from the Basket/Hat. If you get a card that is yours, then place it back into the bucket/hat. Ensure all cards have been distributed.

Step IV: I like it …

On the back of each index card, write down a statement that will counter your partners “I don’t like it …” statement with

“I like it when someone/people….”

You will be amazed how your team member’s insight into your hot-button issue helps you recognize behavior that you will truly appreciate!

Step V: Share Values

Go around the table where each team member reads aloud a statement that begins with “I like it when …”. Take turns reading one statement per team member at a time until all statements are exhausted.

These are your team’s value statements. These statements provide a simple list of positive behaviors that are currently valued in your team.

Caution: As a facilitator/scrummaster refrain from vocalizing these statements yourself. I believe it is very important for everyone in the team to hear these positive behavioral statements from their peers.

Step VI: Team Values Chart

On a Big Visible Chart only capture statements, that begin with “I like it when …”. Radiate this information in your team area for the benefit of your team members and others who interact with your team.

This exercise takes less than 30 minutes to do. Try this exercise again after a couple of months; see how far your team’s values have evolved. As a manager/scrummaster/team member, if you feel tempted to dictate good behaviors to your team, take a deep breath and try this exercise with them. Maybe, just maybe, your team will self-organize to correct its own behavior.

P.S. Suggest destroying index cards that were used for this exercise.

Are We Going to Make It?

  

 Email Article  

Tweet  

  

by Thomas Vollmer

In my previous post, I wrote about the importance of trust for effective agile development. A good way to build trust is to say what you are going to do, and then doing it.

For any given sprint, the team says what they are going to do in three major ways: definition of done, working agreement, and sprint commitment:

• The definition of done shows what actions the team considers mandatory for an item to be done. Often, different criteria are used for tasks, stories, sprints, and releases. For example, one criterion for a task to be done may be that the code is checked in and all tests pass.
• The working agreement shows how the team has decided to work together. For example, the team may require that all production code be written in pairs.
• The sprint commitment is given by the team during sprint planning, and includes which stories the team believes it can deliver that sprint.

Note that the definition of done and the working agreement are overall team agreements and not sprint specific. Also, they are very specific to any given team, and are best determined and agreed upon by that team for their particular situation.

Throughout the sprint, it is up to the team to do what they said they were going to do. Three things you can do at each daily standup to achieve this are:

1. As a team, take a quick look at the burndown chart
2. As a team, ask “are we going to make it?”
3. If not, discuss as a team what can be done in order to make it

What exact actions the team decides to take when things aren’t going well is of course critical. Helping each other out even though it’s “not my job” and doing the simplest thing possible (but no simpler) to solve technical problems are great. If that doesn’t suffice, I recommend thinking about not finishing one of the stories, which will directly reflect in velocity. This is by far the simplest to manage because the effect is immediate and highly visible. Breaking the definition of done or the working agreement (which usually translates to a drop in quality) usually causes indirect, non-linear and unpredictable effects.

In Trust We Trust

  

 Email Article  

Tweet  

  

by Thomas Vollmer

Effective Scrum depends on a high degree of trust between all team members, including the Product Owner and the ScrumMaster.

• Since the scope for a release is not fixed (only time and money are), Scrum asks the Product Owner to trust that with their help, the team is going to deliver the most value possible by the release date.
• In order to make this happen, the team needs a very strong focus on results, which ultimately depends on trust among team members.
• Scrum asks the ScrumMaster to trust the team to self-organize and deliver. In order for the team to take responsibility for results, the ScrumMaster must allow the team to fail safely when needed.

There are of course more instances of mutual trust, but the above should give you an idea.

No matter what role you play on a Scrum team, ask yourself at the end of each sprint: did we increase trust among each other?

Fostering Collaboration in a Multicultural Scrum Team

  

 Email Article  

Tweet  

  

by Valerie Morris

I was talking with a colleague who is a ScrumMaster for an international team. All of the team members are co-locate in the same physical locale and are working together as a Scrum team. So, what do I mean by international team? Often, we use the term international to insinuate geography — I am using the term to represent cultural and diversity about this particular Scrum team, called Mad Dog. There are 9 members on the team representing Russian, Japanese, Chinese, Indian, Scottish, and American cultures. This diversity creates a rich opportunity for team members to form relationships outside of their primary language and customs.

In our conversation, the ScrumMaster told me about a situation some of the team members were experiencing with team conversations. Here is the scenario he presented to me:

“Recently I had a delivery team member (now a former delivery team member) complain that other team members were speaking a foreign language in the team room and that it was an impediment to him. I didn’t give it too much thought because I thought it was a onetime occurrence. Now I’m seeing it very often. What is your perspective on how I can address this with the team?”

In my response to him and anyone else struggling with this same thing, I recommend bringing this topic up in a conversation about the team’s working agreement. We are comfortable with our learned primary language and customs. Being on the outside of one or both if these may cause people to feel left out or insecure. This is an area to build trust and acceptance of a multinational team. As a ScrumMaster, you must facilitate a discussion with the team about “what a team is”. Remind people about the team values of openness, courage, and respect. The diversity of a team can be embraced through all of these values. The team will come to an agreement on this topic if you help them find their voices.