Category Archives: Agile Teams

How Do You Improve Team Performance in a Project Environment?

I recently responded to a question about “How do you improve team performance in a project? 

How to Improve Team Performance

  • It is very common for project managers to over-manage teams and I think that is a mistake
  • A team is like a dynamic organism. Rather than simply putting pressure on the team to improve performance, a better approach is to understand the dynamics of how a team performs. You can then work on the factors that impact improving performance
  • An even better approach is to help the team become self-organizing and take responsibility for improving their own performance
Improve Team Performance

What is a Self-organizing Team?

Here’s a good definition of a self-organizing team from the Scrum Alliance web site:

“A group of motivated individuals, who work together toward a goal, have the ability and authority to take decisions and readily adapt to changing demands”

The diagram below shows a comparison of a traditional project team and a self-organizing team:

What is a Self-organizing Team

Does This Mean Abdicating all Responsibilities to the Team?

The principles behind empowered teams can be used in any project. It is just different levels of empowerment.  The diagram below shows a comparison of different levels of empowerment:

How Do You Improve Team Performance

Here’s a description of each of these levels:

LevelDescription
Manager-led TeamThe lowest level of empowerment is a “manager-led team”. In that environment, the only responsibility delegated to the team is for managing the execution of tasks that they are responsible for.
Self-governing TeamAt the other extreme is a “self-governing team” where the team takes complete responsibility for their operations including setting their own direction. It would be unlikely to find that level in a project team but you might find a senior management leadership team that operated that way.
The two levels below are more typically found in an Agile environment:
Self-managing TeamA “self-managing team” takes responsibility for monitoring and managing work process and progress.
Self-organizing TeamA “self-organizing team” goes beyond that and takes responsibility for designing the team including defining roles within the team and defining the organizational context of how the team operates.

An important point is that “self-organizing” does not mean that a team does not need any direction at all. Self-organizing teams should not be used as an excuse for anarchy.

What Are the Advantages of Empowered Teams?

There are a number of advantages of empowered teams:

  • Empowered teams more fully utilize the capabilities of the people on the team
  • They reduce the need for someone to directly manage all aspects of how the team operates
  • They improve team performance because the team takes more responsibility for managing its own performance
  • Team performance is more sustainable because the performance of the team is more self-correcting
  • It encourages creativity and innovation and enables the team to quickly adapt to new problems and challenges

How Do You Improve Team Performance?

Project Managers have a tendency to over-manage the performance of teams because the perception is that is what a Project Manager or Team Leader is supposed to do.

  • However, in many cases, simply putting pressure on the team to improve performance may not be effective
  • A more proactive and more sustainable approach is to better understand how the team functions as a dynamic organism. You can then work on the factors that drive performance.

In an Agile environment, there may not be a project manager involved at all at the team level:

  • If a project manager is involved at that level, he/she needs to be more of a coach to help the team improve its own performance.
  • However, there is no reason why the idea of empowered teams is limited to an Agile environment
  • The same ideas can be applied in a traditional plan-driven environment; however, it may involve somewhat less empowerment

1. Traditional Plan-driven Projects

In a traditional plan-driven project team, a Project Manager or Team Leader typically provides direction to the team:

  • The project manager is the one who is held responsible for the performance of the team and the results that they produce, and
  • Some level of control may be needed to manage conformance to the project plan

However, even in that kind of environment, it is essential to delegate some level of responsibility to the members of the team.

2. Agile Projects

In an Agile project,

  • There is a much higher level of emphasis on creativity and innovation rather than conformance to a plan
  • In that kind of environment, it is very important to fully empower all the members of the team to actively contribute to the solution as much as possible

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Managing Conflict in Agile Teams – Is Conflict Normal?

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.
Managing Conflict in Agile Teams

How Do You Manage Conflict in Agile Teams?

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.

Tuckman’s Stages of Group Development

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

The first stage is called “Forming”. In this stage, “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

The next stage is called “Storming”. During this stage, “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

The final stage is called “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.”

There are several 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”

Overall Summary

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.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Levels of Mastery in Agile – How Do You Measure Maturity?

I came across the diagram shown below that I think nicely summarizes different levels of mastery in Agile:

Levels of Mastery in Agile

Many people don’t seem to realize that there are these three different levels of mastery and just learning the basic practices is only the beginning.

Three Levels of Mastery

The three levels of mastery are:

1. Practices (Doing)

The initial level of Practices is associated with learning the basic practices of Agile at a mechanical level.

  • There are many people who are at this level of learning – they’ve received their CSM certification (or equivalent) and they may have had some practice in the real world and know how to do the basics.
  • The danger is that many people think that this is all they need to know when they have mastered this level of learning.
  • People who get stuck in this level of learning can become fairly ritualistic or dogmatic and insist that there is only one way to do Agile and that is doing it exactly by the book as they have learned to do it.

2. Principles (Understanding)

People who have gone on to the Principles level of learning have gained a deeper understanding of the principles behind Agile and why it makes sense.

  • This deeper level of understanding gives people a broader perspective – instead of seeing Agile as a mechanical process that must always be done ritualistically “by the book”, people at this level recognize that there may be a need to customize and adapt the processes to fit a given situation.
  • They are also able to see Agile in a much broader context beyond the basic team-level Agile implementation and recognize the need to make Agile work at much higher levels of complexity for large enterprise-level projects.

3. Values (Being)

Values is the highest level of mastery.

  • People at this level of learning not only understand the principles at a deeper level, they also understand the values behind those principles and have internalized those values into the way they work.
  • People at this level are becoming Masters and are at the “top of their game” – they are able to easily go beyond applying Agile to routine Agile project implementations and they are able to apply the principles and practices to much more demanding and difficult situations with much higher levels of consistency and success.

The three levels of mastery shown in this diagram correspond to the “Shu-ha-ri” levels of mastery from martial arts that I have previously discussed:

Agile and Lessons Learned From the Martial Arts

How Does This Relate to Agile Project Management?

How does this relate to the idea of “Agile Project Management”? People who look at Agile and traditional plan-driven project management practices (what many people tend to call “Waterfall”) at a basic level of practices will typically see them as competitive, mutually-exclusive, binary alternatives that are totally incompatible with each other. This is a basic problem and has led to Agile and traditional plan-driven project management being perceived as separate and independent domains of knowledge with little or no integration between the two.

  • I believe that people who are at a higher level of learning and understand the principles behind these two disciplines will see things in a very different perspective.
  • They will probably see them as much more complementary rather than competitive and recognize the reasons why one set of principles and practices makes sense in one situation and not another.
  • They will probably not see them as totally incompatible and be able to easily blend the two sets of principles and practices together as needed to fit a given situation.

Cooks and Chefs

One of my favorite analogies for this that was originally created by Bob Wysocki is the difference between a “cook” and a “chef”:

  • A good “cook” may have the ability to create some very good meals, but those dishes may be limited to a repertoire of standard dishes, and his/her knowledge of how to prepare those meals may be primarily based on following some predefined recipes out of a cookbook.
  • A “chef,” on the other hand, typically has a far greater ability to prepare a much broader range of more sophisticated dishes using much more exotic ingredients in some cases. His/her knowledge of how to prepare those meals is not limited to predefined recipes, and in many cases, a chef will create entirely new and innovative recipes for a given situation. The best chefs are not limited to a single cuisine and are capable of combining dishes from entirely different kinds of cuisine.

This is the challenge that I believe we face in creating a more integrated approach for Agile Project Management. We need to develop more “chefs” who are capable of seeing both Agile and traditional plan-driven project management principles and practices in a very different light as complementary rather than competitive alternatives.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Emotional Intelligence in Agile – Why Is Emotional Intelligence Important?

The role of emotional intelligence in Agile is important to understand. It is a skill that is very difficult to master for many people.

Emotional Intelligence in Agile

What is Emotional Intelligence?

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

Why is that so important in an Agile environment? It’s important 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.

Key Attributes Associated with Emotional Intelligence

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

CharacteristicDescription
Self-AwarenessYou recognize your own emotions and how they affect your thoughts and behavior, know your strengths and weaknesses, and have self-confidence
Self-ManagementYou’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 AwarenessYou 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 ManagementYou 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
  • He had a very strong and dominating personality and what I would consider a low level of emotional intelligence.

Here are some characteristics I saw – He:

  • Liked to be in control of everything. He wanted to 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
  • Was opinionated and confrontational, didn’t value other people’s perspective, and attacked other people openly in emails
  • Had a strong vested interest in his own ideas and proving himself “right”. He lost objectivity and wasn’t able to see different sides of a decision

Impact on an Agile Team

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

The Johari Window is a tool that is used to analyze someone’s level of self-awareness. It breaks up people’s self awareness into four quadrants:

AreaDescription
Open/Free AreaPersonality attributes and characteristics that are known to yourself and to others
Blind AreaPersonality attributes and characteristics that are known to others but not by yourself
Hidden AreaPersonality attributes and characteristics that are known by yourself but not by others
Unknown AreaPersonality 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

Key Points

The key points are:

  • 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)
    • The other quadrants are relatively small
  • 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.

How Do You Develop Self Awareness?

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

Overall Summary

Emotional Intelligence is important in an Agile environment.

  • It is essential for 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
  • Self-awareness is a very important skill for achieving emotional intelligence. You must be able to see yourself openly and honestly in order to improve

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

Agile and Lessons Learned From the Martial Arts

I was engaged in a discussion on LinkedIn that made me think about the relationship of Agile and lessons learned from the martial arts like Karate.

What Is the Similarity?

In theory, there should be a lot of similarity:

  • Techniques – There are a wide range of Martial Arts techniques that can be applied in different situations
  • Finesse and Skill – Most Martial Arts require finesse and skill; it’s not just a brute force approach
  • Levels of Skill – There are different levels of skill associated with Martial Arts and it is an ongoing journey to become a “master”

How Does It Compare to Actual Practice?

In actual practice; however, I think that Agile principles and practices are at a very low level of maturity compared to Martial Arts (that’s perfectly understandable given that Martial Arts have been around for thousands of years); however, there is a lot we can learn from martial arts that can be applied to Agile:

Techniques

Agile has become synonymous with Scrum as the primary methodology for implementing Agile and our knowledge of implementing Agile successfully is heavily defined by the “mechanics” of how to implement Scrum. Surely, there must be more to Agile than that. That’s equivalent to saying that Karate is the only Martial Arts practice when there are many, many others.

Finesse and Skill

I’ve seen many companies take a very superficial approach to Agile. They will do a few Agile practices like holding Daily Standups and putting up Kanban Boards and call it Agile. In many cases, if you look under the surface, it’s still just a brute force approach to get things done. They haven’t really fully implemented Agile principles and practices and they haven’t mastered the skill and finesse needed to do it well.

  • People may not be dedicated to Agile teams
  • The company may still rely on overtime, weekend work, and pressure to meet unrealistic deadlines
  • There may be no Product Owner role and the business side may not be well-integrated with the project
Levels of Skill

Many people don’t seem to realize that there are different levels of skill associated with Agile (some of those levels aren’t even fully understood yet).

  • There is a wealth of knowledge about how to do almost every aspect of Scrum at the team level but very little is understood about how to scale Agile to an enterprise level and how to integrate it with a business environment that isn’t necessarily well-suited to Agile.
  • There are also still very wide gaps in our understanding of how to blend Agile principles and practices with more traditional project management principles and practices which are often seen as competitive rather than complementary with Agile.

Shu-Ha-Ri

There’s a particular concept from Martial Arts that is helpful to understand the level of maturity we are at in Agile. The concept of “Shu-ha-ri” is a Japanese concept to define different levels of proficiency in Martial Arts:

“Shu” Stage

“Shu” means to keep, protect, keep or maintain.

  • During the “Shu” phase, the student builds the technical foundation of the art.
  • In “Shu”, the student should be working to copy the techniques as taught without modification and without yet attempting to make any effort to understand the rationale of the techniques of the school/teacher.
  • In this way, a lasting technical foundation is built on which the deeper understanding of the art can be based

“Ha” Stage

“Ha” is the second stage of the process.

  • “Ha” means to detach and means that the student breaks free from traditions to some extent.
  • In the “Ha” stage, the student must reflect on the meaning and purpose of everything that s/he has learned and thus come to a deeper understanding of the art than pure repetitive practice can allow.

“Ri” Stage

“Ri” means to go beyond or transcend.

  • In this stage, the student is no longer a student in the normal sense, but a practitioner.
  • The practitioner must think originally and develop from background knowledge original thoughts about the art and test them against the reality of his or her background knowledge and conclusions as well as the demands of everyday life.
  • In the Ri stage, the art truly becomes the practitioner’s own and to some extent his or her own creation.

(Source: Shu-Ha-Ri http://www.aikidofaq.com/essays/tin/shuhari.html)

Where Do You Stand?

If you think about our current level of knowledge of Agile as it exists today,

  • I think many people are still struggling with the “Shu” level to understand the mechanics of how to do Scrum and have a long way to go to really get to higher levels of mastery.
  • I’m not sure how many people realize how big this gap is between where we are now and where we need to get to.
  • I think there are many people who seem to think that all there is to know is the mechanics of how to do Scrum at the team level and I think we have hardly scratched the surface of the knowledge that is needed to be known about how to successfully do Agile Project Management.

Martial Arts have been around for thousands of years and there’s still a lot to be learned so its very understandable that our level of knowledge about Agile is at a fairly low level of maturity. For example, here is a very good article written by Patti Gilchrist on the innovations that Bruce Lee has brought to Martial Arts that has some similar thoughts to this article that I really liked:

http://www.projectmanagement.com/articles/278838/Of-Martial-Arts-and-Methodology

Overall Summary

There’s a lot to be learned from the levels of maturity in the martial arts that are directly relevant to Agile. It provides a good way of understanding the level of maturity of Agile teams.

Additional Resources

You will find much more detail on this in my Online Agile Project Management Training.

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:

Level of Developers

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.

Teamwork and Specialization

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.

Defined Individual Roles

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.