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

Agile Scrum Master Role

I was asked to put together a clear definition of an Agile Scrum Master role for a company I am working with that is new to Agile. I think the standard “textbook” definition of what a Scrum Master does is limited and needs some interpretation and elaboration. It also needs to be expanded with some best practices for Scrum Masters from a variety of sources (see below). Here is what I came up with:

  1. Team Management – A commonly held view of Scrum Masters is that they are only passive facilitators because the team is supposed to be self-organizing. That may be true in an ideal world, but very few teams are really at that level from my experience and even teams that are at a high-level of proficiency can slip back. In my opinion, Scrum Masters have to use what I call “Adaptive Leadership” – if a Scrum Master is only a passive facilitator, he/she is not doing the job effectively in my opinion. He/she has to provide a sufficient level of leadership to help the team get to a self-organizing level and then sustain it without over-managing the team. “Adaptive leadership means providing just enough leadership to fit the situation and nothing more. Here are some specific components of that role:
    • Team Productivity
      • Ensures that the team is fully functional and productive including having the right tools, training, and process flows to maximize team productivity
      • Coaching the Development Team in self-organization and cross-functionality
      • Helping the Development Team to create high-value products
      • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood
      • Constantly help to improve tools and practices used by the team so that the efficiency is always maintained
    • Remove Impediments
      The Scrum Master should resolve all the impediments so that the team can concentrate on the engineering tasks to be done.
    • Performance Appraisal & Feedback
      The Scrum Master will provide necessary feedback to the team members to help them improve their performance.
    • Resolve Conflicts
      The Scrum Master should be in touch with the team members to sense any conflicts early and resolve them
  2. Process Management – 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.
    • Meeting Facilitator
      Facilitates Daily Scrums and Other Scrum Events to ensure that they are well-organized, time-boxed and productive.
    • Process Master
      The Scrum Master will typically serve as the scrum expert on the team. This means they are responsible for helping the team optimize the use of scrum as the methodology they have chosen to build their software.
      The Scrum Master creates the scrum rules for the project and then coaches the team to follow Agile principles and practices. At the end of the sprint, he needs to ensure that every user story is completed as per the definition of done.
    • Team Interface
      Serves as the primary interface to the team to manage communications with the team and shield the team from disruptive external influences.
    • Planning and Estimation
      Coach the team on estimation practices, lead the team in estimation during the planning meeting, and work with the team to improve estimation and planning process
    • Continuous Improvement
      Leads and facilitates retrospective meetings and champions efforts to improve on the quality, velocity, value to the business
  3. Project Management – The Scrum Master is not really a Project Manager; however, there are some project management skills that are useful in the role. The Product Owner should really own responsibility for the overall success or failure of the project; however, a Scrum Master plays a number of roles in support of the Product Owner in performing the program/project management function.
    • Support the Product Owner
      • Assists the Product Owner with various activities including assisting with backlog as well as project-level and release-level planning
      • Helping to ensure that the items in the backlog are clear and concise
      • Working with the Product Owner to prioritize the items in the backlog
    • Organizational Transformation
      • Leading and coaching the organization in its Scrum adoption;
      • Planning Scrum implementations within the organization;
      • Helping employees and stakeholders understand and enact Scrum and empirical product development;
      • Causing change that increases the productivity of the Scrum Team; and,
      • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
    • Radiate Information
      Radiate information or ensure that a team’s progress and successes are highly visible to all stakeholders, including the team itself.

In addition to my own personal experience, I have used the following sources to compile this list:

  1. Scrum Guide – http://www.scrum.org/scrum-guides/
  2. Scrum Master Roles & Responsibilities by Amit Malik – http://amitsinghmalik.blogspot.com/2013/06/scrum-master-roles-responsibilities.html

What’s the Difference Between Anarchy and Self-Organizing Teams?

What’s the difference between anarchy and self-organizing teams? The Merriam-Webster dictionary defines “Anarchy” as:

  • a state of lawlessness or political disorder due to the absence of governmental authority
  • a utopian society of individuals who enjoy complete freedom without government
  • absence or denial of any authority or established order

Wikipedia defines “self-organization” as follows:

Self-organization is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent.”

However, that doesn’t mean that self-organizing teams are given a blank check to do whatever they want to do without any higher-level direction and it also doesn’t mean that self-organizing teams should not be held accountable for their actions. The team needs to earn the right to be self-organizing by proving that they are responsible about making and keeping commitments – that’s an essential part of self-organization and one of the key things that distinguishes self-organization from “anarchy”. It would be irresponsible for any manager to rely on a team to be self-organizing if the team doesn’t hold themselves accountable for meeting commitments.

Reliance on self-organizing teams is a very powerful and very important concept in Agile and, if it is done correctly, it can have a huge impact on the whole company. As an example, Valpak, is one of the successful case studies in my book and one of the significant differences Agile has made on their organization is due to self-organizing teams:

  • Prior to Agile, the company had to do a fair amount of management (as most companies do) to resolve individual and team performance issues
  • After Agile, those issues almost totally went away because the teams became self-organizing. If there was someone with a performance issue on the team, the team did not tolerate it and resolved it themselves.

The successful implementation of Agile and self-organizing teams at Valpak allowed their senior management team to focus on higher-level strategic issues much more than they had ever been able to do before because they were freed from managing so many day-to-day issues.

What are the attributes of a good, self-organizing team?

  • They understand and take responsibility for fulfilling the higher-level business direction of the company that they work for but no one has to micro-manage them to get it done.
  • No one needs to pressure them into making commitments – they make commitments eagerly, voluntarily, and responsibly.
  • They’re very clear and unambiguous about the commitments that they make
  • They take commitments seriously and have the integrity and self-discipline to take accountability for their actions and follow-through to make sure that any commitments they make are consistently met

Developing a highly effective, self-organizing team is not an easy thing to do and it can take time but its a very powerful component of Agile. There is also typically a balance between letting self-organization go too far and becoming an end in itself or turning into anarchy. Most companies do not exist totally for the benefit of the workers (that’s what socialism is and we all know how successful that is) so overall business direction and leadership is still important. What is needed; however, is visionary leadership, not micro-management.

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.