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 Project Manager Job Description

I was recently asked by a company I am working with to create an Agile Project Manager job description. Here’s what I came up with:

Agile Project Manager Job Description

Introduction

The Agile Project Manager (APM) is responsible for planning, leading, organizing, and motivating Agile project teams. The goals are to:

  • Achieve a high level of performance and quality, and
  • Deliver agile projects that provide exceptional business value to users

The APM may be responsible for managing several concurrent high visibility projects using agile methods in a fast-paced environment that may cross multiple business divisions.

Potential Agile Project Manager Roles

The APM may play a number of different roles in actual practice:

Enterprise-level Role

At an enterprise level, potential roles include:

  • Leading and managing large, complex enterprise-level projects
  • The projects may consist of multiple Agile teams and require integration with other activities outside the scope of the Agile teams

Team-level Role

At a team level, potential roles include:

  • Playing a consultative role to put in place the appropriate people, process, and tools, to improve team efficiency and effectiveness
  • Coaching members of the team as needed to optimize the efficiency of the project team

Hybrid Agile Role

In situations that require a hybrid Agile approach, potential roles include:

  • Using good judgment and skill to develop a project management approach that is suitable for planning and managing the effort
  • Achieve the project goals within designated project constraints

In performing these roles, the APM will be expected to use a high level of knowledge and experience in blending traditional project management principles and practices with an Agile development approach in the right proportions to fit large, complex, mission-critical, enterprise-level projects and with the appropriate level of planning and provide the right balance of agility and predictability.

Agile Project Management Job Description

Essential Job Requirements

AreaRequirement
Project Planning and ManagementDefine project scope and schedule while focusing on regular and timely delivery of value; organize and lead project status and working meetings; prepare and distribute progress reports; manage risks and issues; correct deviations from plans; and perform delivery planning for assigned projects
Team ManagementAssist in team development while holding teams accountable for their commitments, removing roadblocks to their work; leveraging organizational resources to improve capacity for project work; and mentoring and developing team members
Product Owner SupportSupport the Product Owner in managing customer expectations for project deliverables, managing stakeholder communications, and helping to implement an effective system of project governance
Process Management and ImprovementDefine and manage a well-defined project management process and champion ongoing process improvement initiatives to implement best practices for Agile Project Management
Team BuildingPromote empowerment of the team, ensure that each team member is fully engaged in the project and making a meaningful contribution, and encourage a sustainable pace with high-levels of quality for the team

Qualifications

  • Solid understanding of software development life cycle models as well as expert knowledge of both Agile and traditional project management principles and practices and the ability to blend them together in the right proportions to fit a project and business environment
  • A proven track record of successfully implementing software or web development projects using Agile methodologies including 8+ years of experience as a Project Manager managing large, complex projects in a high-tech development environment with multi-function teams. PMP preferred
  • Prior experience with SCRUM/Agile methodologies with enterprise-level application development projects. PMI-ACP, CSM, or equivalent preferred
  • Experience overseeing multi-function project teams with at least 10-15 team members including Developers, Business Analysts, and QA Personnel
  • Balanced business/technical background:
    • Sufficient level of technical background to provide highly-credible leadership to development teams and to be able to accurately and objectively evaluate complex project risks and issues
    • Ability to provide leadership to business analysts and collaborate with customers and develop strategies and solutions of high business value

Skills Required

  • BA or BS or equivalent experience is required; MA or MS is a plus
  • Very effective interpersonal skills including mentoring, coaching, collaborating, and team building
  • Strong analytical, planning, and organizational skills with an ability to manage competing demands
  • In-depth knowledge and understanding of business needs with the ability to establish/maintain high level of customer trust and confidence
  • Proven ability to lead software development projects and ensure objectives, goals, and commitments are met
  • Solid understanding of and demonstrated experience in using appropriate tools:
    • Agile Project Management tools such as Jira/Greenhopper, Rally, VersionOne or equivalent
    • Microsoft Project, Visio, and all Office Tools
  • Excellent oral and written communications skills and experience interacting with both business and IT individuals at all levels including the executive level
  • Creative approach to problem-solving with the ability to focus on details while maintaining the “big picture” view

Additional Resources

This is a new and rapidly evolving field. For more insight into the role of an Agile Project Manager, check out the online training curriculum below:

Agile Project Management Training Curriculum

Developing an Agile Company Culture

Developing an Agile company culture can be a major obstacle to successfully implementing an Agile development approach; however, it doesn’t have to be that difficult.

  • Some people make the mistake of thinking that you have to change the entire culture of a company in order to adopt an Agile development approach
  • I don’t believe that is necessarily the case. A company’s culture should be designed around whatever business they are in and
  • That may or may not be well-aligned with implementing an Agile development approach

See my previous blog post on “Agile and Corporate Culture” for more discussion on this.

Agile Company Culture
Organizational Culture Word Cloud on White Background

Impact of Agile Company Culture

The nature of the company’s business can have a big impact on the implementation of Agile. Agile works best:

  • In companies that are in the business of developing products or
  • Where software product development is directly related to their primary business

In other companies where the relationship is more indirect, it can be much more difficult to implement an Agile development approach. In those companies, an Agile development approach may not be as well-aligned with the company’s primary business objectives. Check out this article for more on that:

What Are the Most Important Factors?

Here are a few of what I think are the most important factors in developing a corporate culture that is consistent with Agile:

1. Transparency and Trust

In many large corporations,

  • There is somewhat of a contractual relationship between the business users and the people who deliver Information Technology solutions.
  • The business users may be under intense pressure to reduce costs and want to get firm commitments from the solution providers on the costs and schedules of projects

That is one of the major factors that has can be a big obstacle to implementing an Agile development approach. Sometimes it even creates somewhat of an adversarial relationship between the two organizations. The key to getting past that obstacle is:

  • Companies need to realize that this is not an “all-or-nothing” proposition to totally give up all control of projects to become Agile
  • There are many ways to blend traditional project management principles and practices with Agile principles and practices to develop the right balance of agility and control

See my blog post on a Hybrid Agile framework here:

Developing a spirit of trust, partnership, and collaboration between the two organizations can require some strong executive-level leadership to break down some of the traditional barriers that exist inside of companies. The strongest driving force for making that happen is that it requires a more collaborative partnership approach to focus on rapid innovation.

2. Focus on Continuous Improvement and Innovation

A focus on process improvement and continuous innovation is certainly not new to Agile:

  • It has been around a long time and many companies have successfully adopted continuous improvement approaches based on Six Sigma and other process improvement methodologies
  • A similar thing is happening today with Agile. Companies who take the time and effort to understand Agile at a deeper level and adapt it to their business are probably more likely to do it successfully

3. Respect for People and Self-organizing Teams

This principle is also not new to Agile. It was a key element of Dr. Deming’s principles that form the basis of the Total Quality Management (TQM) approach. I can remember a strong focus on this when I worked at Motorola in the early 1990’s. It’s another thing like Six Sigma that some companies forget about when the pressure gets intense to deliver business results:

  • They sometimes take a superficial, brute-force approach to try to drive business results rather than
  • Taking a systems-thinking approach to understanding the factors that drive business results and the role that people play in achieving those goals

Overall Summary

If you only focus on those three things about a company’s culture, I think you will have a pretty good foundation for implementing an Agile development approach. Those three things are somewhat common to all companies regardless of what business they’re in.

Additional Resources

Here’s a related article on “Agile and Corporate Culture – How Do You Make it Work?”:

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

Managed Agile Development Framework – A Hybrid Approach

I’ve seen many people ask a question like “should I use Agile or Waterfall for a project? That excludes the possibility that there is a hybrid approach that provides the benefits of both approaches. The Managed Agile Development Framework is an example of a hybrid approach that is very easy to implement

Background

A few years ago, I was responsible for managing a large government project.

  • The project required meeting some defined cost and schedule milestones
  • However, the customer wanted to take an Agile approach to defining the requirements.

In response to that project, I developed an approach which I call “The Managed Agile Development” framework that would satisfy those two seemingly inconsistent goals. The framework consisted of two levels:

LayerDescription
Macro LevelThe “Macro” level was the outer envelope of the project. It was focused primarily on managing overall contractual requirements
Micro LevelWithin that “macro level” envelope, we were still able to implement a fairly flexible Agile development approach at the “micro-level”
Managed Agile Development Framework

How Does It Work?

There are two layers in the framework as shown in the diagram above. The “Macro” layer is plan-driven; but it can be as “thick” or “thin” as you want it to be. The “Micro” layer can be any Agile development approach such as Scrum.

  • The macro-level framework is a plan-driven approach. It is designed to provide a sufficient level of control and predictability for the overall project. It defines the outer envelope (scope and high-level requirements) that the project operates within
  • Within that outer envelope, the micro-level framework utilizes a more flexible and iterative approach based on an Agile/Scrum approach. It is designed to be adaptive to user needs

Trade-offs to Consider

Naturally, there are tradeoffs between

  • The level of agility and flexibility to adapt to change at the “micro-level” and
  • The level of predictability and control at the “macro-level”.

It is important that both the client or business sponsor and the development team need to agree on those trade-offs. The framework provides a mechanism for making those trade-offs by making the “macro-level” as “thick” or “thin” as you want to fit a given situation.

Increasing Predictability and Control

Increasing the level of predictability and control requires:

  • Beefing up the macro-level,
  • Providing more detailed requirements at that level, and
  • Implementing at least a limited amount of change control

Increasing Agility

To increase the level of agility:

  • You can simply eliminate the macro-level altogether or limit it to only very high-level requirements
  • Other elements of the framework can be easily customized or eliminated depending on the scope and complexity of the project and other factors

Change Control

A question that often comes up is “How do you handle change control?”. The answer to that question is that:

  • You have to design enough slack into the milestones at the “macro” level to allow detailed elaboration of requirements to take place in the “micro” level.
  • However, when there is a significant enough change in the “micro” level that would impact achievement of the requirements in the “macro” level, that should trigger a change to the “macro” level milestones.

General Approach for Agile Contracts

This general approach can be used on almost any project. Check out this article for more detail on Agile Contracts:

Agile Contracts

Additional Resources

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

Agile Maturity and the Martial Arts – How Are They Similar?

There’s a definite relationship of Agile levels of maturity and the martial arts like Karate.

Agile Maturity and the Martial Arts
Young couple doing Martial Arts exercise outdoors

What Is the Similarity of Agile and the Martial Arts?

In theory, there should be a lot of similarity:

AreaSimilarity
TechniquesThere are a wide range of Martial Arts techniques that can be applied in different situations
Finesse and SkillMost Martial Arts require finesse and skill; it’s not just a brute force approach
Levels of SkillThere 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.

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

For example:

  • 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. Those two areas are often seen as competit1ive rather than complementary with each other.

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”

“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

The second stage of the process is called “Ha”.

  • “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 he/she has learned. The student thus comes to a deeper understanding of the art than pure repetitive practice can allow

“Ri”

“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. He/she tests 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)

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.

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

  • Many people are still struggling with the “Shu” level to understand the mechanics of how to do Scrum. They have a long way to go to really get to higher levels of mastery
  • Many people do not realize how big this gap is
  • Many people seem to think that all there is to know is the mechanics of how to do Scrum at the team level

I think we have hardly scratched the surface of the knowledge that is needed 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

Additional Resources

For more on levels of mastery in Agile, check out this article:

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

Using an Adaptive Leadership Style in Agile

Adaptive Leadership in Agile

My answer to that is:

What is the importance of adaptive leadership in Agile? I’ve been a Project Manager for many years and, over the years, I’ve gone through a lot of job interviews, particularly as a consultant where you might change roles every 3-6 months. One of the questions I’ve been asked in interviews is “What is your leadership style?”.

  • I use an “adaptive leadership” approach. That is, I think that’s there’s not just one leadership style that works all the time
  • That is particularly true in an Agile environment
  • You have to adopt an adaptive leadership style in Agile that is appropriate for the situation.

I think that’s there’s not just one leadership style that works all the time and that is particularly true in an Agile environment. You have to adopt an adaptive leadership style in Agile that is appropriate for the situation.

Adaptive Leadership in Agile
Leadership Business Management Teamwork Motivation Skills concept on the hexagons and transparent honeycomb structure presentation screen. Man pressing button on display with word in modern office

How does Adaptive Leadership apply to Agile Project Management?

  • There is a popular stereotype in the Agile community that all project managers are only capable of operating in a “Command and Control” leadership style. I’m sure that is an exaggeration, but it is true that many project managers have a tendency to assume a somewhat directive leadership style
  • For years, that has been an essential characteristic of many project managers – you can’t just sit on the sidelines and let a project run its course without some kind of direction and leadership
  • Agile changes that paradigm dramatically by emphasizing self-organization and empowerment of the team and positions the Scrum Master in the role of a “Servant Leader” to support the team rather than leading and directing the team

What’s the Impact of Adaptive Leadership on Project Managers?

So, where does that leave the project manager? What value does he/she provide to an Agile team? I think the appropriate answer to those questions is that “it depends”.

  • A lot of people will say that a project manager can’t possibly play the role of a Scrum Master because the roles are so different. I don’t necessarily agree with that perspective…that perspective is based largely on the stereotype that all project managers are only capable of operating in “command and control” mode
  • I believe a good project manager has learned over the years to develop an adaptive leadership approach that’s appropriate for the situation and I think that’s very appropriate in an Agile environment

Overall Summary

There is an idealistic Agile view that all Agile teams are totally self-organizing, completely empowered, and require little or no direction or leadership.

  • The team, as a whole, should function on its own without much direction at all – that’s true to some extent, but a more pragmatic view is that all teams aren’t necessarily at that level of maturity and some leadership is needed to help them get to that point.
  • “Adaptive leadership” is an important skill in this kind of environment…a good Project Manager or Scrum Master should be capable of providing a sufficient level of leadership to get the team to a level of self-sufficiency and progressively back out as the team reaches that level

“Adaptive Leadership” or learning to adapt your leadership style to the situation is a very important characteristic for project managers to be successful in an Agile environment.

Additional Resources

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

Agile Estimation – What’s the Right Level? Is It Important?

I participated in a discussion recently on the subject of estimation in an Agile Project.

  • The individual who started the discussion indicated that his team was not very good at estimating.
  • He asked whether it was important for them to become more proficient in estimating the level of effort required.
Agile Estimation

Why Is Agile Estimation Important?

Estimation can be very important and is a skill that is often neglected in Agile development projects. There are different levels of estimation in an Agile project. Here’s why I think each of those levels is important:

Agile Estimation in Project-level Planning

At a project level, there is a need for some kind of planning to estimate the scope of the effort. That can be essential to set expectations of how long it is going to take to finish the project:

  • Very few projects are given a “blank check” for a project without some expectations about the cost and schedule of the project
  • In that situation, it’s irresponsible to not set and manage those expectations

I have seen Agile projects where the project has gone on-and-on for an extended period of time without a plan for when it would finish:

  • In one case, a project was so large that it couldn’t possibly be done by a single Agile team, and
  • That wasn’t discovered until well into the project
  • At that point, the whole project had to be re-planned and estimated

Agile Estimation in Determining Business Value

At a more tactical level within a project, there is an ongoing need for the Product Owner to evaluate the value produced by stories:

  • The Product Owner needs to compare the value of the stories against the level of effort required to develop that capability
  • He/she needs use that information to prioritize he work properly to maximize the value that the project produces
  • If the Product Owner only knows the business value of the work without an idea of the level of effort associated with it, it is very difficult to make a good decision

Agile Estimation in Sprint Planning

There is also a need to accurately size the level of effort that can be taken into a sprint so that it can be completed successfully:

  • A team can become demoralized if they never finish a sprint successfully. And, that can happen if they weren’t able to accurately estimate the level of effort required
  • Estimating the work to be done also allows the team to better allocate the work among people on the team to do it more efficiently

What’s the Right Level of Estimation?

The level of estimation can range from

  • Very rough, high-level estimates to
  • More accurate, detailed estimates

The right approach for estimation in an Agile project will depend on several factors:

FactorImpact
Level of UncertaintyThe level of uncertainty in the project is the most important factor. Naturally, the accuracy of any estimate must be proportional to the level of uncertainty in the requirements
Customer ExpectationsThe customer’s need for predictability is important. However, that obviously needs to be balanced against the level of uncertainty so that the customer expectations are properly set
Contractual RequirementsAny contractual requirements will also have a big impact. The nature of a contract might range from a very collaborative partnership to a more typical “arms-length” contract.

Overall Summary

There is no question that estimation is a difficult thing to do in an Agile environment and, the importance of doing estimation is not well-understood. For those reasons, developers sometimes resist making estimates.

  • The important thing is to define the approach for doing estimation in the context of the project you’re operating in
  • Some projects may have very uncertain requirements and may be very difficult to estimate
  • That may be OK for some projects but that doesn’t have to be the norm for all Agile projects

It is not an all-or-nothing decision between:

  • A totally adaptive with no plan or estimates at all and
  • A rigidly plan-driven approach with highly detailed estimates

There are plenty of alternatives between those two extremes. What is most important is that the project team and the customer have a common understanding of:

  • The level of uncertainty in any estimates and
  • How that uncertainty will be managed.

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.

People, Process, and Tools in an Agile Project – How to Fix a Broken Project

The inter-relationship of people, process, and tools in an Agile project is important to understand. It is particularly important when you try to fix a broken project.

People Process and Tools

Typical Traditional Project Management Approach

On several occasions, I’ve been brought in to rescue a project that was in trouble. In many cases, there is an expectation that, as a Project Manager,

  • I will re-plan the project,
  • Get it on the right track, and
  • Perhaps also”ram-rod” the effort to get it moving through to completion if necessary.

That’s the typical expectation of what a traditional Project Manager might do. If a project fails, it is the Project Manager who is typically held responsible.

People Process and Tools in an Agile Project

I think the Agile environment is different.

  • I’ve certainly seen a need to re-plan projects and get them on the right track and it often takes some strong leadership skills to do that; however
  • A more critical role in many cases in an Agile project is developing the right people, process, and tools to make the Agile project teams more effective and self-sufficient.

The irony is that if you do that successfully, you might practically eliminate the need for a Project Manager and put yourself out of a job, but that’s the right thing to do. I think that’s a key difference in an Agile project. In a traditional project, the role of the Project Manager might normally be expected to continue all the way to the end in order to push the project on to completion.

I’ve seen several Agile projects that got into trouble because they didn’t have an adequate amount of upfront planning. And, as a result the project didn’t have the right people, process, and tools to be successful. This happens frequently in larger, enterprise-level projects because many people don’t understand or appreciate what it takes to scale an Agile development approach to an enterprise level. Here are a few examples of typical problem areas I’ve seen:

People

The first and most important area is related to “people”:

  • It takes a lot more skill to organize a large, enterprise-level Agile project
  • The number and different types of people involved are typically a lot more numerous and complex
  • It can be a real challenge to figure out how to organize all of the people (both inside and outside of the project teams) to get the effort done successfully

Here’s an example:

  • I’ve seen projects get in trouble because there was no Project Governance model defined to provide overall direction to the project
  • In many cases at an enterprise level, its not as simple as having a single Product Owner to provide direction. And, without a plan for how all of the stakeholders and decision-makers will participate in the project as it moves forward, it’s very easy for a project to go off-course and get in trouble

Process

The second major area is process:

  • In many cases, there’s also not a clear understanding of what it takes to scale an Agile process like Scrum to enterprise levels.
  • There are typically layers of management needed above the team level and it has to be well-integrated with the company’s primary management structure.
  • It may not be as simple as layering a Scrum-of-Scrums approach on top of a couple of Agile teams.
  • There is also often a need to define a hybrid process that blends together:
    • Some amount of traditional plan-driven project management at a higher level with
    • An Agile development approach like Scrum at the team level.

Tools

The third area that it often important in effectively organizing large, enterprise-level Agile projects is tools.

  • In large, complex enterprise-level projects, tools also can be a major problem area
  • The tools that people many times use for small, simple Agile projects, just don’t necessarily scale well to larger, more complex, enterprise-level projects

For example,

  • People might use physical story cards and white-boards for tracking progress of small, single-team Agile projects but
  • Those methods start to fall short very rapidly as you to try to scale the effort to larger, enterprise-level projects with multiple teams that need to coordinate with each other and may not be collocated
  • Managing that type of situation typically requires more sophisticated, on-line electronic tools

People Process and Tools – Overall Summary

I’ve been in situations where clients might not have the patience to address some of these more systemic issues involving people, process, and tools:

  • In some cases, there might be an expectation that the Project Manager will just somehow “ram-rod” the project to get it moving and get it back on the right track but
  • Taking that kind of approach and ignoring the more systemic factors associated with people, process, and tools is not likely to be very successful,
  • That’s equivalent to just putting pressure on a broken process to make it work better. A more effective approach in most cases is to fix the broken process.

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.