Kanban versus Scrum – Which Agile Approach Do You Prefer?

I recently saw an online question that asked the question “Which Agile approach do you prefer – Kanban or Scrum?”. I decided that it was worth a blog post because I’ve seen this question several times. There are a couple of things wrong with this question:

  • It implies that Kanban and Scrum are interchangeable and
  • That the choice of one or the other is only a matter of personal preference

I don’t believe that either of those is correct:

  • Kanban and Scrum serve very different purposes
  • The choice of which one you choose should depend on what problem you’re trying to solve and objectively fitting the best approach to the nature of the problem. Personal preference or bias should not be a factor in that selection

How Are Kanban and Scrum Different?

Kanban and Scrum are very different kinds of processes and are intended for very different purposes.

Detailed Comparison

The table below shows a comparison of how Kanban and Scrum are different:

Primary DeliverablesIntegrated SolutionsCompleted Individual Work Items
Nature of the Work To Be DoneThe work may have a high level of uncertainty and require considerable interaction with the customer to resolve the uncertainty as the project is in progressThe individual work items may be relatively well-defined and may not require much interaction with the customer to clarify requirements
PlanningMulti-level Planning
  • Sprint-level
  • Release-level
  • Project-level
No Significant Planning Required
  • Scrum Master
  • Product Owner
  • Team
No Defined Roles
Time-boxingTime-boxed Sprints
Work is organized into fixed-length sprints
Each work item is handled individually – Kanban has no concept of grouping work items into a sprint
WorkflowPush-Pull Model
  • Work to be done is planned and prioritized to support a product road map (Push Model)
  • Within a sprint, work is started as soon as capacity is available to work on it (Pull Model)
Continuous Flow Model (Pull Model)

Work is started as soon as capacity is available to work on it
  • Sprint Planning
  • Sprint Review
  • Sprint Retrospective
  • Daily Stand-ups
No Meetings
Level of Integration
  • Work can be organized into a hierarchical structure to facilitate integration
  • Sprints and releases can be defined to support Product Road Map deliverables
  • Work is organized as a single stream of work to be done with no hierarchy
  • Each item of work is treated independently and there is no mechanism for developing an integrated solution
Process Definition and Continuous Improvement
  • The process is intended to evolve as the project is in progress
  • Strong emphasis on continuous improvement with Sprint Retrospectives
  • The process may be well-defined and repetitive
  • No formal mechanism for continuous improvement

    General Comparison

    It should be apparent that Kanban is very streamlined and designed for efficiency but it is also very limited in what it is intended for:

    • Kanban has practically none of the overhead (planning, meetings, roles, etc.) of Scrum
    • However, it is intended for producing completed individual work items that do not require an overall integrated solution

    If you asked a developer which one they prefer, their choice might be obvious because developers like to write code without being burdened with too much overhead. However, that “overhead” is not unnecessary and can be essential in an environment where the goal is to produce a well-integrated solution that meets some overall business objective or solves a business problem.

    Overall Summary

    Kanban and Scrum are designed and optimized for very different purposes:

    • Kanban is designed for a continuous flow kind of process that may be somewhat repetitive. An example would be a customer service response queue or a queue of requests for business reports, The overall goal of a Kanban process is to produce as many completed individual work items as quickly and efficiently as possible
    • Scrum is intended for project work where there is an overall goal of producing some kind of integrated solution

    I’ve seen some people who want to abandon Scrum and move to Kanban because they don’t like some of the overhead that is built into Scrum; however, that “overhead” serves a purpose, provides value, and can be essential for projects that need to produce an integrated solution.

    Additional Resources

    This is only a very brief, high-level overview of differences between Kanban and 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 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 Scrum Product Owner in Agile?

    I recently participated in an online discussion on the question of “What are the Critical Skills of a Scrum 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 a Scrum Product Owner?

    What Does the Scrum Guide Say?

    The Scrum Guide defines the role of the Scrum 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”.

    Scrum Product Owner 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 Scrum 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 Scrum 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.

    Improving Team Performance – How Do You Improve Team Performance in a Project Environment?

    A number of people have asked questions related to improving team performance. It takes some skill to do that – “How do you improve team performance in a project? 

    Improve Team Performance

    Improving Team Performance

    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

    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:

    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

    Comparison of Agile and Plan-driven Approaches

    There can be a big difference between an Agile environment and a traditional plan-driven environment.

    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

    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

    Overall Summary

    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.

    Additional Resources

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

    Managing Team 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 would probably not be a very high performance team
    • In this particular situation, the conflict was occurring over estimation. In that area, you certainly want to bring out opposing views and attempt to resolve them. You don’t want to suppress conflicting opinions
    Managing Team 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. An important value is to listen to the views of others and treat them with respect and consideration even if you disagree with them.

    • Each person on the team also needs to put their own ego and emotions aside. 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. They may also try to prove that they’re right and others are wrong. That behavior can be very counter-productive
    • A good way to minimize that kind of behavior is to have a clearly-defined set of values that everyone on the team agrees to

    Tuckman’s Stages of Group Development

    “Tuckman’s Stages of Group Development” is an excellent model for understanding team performance. The model consists of four stages that teams go through in the journey to becoming a high performance team. Here’s a brief summary.

    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.
    • However, individuals are also gathering information and impressions about each other an
    • d 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 tIndent1he 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, while 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.”

    Important Points to Recognize

    There are several important things to recognize about this model:

    Jumping Past Stages

    You can’t just jump past the “Storming” stage and go right to the “Performing” stage

    • The only way that might happen is 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

    Sequential Progression

    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.

    Moving to the Norming Stage

    The natural progression for a team that is in conflict is to move to the “norming” stage:

    • 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 that 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. Just learning the basic practices is only the beginning.

    Levels of Mastery in Agile

    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. They think that their development is complete when they have mastered this level of learning
    • People who get stuck in this level of learning can become fairly ritualistic or dogmatic. They may 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. They understand why it makes sense rather than just doing it mechanically.

    • 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
    • People at this level are also able to see Agile in a much broader context.
      • They see beyond the basic team-level Agile implementation and
      • They 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 go beyond only understanding 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.
      • Apply the principles and practices to much more demanding and difficult situations. They are also able to do it 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. I have previously discussed that in this article:

    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”? Many people in both the Agile and traditional plan-driven project management communities are at a very basic level of mastery of those two disciplines. They see them as firmly-defined processes to be followed. 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:

    • See these two areas as much more complementary rather than competitive
    • Recognize the reasons why one set of principles and practices makes sense in one situation and not another
    • Be able to easily blend the two sets of principles and practices together as needed to fit a given situation

    Overall Summary

    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. 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 styles of cooking

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

    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:


    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:

    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:


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

    Functional Decomposition – How Does It Apply to Agile? Why Is It Important?

    What is Agile functional decomposition? (and why is it important?) Investopedia defines “functional decomposition” as follows:

    “A method of business analysis that dissects a complex business process to show its individual elements. Functional decomposition facilitates the understanding and management of large and/or complex processes and can be used to help solve problems:

    Functional Decomposition in Agile
    • Basically, functional decomposition takes something complicated and simplifies it
    • The individual elements of the process and their hierarchical relationship to each other are commonly displayed in a diagram called a functional decomposition diagram.”

    How Is It Relevant to Agile?

    Why is that relevant to Agile? A major goal of Agile is to maximize the business value that a project produces.

    • On small, simple projects, you might be able to easily discover what the business value is based on direct face-to-face discussion with the Product Owner and individual stakeholders
    • On large enterprise-level projects, that may not be so easy to do:
      • An example is that I was involved in a large project with about 500 user stories, and
      • We had to do some prioritization to move things out to a future release
      • Doing that on a project of that size without understanding the relationships among the stories can be very difficult if they’re not organized into some kind of functional hierarchy

    Agile Functional Decomposition – Keeping Stories Well-Organized

    Using functional decomposition to organize stories into epics and themes:

    • Makes it possible to keep all of the stories well-aligned with producing the higher-level business value that the project is intended to produce, and
    • It makes it a lot easier to effectively manage the Product Backlog

    It also provides a capability for trace-ability

    • You can look at the top-level functionality and then look down into the functional decomposition to verify that the lower-level functionality is really complete and
    • That the lower-level functionality is sufficient to support the higher-level functionality.

    Overall Summary

    Functional decomposition has been around for years but many people don’t think it is relevant to Agile projects. It’s one of those traditional, plan-driven practices that people seem to assume is now obsolete and no longer relevant with Agile. I don’t believe that is the case.

    • You don’t have to completely throw away all the traditional plan-driven practices you may have learned in order to practice Agile and
    • Some of those practices become especially important as you begin to try to scale Agile to an enterprise level
    • Functional Decomposition is an example

    Additional Resources

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