Category Archives: Scrum

Scrum is the most widely-used Agile methodology in the world. It is actually a flexible and adaptive framework that can be adapted to many different projects.

What Is Scrum and What Is Agile?

There’s a lot of confusion about “What Is Agile” and “What Is Scrum?”. This article provides a very brief explanation.

Loose terminology is a big source of this confusion. For example, many people use the word “Agile” when they really mean “Scrum”.

What is Scrum?

Difference Between Agile and Scrum

For that reason, it is important to clearly understand the difference between Agile and Scrum. Here’s the difference:

If you want to learn more about Agile, check out this article on “What Is Agile – How Would You Define It? – What Does It Really Mean?”

What is Scrum?

Here’s the official explanation for “What is Scrum” from the Scrum Alliance:

“Scrum is a process framework used to manage product development and other knowledge work.

Scrum is empirical in that it provides a means for teams to establish a hypothesis of how they think something works, try it out, reflect on the experience, and make the appropriate adjustments.

That is, when the framework is used properly.

Scrum is structured in a way that allows teams to incorporate practices from other frameworks where they make sense for the team’s context.” – Agile Alliance

What Is a Framework?

Many people will say that it is inaccurate to call Scrum a “methodology” and that it really is a “framework”. What’s the difference? Here are a two key differences:

  • A “framework” is not very prescriptive and is normally adapted to fit a situation
  • A “methodology” is more prescriptive and provides a specific and well-defined approach for arriving at a solution

Empirical versus Defined Process Models

A related factor to understand the difference between a “framework” and a “methodology” is the difference between an “empirical” process model and a “defined” process model:

Defined Process Model

A “Defined Process Model” attempts to define every piece of work in advance in order to develop a detailed plan for completing the work. There are two very important characteristics of a Defined Process Model:

  • Repeatable – A Defined Process Model will produce the same outputs every time for the same set of inputs
  • Predictable – The results of a Defined Process Model are predictable in advance

For example, the diagram below shows a figurative depiction of a defined process using a well-defined methodology that is repeatable:

Defined Process Model

A traditional plan-driven project management approach as defined in PMBOK and a Waterfall model are examples of methodologies that follow a Defined Process Model.

Empirical Process Model

An “Empirical Process Model” is a style of work that leverages the principles of inspection, adaptation, and transparency. For that reason, an Empirical Process Control Model works best where the result that is needed is uncertain and the process to produce the result may also be not well-defined.

The diagram below shows a figurative depiction of how an empirical process model works. Basically, the process is not as well-defined and uses an incremental and iterative process based on some level of experimentation to try to arrive at an optimum solution.

Empirical Process Model

A key point is that in an empirical process model, you’re not really sure exactly what the solution will be and you’re also not exactly sure of what the optimum process for arriving at a solution is. Scrum is an example of an empirical process model.

Key Differences

The key difference between the two process models is related to the level of uncertainty in the project:

Low Level of Uncertainty

With a relatively low level of uncertainty, a defined process model might work best especially if there is a goal of being predictable because it is a predictable and repeatable model.

  • To achieve predictability, you would typically use a Defined Process Model because all of the work can be planned in advance
  • A Defined Process Model may also be more efficient because the work can be planned and organized in advance

For example, you would be very likely to use a Defined Process Model if you were building a house where it is important to have some predictability over the costs and schedule for completing the house.

Higher Level of Uncertainty

With a higher level of uncertainty, an empirical process model might work best because it provides a more adaptive approach for arriving at an optimum solution.

  • It may be less efficient than a Defined Process Model because it may require more trial-and-error but
  • It is much more likely to produce a more optimum solution, especially in an uncertain environment.

For example, if you set out to find a cure for cancer or some other disease that has no known cure, the solution is probably not well-known when you start the project and it likely requires some level of experimentation to arrive at at an optimum solution.

How Does Scrum Work?

Scrum uses an empirical process model that continuously refines both the product and the process to produce the product as the project is in progress. For that reason, Scrum works best in an uncertain environment.

Scrum Is Incremental

A Scrum process breaks up all the work into short development increments called “sprints”

  • Sprints are limited to a fixed-length that is normally 2-4 weeks long
  • The Product Owner prioritizes all work based on business value. That enables the team to deliver value as quickly as possible

Scrum Is Also Iterative

At the end of each sprint, the Product Owner and any important stakeholders review the results of the sprint and provide feedback and inputs

  • Providing direct feedback and inputs is essential to optimize the solution
  • Reviewing the results at the end of each sprint enables rapid learning for ongoing continuous improvement

Additional Resources

This is only a very brief, high-level overview of Scrum. If you want to learn much more detailed information, check out my Online Agile Project Management Training Courses. The first course is free!

What Are the Critical Skills of a Product Owner in Agile?

I recently participated in an online discussion on the question of “What are the Critical Skills of a Product Owner?” This is a very good question because the role of a Product Owner is not very well-understood. The actual role that a Product Owner plays can vary significantly in the real-world depending on the nature of the company’s business and the scope and complexity of the projects that the Product Owner is responsible for.

What are the Critical Skills of the Product Owner?

What Does the Scrum Guide Say?

The Scrum Guide defines the role of the Product Owner. However, it recognizes that the role varies widely across organizations. Here’s what the Scrum Guide has to say:

“The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”

“The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:”

  • Clearly expressing Product Backlog items;
  • Ordering the items in the Product Backlog to best achieve goals and missions;
  • Optimizing the value of the work the Development Team performs;
  • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
  • Ensuring the Development Team understands items in the Product Backlog to the level needed

“The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.”

Impact of the Nature of the Company’s Business

The nature of the company’s business will have a very big impact on the role of the Product Owner. In this regard, there are two major types of companies that are most significant:

  • Product-oriented Companies
  • Project-oriented Companies

Product-oriented Companies

Product-oriented companies who are in the business of selling products to external customers are at one extreme. In those companies, a Product Owner may have the full responsibilities of a Product Manager, including product profit-and-loss responsibility.

In this world, the critical skills of a Product Owner are essentially the same as the skills of a good Product Manager

Project-oriented Companies

At another extreme, are companies that are not really in the product development business at all. The work is more project-oriented to develop projects for internal use inside the company. In that kind of environment, the role of a Product Owner is likely to be very different. What is typical in this role is the role of the Product Owner is somewhat of a combination of a “Business Analyst on steroids” and a “Project Manager on steroids”.

Product Manager versus Business Analyst Role

A Product Owner has some attributes of a Business Analyst:

  • Both have a responsibility to represent the requirements of the business solution, but the Product Owner role is much more than an ordinary Business Analyst. A Product Owner has decision-making responsibility on the requirements where a normal Business Analyst does not have that kind of authority. 
  • The Product Owner also has some attributes of a Project Manager as he/she is responsible for the successful completion of the project. That responsibility is also much more than a normal Project Manager. A Project Manager is normally responsible only for delivering defined requirements without responsibility for the overall project’s business success. 

Critical Product Owner Skills

In this world, the critical skills of a Product Owner are:

  • Business Analysis Skills – Some “Business Analyst” skills are necessary for succinctly and accurately defining requirements but also have the domain knowledge and business knowledge to be a decision-maker to determine and prioritize what those requirements should be
  • Project Management Skills – Some “Project Management” skills are necessary to make good risk-based decisions on managing the project to make it successful from an overall business perspective (not simply meeting defined requirements)
  • Overall Management Skills – Above all else, the Product Owner is ultimately responsible for the success or failure of the project from a business perspective. He is an important decision-maker and is sometimes referred to as the “CEO of the project”.

Impact of the Scope and Complexity of the Project

Beyond the nature of the company’s business discussed above, the role of the Product Owner can also vary widely due to the scope and complexity of the project.

  • At one extreme, you might have a small, single-team Agile project with a very limited scope and complexity
  • At another extreme, you might have a much larger and more complex enterprise-level project with multiple teams

Naturally, that will also have a very big impact on the role of the Product Owner.

What Does a Product Owner Really Do?

So, what does a Product Owner really do? Here’s a very good article on that subject:

The Top 10 Responsibilities of a Product Owner

Additional Resources

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

What Are the Advantages and Disadvantages of Agile and Scrum?

I have often been asked “What are the advantages and disadvantages of Agile/Scrum?” so I thought it would be useful to summarize what I believe are the most important advantages and disadvantages.

Advantages and Disadvantages of Agile/Scrum

Advantages of Agile/Scrum

1. Flexibility and Adaptivity

An Agile/Scrum approach is best-suited for a relatively uncertain environment. In that kind of environment:

  • It is very difficult, if not impossible, to accurately define the requirements and design for the solution in detail prior to the start of the project
  • Flexibility and adaptivity are essential to further define and elaborate the requirements and design of the solution as the project is in progress

2. Creativity and Innovation

In the highly competitive environment that we live in today, no one wants to buy average, run-of-the-mill products.  People expect a higher level of excellence and that requires creativity and innovation.  An Agile/Scrum approach emphasizes creativity and innovation to maximize the business value of the solution. An over-emphasis on planning and control tends to stifle creativity and innovation.

3. Time-to-Market

An Agile/Scrum approach typically results in faster time-to-market due to shorter startup times. An incremental development effort will also allow early delivery of at least a portion of the solution without the entire solution to be 100% complete

4. Lower Costs

An Agile/Scrum approach can lower the costs of a project in several ways:

  • Significantly reduced overhead resulting from reducing unnecessary documentation and control requirements
  • Higher productivity of the project team
  • Reduced “feature bloat” from using an incremental development effort and prioritizing the requirements. Using that approach, it will become apparent when the project begins to reach a point of diminishing returns where the incremental value of the features no longer exceeds the incremental development cost

5. Improved Quality

In an Agile/Scrum project, quality is an integral part of the development process rather than a sequential activity.  The developers know that quality is not “someone else’s responsibility”

6. Customer Satisfaction

An Agile/Scrum approach should result in higher customer satisfaction and more effective solutions because the customer is heavily involved in providing feedback and inputs throughout the development process

7. Employee Satisfaction

An Agile/Scrum approach should also result in higher employee satisfaction from all employees that are engaged in the effort because they are much more engaged to take responsibility for their own work as part of an empowered team

8. Organizational Synergy

An Agile/Scrum approach can improve organizational synergy by breaking down organizational barriers and developing a spirit of trust and partnership around organizational goals.

Disadvantages of Agile/Scrum

1. Training and Skill Required

An Agile/Scrum approach requires a considerable amount of training and skill to implement successfully.  Many project teams don’t fully understand the need for training and skill or don’t want to put the effort into it. They attempt to do Agile/Scrum mechanically without fully understanding the principles behind it and that is typically not very effective

2. Organizational Transformation

An Agile/Scrum approach may also require some level of organizational transformation to make it successful.  It require the business users to work collaboratively with the development team in a spirit of trust and partnership.  That may require breaking down some organizational barriers that make that difficult or impossible to do

3. Scalability

It can be difficult to scale an Agile/Scrum approach to large, complex projects.  There are some models for doing that (Scrum-of-Scrums, LeSS, and SAFe are examples) but none of those are a cookbook solution that are easy to implement.

4. Integration with Project/Program Management

An Agile/Scrum approach may not be totally appropriate for projects that require a more plan-driven approach to achieve some level of predictability. However, there are many ways to create a hybrid approach that blends a traditional plan-driven approach and an Agile/Scrum approach in the right proportions to fit the situation

Overall Summary

Agile is not a “silver bullet” and it is not a solution to every problem you might have. However, if Agile is applied intelligently in the right situations, it has huge advantages and the advantages can easily outweigh the disadvantages.

Additional Resources

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

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? 

  • 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 and rather than simply putting pressure on the team to improve performance, a better approach is to understand the dynamics of how a team performs and 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.

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”

What is a Self-organizing Team

The diagram below shows a comparison of a traditional project team and 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:

  • The 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.
  • At 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 in the center would be more commonly found in a project environment.  A “self-managing team” takes responsibility for monitoring and managing work process and progress.
  • A “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:

  • It more fully utilizes the capabilities of the people on the team
  • It reduces the need for someone to directly manage all aspects of how the team operates
  • It improves 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 the best thing to do. A more proactive and more sustainable approach is to better understand how the team functions as a dynamic organism and work on the factors that drive performance.

In an Agile environment, if there is a project manager involved at all at the team level, that project manager 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 project team, a Project Manager or Team Leader typically provides direction to the team and he/she is the one who is held responsible for the performance of the team and the results that they produce.    In a traditional plan-driven project, 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.

What Is an Agile Developer? How Is the Role Different?

The role of an Agile Developer is not well-understood and many developers may have difficulty making this transition.

In a traditional plan-driven environment (aka “Waterfall”), a developer might be able to sit in his/her cube with their headset on listening to some cool tunes. And, he/she could be fairly isolated from the rest of the world and simply write code. That isn’t possible in a true Agile environment.

What is an Agile Developer?

Agile Developer Role

The role of a developer in an Agile environment is significantly broader than that and includes:

AreaAdditional Responsibility
Task/Project ManagementTaking responsibility for estimating, planning, and managing all of his/her own tasks and reporting on progress. This role is essentially what a project manager might do on a very small scale.
Effective TeamworkCollaborating closely with all the other members of the team to take shared responsibility for the overall efforts that the team has committed to. This role is also similar to what a project manager might do but rather than being done by a single person with the title of “Project Manager”, the responsibility is distributed among all members of the team.
Software QualityTaking responsibility for the quality of the software the developer produces. Instead of turning over some code to a separate and independent group for testing, the team, as a whole, takes responsibility for the quality of the work they produce. A developer may or may not do the testing himself/herself but the key point is that the quality of the code is not someone else’s responsibility.
Understanding User NeedsInteracting with users as necessary to clarify requirements. Developers will typically not be given a well-defined set of requirements. More often, the developer will get some general user stories that are intended to be a “placeholder for conversation” and the developer will be expected to interact with the Product Owner and users as necessary to better define what is needed. This is essentially equivalent to a Business Analyst role on a very small scale.

Overall Summary

The role of a developer in an Agile environment is significantly different.

  • It is much more than just “writing code.
  • Some developers may have difficulty making this transition.

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.

Agile Product Backlog Grooming “Iceberg”

An understanding of the Agile Product Backlog Grooming “Iceberg” is important.

How Far Do You Need to Plan Ahead?

A key decision is “How far do you need to plan ahead to stay ahead of the development process?”

  • A typical Agile approach of Product Backlog grooming is sometimes focused primarily on limiting the backlog to only about 2-3 sprints ahead
  • That approach involves only doing grooming only as needed to get stories ready for development

There can be a big difference in the Product Backlog Grooming depending on what level of planning the project requires:

Totally Adaptive Approach

If your project can be totally adaptive and doesn’t require a plan, you can probably live with that approach. You could completely define the Product Backlog “on the fly” as the project progresses.

More Plan-driven Approach

However, in many situations there is a need to have a plan either at the release level or project level for the project. In that situation, it’s very difficult, if not impossible, to

  • Limit the definition of the backlog too much and
  • Also be able to have some kind of plan of where the project is going

The Product Backlog Grooming “Iceberg” Approach

I like the idea of thinking of the Product Backlog as an “iceberg” as shown in the diagram below. I believe this iceberg Idea was originally created by Mike Cohn):

Product Backlot Grooming Iceberg

The “iceberg” idea is that:

  • As you pull items off of the top of the iceberg,
  • Other stories that are at lower levels in the iceberg move up to take their place

The process of developing stories and moving them up the iceberg goes on continuously to feed the development process. A Kanban process with different stages of definition for stories fits this process very well.

Product Backlog Grooming Guidelines

Here are a couple of suggested guidelines for this process:

1. You Never Want the Development Team Waiting for Stories to Go Into Development

The number of stories that are fully groomed and ready to go into development should always be far enough in advance to keep the queue from going empty. You always want to prevent developers becoming idle waiting for stories to develop.

2. Logical Stages for the Grooming Process

There are logical stages that the grooming process for the rest of the backlog goes through. Those stages should align with whatever planning objectives you need to meet. For example, if there is a need for release-level planning or project-level planning to forecast a plan and an estimated schedule, the Backlog needs to be sufficiently-defined far-enough in advance to support that objective.

3. Product Backlog Grooming Can Be a Very Time-Consuming

Product Backlog grooming can be a very time-consuming process. The time for grooming of what’s coming next needs to be built into the current sprint or it may not get done in time to keep up with the development effort.

4. Using People on the Team Efficiently

Using people on the team efficiently to do backlog grooming can be a challenge.

  • The developers who are going to take responsibility for the development of the stories need to be involved in the final stages of grooming. Prior to taking the stories into development, there should be a common understanding of the intent for the stories
  • However, it might be a significant drain on the team if the entire development team became deeply engaged in the very early stages of backlog grooming. A large portion of that effort can be done by the Product Owner and/or a Business Analyst working with the Product Owner supplemented by inputs from the development team as needed

Additional Resources

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