Tag Archives: Agile Teams

Managing Conflict in Agile Teams

I recently saw a LinkedIn post from someone who was requesting advice on managing conflict in Agile teams. One response was to remove the people who are causing the conflict from the team. That may not be an appropriate solution – some level of conflict is necessary and healthy in a high performance team. A team where everyone always agrees with everyone else on the team would probably not be a very high performance team. In this particular situation, the conflict was occurring over estimation and that’s an area where you certainly want to bring out opposing views and attempt to resolve them rather than suppress them.

The right way to manage conflict on an Agile team is not to try to stifle conflict but to accept some values among the team to listen to the views of others and treat them with respect and consideration if you disagree with them. Each person on the team also needs to put their own ego and emotions aside and instead of focusing on who’s right and wrong, focus on working collaboratively with others towards what is in the best interest of the team and the business. Some times people become argumentative and pursue an argument just to have the last word or try to prove that they’re right and others are wrong – that behavior can be very counter-productive. Having a clearly-defined set of values that everyone on the team agrees to is a good way to minimize that kind of behavior.

I suggest that anyone who wants to learn more about team dynamics do some reading on “Tuckman’s Stages of Group Development”. It’s an excellent model for understanding the stages teams go through in the journey to becoming a high performance team. Here’s a brief summary – Tuckman’s model consists of four stages:

  1. Forming
    “Individual behavior is driven by a desire to be accepted by the others, and avoid controversy or conflict. Serious issues and feelings are avoided, and people focus on being busy with routines, such as team organization, who does what, when to meet, etc. But individuals are also gathering information and impressions – about each other, and about the scope of the task and how to approach it. This is a comfortable stage to be in, but the avoidance of conflict and threat means that not much actually gets done.”
  2. Storming

    “Individuals in the group can only remain nice to each other for so long, as important issues start to be addressed. Some people’s patience will break early, and minor confrontations will arise that are quickly dealt with or glossed over. These may relate to the work of the group itself, or to roles and responsibilities within the group. Some will observe that it’s good to be getting into the real issues, whilst others will wish to remain in the comfort and security of stage 1. Depending on the culture of the organization and individuals, the conflict will be more or less suppressed, but it’ll be there, under the surface. To deal with the conflict, individuals may feel they are winning or losing battles, and will look for structural clarity and rules to prevent the conflict persisting.”

  3. Norming

    “As Stage 2 evolves, the “rules of engagement” for the group become established, and the scope of the group’s tasks or responsibilities are clear and agreed. Having had their arguments, they now understand each other better, and can appreciate each other’s skills and experience. Individuals listen to each other, appreciate and support each other, and are prepared to change pre-conceived views: they feel they’re part of a cohesive, effective group. However, individuals have had to work hard to attain this stage, and may resist any pressure to change – especially from the outside – for fear that the group will break up, or revert to a storm.”

  4. Performing

    “Not all groups reach this stage, characterized by a state of interdependence and flexibility. Everyone knows each other well enough to be able to work together, and trusts each other enough to allow independent activity. Roles and responsibilities change according to need in an almost seamless way. Group identity, loyalty and morale are all high, and everyone is equally task-orientated and people-orientated. This high degree of comfort means that all the energy of the group can be directed towards the task(s) in hand.”

  5. There are a couple of important things to recognize about this model:

    • You can’t just jump past the “Storming” stage and go right to the “Performing” stage unless the people on the team have a lot of maturity on working in other teams. You have to progress through these stages to some extent to make progress. For that reason, conflict should be viewed as a sign of progress that you’ve moved past the “forming” stage.
    • You don’t necessarily always proceed through these stages in a strict sequential order…sometimes a team will regress and fall back to an earlier stage and start over from that point and you might go back-and-forth like that over a period of time.
    • The natural progression for a team that is in conflict is to move to the “norming” stage and you do that by adopting rules and values of how the team interacts with each other. Those rules and values are like “training wheels on a bike”. After teams have reached a point of maturity, those rules become just a natural part of people’s behavior and the team reaches the “performing” stage which is similar to riding a bike without the “training wheels”.

    Source: “Stages of Group Development”

    One of the key points in this model is the conflict is a normal and necessary stage of progression on the journey to becoming a high-performance team. For that reason, you shouldn’t try to stifle conflict – the best approach is to manage it by setting values so that it doesn’t become destructive.

Emotional Intelligence in Agile

The role of emotional intelligence in Agile is important to understand. HelpGuide.org defines “emotional intelligence as follows:

“Emotional intelligence (EQ) is the ability to identify, use, understand, and manage emotions in positive ways to relieve stress, communicate effectively, empathize with others, overcome challenges, and defuse conflict. Emotional intelligence impacts many different aspects of your daily life, such as the way you behave and the way you interact with others.”

“If you have high emotional intelligence you are able to recognize your own emotional state and the emotional states of others, and engage with people in a way that draws them to you. You can use this understanding of emotions to relate better to other people, form healthier relationships, achieve greater success at work, and lead a more fulfilling life.”

Why is that so important in an Agile environment? Because Agile relies so heavily on teamwork and open, honest, and transparent communication both within the team and with other stakeholders outside of the team.

HelpGuide.org goes on to define four key attributes associated with “emotional intelligence”:

  • Self-awareness – You recognize your own emotions and how they affect your thoughts and behavior, know your strengths and weaknesses, and have self-confidence.
  • Self-management – You’re able to control impulsive feelings and behaviors, manage your emotions in healthy ways, take initiative, follow through on commitments, and adapt to changing circumstances.
  • Social awareness – You can understand the emotions, needs, and concerns of other people, pick up on emotional cues, feel comfortable socially, and recognize the power dynamics in a group or organization.
  • Relationship management – You know how to develop and maintain good relationships, communicate clearly, inspire and influence others, work well in a team, and manage conflict

Source: www.helpguide.org/mental/eq5_raising_emotional_intelligence.htm

The easiest way to see how this impacts the performance of Agile teams is to observe the behavior of someone who has a low level of emotional intelligence. Here is an example: on an Agile team I’ve worked with, there was one particular individual who was very bright and intelligent but had a very strong and dominating personality and what I would consider a low level of emotional intelligence:

  • He liked to be in control of everything and be seen as the “hero” who is leading the entire effort – there was a saying on the team that if it’s not XX’s idea, it sucks
  • He was opinionated and confrontational, didn’t value other people’s perspective, and attacked other people openly in emails
  • He had such a vested interest in his own ideas and proving himself “right” that he lost objectivity and wasn’t able to see different sides of a decision

How does that impact the effectiveness of an Agile team?

  • It can stifle the contribution of others on the team – it’s well known that more minds can work better than one and the performance of a team is maximized when everyone on the team is fully engaged and actively contributing to decisions and the work of the team.
  • It can lead to poor decisions because decisions may be biased in favor of one person’s point of view and may not objectively consider all aspects of the problem

Here’s some excellent additional reading on this subject:

http://www.helpguide.org/mental/eq5_raising_emotional_intelligence.htm

How do you acquire “emotional intelligence”? I believe that the first and most important step is self-awareness – you have to be somewhat introspective and be able to look at yourself openly and honestly and also learn to be comfortable being open and transparent with others. That doesn’t come naturally to all people and requires a certain amount of self-confidence to develop. Many people have a “shell” that they operate within and that “shell” can be either thick or thin. There’s a concept that I learned a long time ago called the “Johari Window” that is still valid today. The Johari Window breaks up people’s self awareness into four quadrants:

  1. Open/Free Area – Personality attributes and characteristics that are known to yourself and to others
  2. Blind Area – Personality attributes and characteristics that are known to others but not by yourself
  3. Hidden Area – Personality attributes and characteristics that are known by yourself but not by others
  4. Unknown Area – Personality attributes and characteristics that you are not fully aware of and others are also not aware of.

Source: http://en.wikipedia.org/wiki/Johari_window

Alan Chapman has created a very nice diagram that shows the relationship of these four quadrants:

Johari Window Model

Source: http://www.businessballs.com/johariwindowmodeldiagram.pdf

People who have a high level of self-awareness and who are also open and transparent in their behavior with others have a relatively large quadrant one (Open/Free Area) and the other quadrants are relatively small. Of course, the objective of increasing your self-awareness, openness, and transparency is to increase the size of quadrant one (Open/Free Area) relative to the size of the “Blind” and “Hidden” quadrants. Another objective is to more fully develop your true potential through self-discovery of skills, attributes, and characteristics in the “Unknown” area that neither you or others you interact with are fully aware of.

Years ago, I can remember many companies made self-awareness training a key part of their management development curriculum for new managers. The principle behind that was that you couldn’t be very effective as a manager if you had a hidden personal agenda and you weren’t open and transparent in your relationships with other people. Your employees will recognize the external veneer that you put on, see right through it, and lose respect for you.

Unfortunately, over the years, many companies have cut back on that kind of training. It was perceived as too “touchy-feely” and when times got tough, it was one of the first things that got cut because it was not seen to have a direct contribution to company profitability. The relationship to company profitability may be indirect, but I think it is just as essential today for managers and even more important for people participating in Agile teams.

There are some exercises that can be done with Agile teams to develop higher levels of self awareness. For example, here’s a Johari Window self-assessment tool:

http://kevan.org/johari

A key element for successful implementation of these exercises is creating an environment of trust where people feel comfortable with being open and honest with others in a small group. Once people have become comfortable with doing that in a small group, they can then take more risks and practice the same behavior outside of that small protected group environment.

Thoughts and Recommendations on Scrum Master Training

This is not a plug for a Scrum Master training course… I was recently asked to provide some thoughts and recommendations on Scrum Master training for a person who was new to the Scrum Master role. This particular individual knew the basic mechanics of how to do Scrum but needed to take the performance of the team to the next level. I want to share my recommendations with you because I think this is a fairly common situation.

  • The biggest problem is that many people don’t understand the full scope of the Scrum Master role. They see it as a passive facilitator role and all you need to know is the mechanics of how to do Scrum. If that’s the way you see it, you can get the standard CSM certificate and call it “done”; I think it is much more than that. (See my recent post on the Scrum Master role):http://managedagile.wordpress.com/2013/08/17/scrum-master-role
  • I thought that the standard Certified Scrum Master (CSM) course would be a waste of time and money for this individual unless it is taught by someone really good who goes beyond the basics. Most CSM courses only cover the basic mechanics of Daily Standups, Sprint Reviews, Retrospectives, etc. and that’s a very small fraction of what a good Scrum Master needs to know, in my opinion.
  • However, I did think it would be worthwhile for this individual to take an assessment of Scrum Master knowledge without going through the standard CSM course – an assessment exam is relatively inexpensive ($100) and that exam will help validate that the individual has the basic Scrum Master knowledge or not and will help to highlight any areas of weakness. Here’s a link for registering to take the Professional Scrum Master Self-Assessment:http://www.scrum.org/Assessments/Professional-Scrum-Master-Assessments/PSM-I-Assessment

What is needed in many cases is an Advanced Scrum Master training course, but there are very few of those offered. Standard CSM courses are available all over the place, but very few people offer an Advanced Scrum Master course that goes beyond the basics because so many people seem to be content to get the CSM certificate and call it “done”.

A good Scrum Master, in my opinion, is passionate about Agile and doing it with a level of excellence. He/she should be somewhat of an evangelist to help others thoroughly integrate Agile/Scrum values, principles, and practices into the way that they work. That’s what is needed, in my opinion. There are many situations like the one I was in where the company was doing the “mechanics” at a basic level and what’s needed is to go beyond that basic level to really dramatically improve the performance of the team. In that kind of situation, you’ve really got to become somewhat of an Agile “zealot” to do it well and one CSM course is not likely to do that.

It requires a strong commitment to ongoing learning and development to become a really good Scrum Master. Essentially, you need to commit yourself to becoming an “Agile Expert”. There are a lot of regularly scheduled Agile events sponsored by Agile groups throughout the world where people share knowledge of what works and what doesn’t work in the real world. Don’t forget that Agile is based on very empirical knowledge… beyond a certain point, there is no textbook that I’m aware of to tell you exactly what to do.

Another course and certification that I think is worthwhile to consider (but not necessarily the first thing to do) would be to get the PMI-ACP certification. ACP stands for “Agile Certified Practitioner” and is a new PMI certification designed primarily for project managers who work in an Agile environment. I have that certification and I think it is worthwhile. Here’s what I like about it:

    • I think the PMI-ACP exam is more rigorous than the CSM exam and the certification has some more rigorous experience requirements that the CSM certification doesn’t require
    • The PMI-ACP certification takes a broader view of Agile not limited to Scrum and covers other related knowledge areas such as Lean and helps you see the “Big picture” of what Agile is all about; where CSM is really focused on Scrum and the mechanics of how to do Scrum

Both have value…you do need to know the mechanics of how to do Scrum, but it’s also worthwhile to see the “big picture” of Agile as well to better understand the principles and practices at a higher level. You will find information on the PMI-ACP certification here:

http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx

I think certifications have value if they’re used in the right way. Some people seem to use them to “punch a ticket” and call it done. I see certifications as part of a program of ongoing learning. They can be useful to calibrate what you know and don’t know, particularly if you do a lot of self-study as I do; but getting a particular certification should rarely be an end in itself.

The Impact of “Tunnel Vision” in Agile

I am amazed at the amount of “tunnel vision” in Agile. Many people see it only as a development process for single teams and don’t pay much attention to the larger context that the development process operates in. An Agile project always exists inside of some business context and if you look at the project from that business context rather than looking at it only from a development perspective, you might see a very different picture.

A pure Agile approach is best suited for a company that is in the business of producing some kind of software product (an example would be Intuit and TurboTax or Quicken) or where the software plays a very direct role in leveraging the company’s primary business (an example would be Amazon.com). Where that is not the case and the company’s business is only indirectly leveraged by the Agile development process (an example would be an internal IT application development project), it can be a lot more difficult to implement an Agile development process because more adaptation may be required to fit the Agile development process to the company’s business environment.

Here’s the difference – in the product development company, the company typically budgets a fixed amount of development effort to produce and sustain the product and the business decision is primarily about prioritizing how that money is spent on creating new features for the product to get the most business impact. That kind of business decision fits very nicely with an Agile development process approach and it’s relatively easy to implement an Agile development approach in that kind of environment.

In a company that is in some other kind of business where the software development effort plays a more indirect role in leveraging the company’s business, there is typically a very different kind of decision process. An example would be a company whose business is focused on achieving operational excellence (like Walmart) and not heavily focused on product innovation as a primary business goal. In that kind of environment, there is typically some kind of Project Portfolio Management approach to determine how to allocate the company’s IT budget to get the most “bang for the buck”. The company needs to choose the projects that are going to provide the highest amount of leverage to the business and then monitor those efforts to see if they really do produce the desired effect.

At the level of a single team development process, the effort may look the same as a product development company, but the business context is entirely different and requires some adaptation. The primary difference is in the level of planning required. In a product development company, you might be able to use a highly adaptive approach with almost no Product Backlog defined in advance and you might be able to almost completely define the requirements for the project as it progresses looking no more than 2-3 sprints ahead into the future. That’s what a pure Agile approach looks like; however, that doesn’t work in environments where there is more of a need to plan the project in advance and estimate the schedule and costs of the project to support a higher-level project portfolio management decision process.

In those environments, there is a typically a need to at least define the Product Backlog to a sufficient level to define the scope of the project and to provide at least a high-level estimate of the costs and schedule for the project. Some people will say that it is futile to attempt to estimate the costs and schedule for an Agile project because the requirements are only going to change. I don’t totally buy that…this is not an all-or-nothing decision to have a project totally planned in detail (like the Waterfall approach) or not planned at all (totally adaptive). There are plenty of alternatives between those two extremes to pick a level of planning that is appropriate for the project, the level of uncertainty in the requirements, and the business environment that it has to operate in.

Some people will also say that you have to force the entire company to change its culture to become totally Agile in order to implement an Agile development process. A company has to define its culture around what makes the most sense for the business it operates in and that may or may not align very well with an Agile development process. In the product development company, it probably aligns very well and it makes sense for the company to become more Agile in delivering new and innovative product features to market quickly. In a company like Wal Mart whose business is leveraged primarily by operational excellence and lower costs, that is probably not the case and you can’t necessarily force the company to adopt a totally Agile culture.

The key message is that you have to consider an Agile development process in the context of the business it operates in and many times you need to adapt an Agile development process to fit the business environment. Within the development process itself, the process may be largely the same – the differences may come into play at a higher-level such as the project portfolio management layer that wraps around the project. Those higher-level layers could also be Agile (Dean Leffingwell’s Scaled Agile Framework is an example), but that kind of complete, top-to-bottom Agile transformation just doesn’t work in all business environments.

Making Agile Work with Offshore Teams

One more excellent question I got at the Valpak presentation last night was regarding “Making Agile Work with Offshore Teams” Here’s a brief response…There are a lot of difficulties and you have to be willing to accept a lot of compromises from an ideal Agile team. Here are a few examples:

  1. Commmunications is a major challenge. I was in a situation where the entire development team was in India and only the customer-facing people were in the US. In a normal Agile environment where the team is collocated and on the same time zone, a brief Daily Standup may be sufficient; but if that is the only (or primary) form of communications with the team throughout the day, it can be very difficult to limit the Daily Standup to just a brief 15 minute session. You have to learn to adapt the communication practices to the situation.
  2. Tools are essential to help close this communication gap and maintain coordination. Where you might be able to use “stickies” on a board with local, collocated teams; that just doesn’t work very well at all with distributed teams to keep everyone informed about what everyone else is doing.
  3. Cultural ChallengesThere are several significant cultural challenges:
    • There are a lot of good developers in India, but it can be very tough to find a lot of senior-level developers. In the Indian culture, someone may be perceived as a failure if they haven’t moved into a management position by some point in their career. For that reason, becoming a very senior-level developer who is not in a management position may not be regarded very highly. The impact of that is instead of having a team of peers who are self-organizing and all individually capable of self-directed work, you may have to compromise and select a few senior-level Team Leaders to provide direction to the rest of the team.
    • Indian people are also very polite and respectful and somewhat regimented (probably due to many years of British rule). In an ideal Agile team, that also works against being a totally self-directed team and you may find that more direction needs to be provided to the team.

Those are only a few of the more significant challenges, but the Indian people work very hard and are very committed to their work. If you go into it expecting that you’re going to be able to setup an ideal team as if they were collocated and from the same culture, you’ll probably get very frustrated; but if you learn to make the best of the situation and make a few compromises, you will find it to be a pleasure to work with the people in India – it just takes a bit of adaptation to make it work.

Overcoming Misconceptions About Agile Teams

There are a lot of misconceptions about Agile teams. There is no doubt that “Agile is a team sport”, but have you really thought about lessons learned from team sports that can be applied to Agile teams? Many people have the view that an ideal Agile team is a team of peers where there is no specialization among people on the team, everyone on the team is capable of performing any role, and everyone on the team is also responsible for everything. That’s a very idealistic view and may not be the best way for Agile teams to work. For example:

  • Is it inconsistent with Agile for a more senior-level Tech Lead to provide direction to other more junior-level developers? My experience in the real world is that you don’t often find teams who are all peers and it may not be practical or cost-effective for a company to staff a development team with all senior-level people who are all self-sufficient. The key thing is that you can have people at multiple levels of proficiency on a team without creating a formalized hierarchical structure that inhibits individual productivity and initiative.
  • Is it inconsistent with Agile for individual people on the team to have defined roles like QA testing and does that limit the ability of the team to be cohesive? Think of a football team – each player has a role that he specializes in and is good at that role. A football team probably wouldn’t be very good if there was no specialization and everyone did a little of everything. The center might be a 300 pound gorilla and might be very good at blocking and tackling, but he may not be very good at throwing touchdown passes. Imagine the 180 pound quarterback attempting to play on the front line and blocking and imagine the 300+ pound center attempting to play the role of the nimble quarterback throwing passes.Specialization on a team doesn’t preclude developing high-performance teams with very cohesive teamwork. Having someone on a team who is skilled in QA testing and is specialized in playing that role is a lot different than having a separate QA group outside of the development team who specializes in QA testing.
  • Some people seem to think that having well-defined individual roles and accountability is inconsistent with having overall team accountability – shouldn’t everyone on the team be responsible for everything? Think of a football team again – everyone on the team, as a whole, is responsible for winning; but what if everyone on the team just ran around without defined roles that they were responsible for and without defined plays trying to figure out what to do to get the ball across the finish line? It wouldn’t be very likely to be a very high-performance winning team. Teams where “everyone is responsible for everything” and there is no individual accountability for anything are not likely to be very effective.

Agile Is a Lot Like Playing Golf – It Can be Very Difficult

Agile Is a Lot Like Playing Golf -there are a number of things about Agile that remind me of playing golf.

  • In the game of golf, if you didn’t have to get the ball in the hole, my golf score would be a lot better.  Imagine if the requirement in golf was only to get the ball somewhere near the green – if you didn’t actually have to get it in the hole, my score would be a lot better, but that would be very misleading, wouldn’t it?That’s equivalent to a team that doesn’t have a clear definition of “Done”. On the surface, it may look like they’re completing sprints successfully, but when you look deeper, you sometimes discover that there is not a good process to validate that the work is really complete and really meets the business need it is intended to fulfill.
  • The reason golf can be such a difficult and frustrating game to master is that it requires a fair amount of discipline, lots of practice, and lots of patience and persistence to be good at it – Agile is the same way.
  • Golf also requires some planning and strategy – the best players carefully consider every shot; They don’t just go out there and whack the ball around.