Use the 7 Habits to create highly effective agile teams

When Dr. Stephen R. Covey’s wrote his book, The 7 Habits of Highly Effective People®, it was used by individuals for self-improvement but the same habits could also help teams in their journeys to greater agility.

Be Proactive®

Dr. Covey wrote “The proactive approach to a mistake is to acknowledge it instantly, correct and learn from it.“. Just as individuals should blame everything on others, agile teams need to own the mistakes which arise from their behavior. Empowerment by senior leadership to self-organize increases a team’s sense of autonomy but with this comes the responsibility for the team’s actions. Covey’s quote also highlights the importance of transparency and ongoing learning. Whenever there is a setback, someone on the team should have the perspective to ask “What have we learned from this?”.

Begin with the End in mind®

This habit underscores the importance of knowing what we are building towards. Without that shared understanding in a project or product vision, it is easy for a team to get distracted by quick wins or by new backlog items which provide short term gratification but won’t deliver the overall value expected by stakeholders. Whether it is a vision statement, a vision board or a formal project charter, the time spent in crafting it and reviewing it regularly will give team members the confidence needed to challenge misaligned or low value work items.

Put First Things First®

There will always be more work to be done than a team’s ability to complete it. This habit reminds Product Owners and other team members to focus on what’s most important at that time which means saying “no” to lower value work. It also means that teams need to be aware of their own capacity and to not over extend themselves by working overtime or by accepting an unhealthy level of multitasking.

Think Win-Win®

When working in large organizations, there can be a natural tendency for teams to focus on their own objectives, optimizing their work but potentially sub-optimizing the whole. When they have to rely on other delivery or support teams, it can easily become a finger-pointing “us and them” situation. Success in an enterprise context requires agile teams to take a system-level view and work effectively with others to ensure organizational success. This also aligns well with the Disciplined Agile principle of Enterprise awareness which encourages teams to consider the needs of the overall organization and not just their own team’s.

Seek First to Understand, Then to Be Understood®

This aligns well with two key ingredients of a high performing teams, effective communications and psychological safety. By missing what others within or outside of the team are saying because of our own assumptions, biases and agendas, we can erode trust and collaboration. This habit can also be a caution for those who support agile teams to truly understand why something ight be happening before providing guidance or solutions.

Synergize®

The word “synergy” comes from the Greek words “Sun” and “Ergon” meaning to work together. Agile teams need to collaborate which is making the whole greater than the sum of the parts, but this habit also encourages exploiting diversity within our teams rather than striving for conformity. Pair programming and other types of non-solo work are opportunities to put this habit into practice.

Sharpen the Saw®

This habit is about renewal and investing in one self. At a team level, we embrace it by looking out for one another, working a sustainable pace, taking the time to learn and grow as a team. Ceremonies like retrospectives are explicit opportunities to do this, but this also happens through “in the moment” support and recognition for each other.

“If we keep doing what we’re doing, we’re going to keep getting what we’re getting.” – Dr. Stephen R. Covey

 

 

 

Small is beautiful for product backlog items

One of the reasons for having small work items at the top of a product backlog is so the team is able to complete them within a short amount of time. This benefit applies regardless of whether your team is using an iteration-based delivery approach or has adopted a lean continuous flow-based approach.

But what are some of the other benefits of having small work items?

• While size does not always positively correlate with complexity, usually the smaller a work item, the easier it should be for team members to come to a shared understanding with the work item originator as to what is desired and how they will deliver it.
• Smaller work items often require less documentation than larger ones.
• It might be less challenging for team members who are new to test driven development to apply this practice for small work items.
• If the team is using an iteration-based approach, the probability of getting a higher percentage of completed work items is greater if they forecast a larger number of small work items in an iteration as opposed to a smaller number of large ones.
• The amount of re-work or wasted effort involved if a particular work item does not meet general or quality requirements should be lower.
• If most work items for a release are small “enough”, the team has the ability to skip the use of story points or some other relative sizing method in favor of just tracking how many work items they can complete within a given amount of time.
• Finally, splitting a large work item into small pieces provides greater feature choice to product owners when prioritizing the backlog.

But before slicing our work items too small, we need to remember that size is just one of the criteria provided by Bill Wake when he wrote about the INVEST acronym in his book Extreme Programming Explored for assessing how good a story is. A work item which is too small might not be sufficient independent or provide value to a stakeholder.

But keeping these caveats in mind, good things come in small packages.

The art and science of backlog prioritization

A key responsibility of Product Owners is ensuring that the order of work items in a backlog best achieves the goals and vision for the product. Unlike project portfolios where selection or prioritization decisions are often made by a governance committee, with a product backlog the responsibility for the business success or failure of the product rests on the Product Owner’s shoulders.

This activity is both science and art.

Multiple competing factors need to be considered and balanced including:

• Business value
• Alignment with the original vision
• Dependencies
• Constraints
• Risk reduction

Evaluating cost of delay or Weighted Shortest Job First can inject consistency and objectivity into activity but also takes learning and effort. If used, such scoring approaches should be used to guide decision making rather than replace it.

The Product Owner needs to collaborate well with key stakeholders to ensure that releases won’t just satisfy his or her needs. This collaboration requires willingness on the part of the Product Owner to push back the release of certain “hot” features if that will result in a better product overall.

When working with a new team, the Product Owner needs to actively listen during backlog refinement discussions with team members as some of them might lack the courage to openly challenge a short-sighted decision. One way to help overcome such growing pains is to actively ask the team as work items are being ranked whether they see any flaws with the order or whether they are aware of any work item which might need to be tackled sooner. Prioritization might be a good item to consider during retrospectives to ensure that the process is regularly inspected and adapted.

The Product Owner will naturally want to maximize business value realization while solution owners will want to tackle solution uncertainties or address scalability or flexibility early on. Healthy prioritization should feel like a tug-of-war between the representatives for each influencing factor.

A good Product Owner should be ego-less about the prioritization activity as their goal is not to demonstrate omniscience about the sequencing of the product’s development but rather to release the best product possible.