Is Your Agile Project Healthy?

Experienced agile coaches and practitioners develop a sixth-sense. They can quickly assess the health of an agile project or team just as doctors do with their patients. In 2013, Mike Cohn coined the term scrum smells  [1]to describe the signs that a scrum team is in trouble. 

In my agile training and consulting practice, I have witnessed similar symptoms when an organization is struggling with its agile adoption. Like a competent physician, an agile coach can quickly diagnose problems by listening, observing, and asking probing questions. It is easy to spot these ills, but the treatment is frequently more complicated. The underlying issues are often deeply rooted. 

Scrum masters, agile coaches, and even team members can improve their teams' performance by spotting these warning signs early and taking corrective actions. Just like the onset of a disease, it's better to seek treatment early. Here are some of the common ills that I have encountered:

When I hear, "We have been agile for years, but [2]," I prepare myself to open a Pandora's Box of poor practices and agile anti-patterns.

To diagnose the root cause, I start by asking a range probing questions to understand the margins of the good and not so good practices; such as:

• What methodology or set of practices are you using?If the answer is convincingly Scrum or Kanban, they are probably following a process. If the answer is "a mix" or "sort of…", then I start collecting additional information.
• What are the team dynamics? Since agile is built on collaborative teams, I start looking for signs such as poor cooperation, collaboration, and communication, disengagement, organizational silos, etc. 
• Who is the Scrum Master or Product Owner? The Scrum Master and Product Owner play pivotal roles. Teams with inexperienced scrum masters or "proxy" product owners, tend to have problems. 
• · What are the team's performance metrics, and how are they being used? Agile is based on Systems Thinking [3]. We want to measure and adjust our team's performance based on data. 

Once I understand the landscape, I focus my attention on the most urgent needs, which are often the team dynamics and culture.

Outsourcing is a good option for organizations where technology is not a core or strategic competency. Typically, technology contracts are fixed-scope/fixed-price and assume an adversarial buyer-supplier relationship. While these contracts are intended to protect the buyer, they do not augur well in an agile environment. They conflict with the core values of collaboration over contract negotiation  [4]and welcoming changing requirements [5]. 

When clients tell me, they have outsourced their development, I begin to ask questions:

• How are things going?
• What is the contract type? 
• How is work prioritized? How is change managed?
• How is the vendor relationship? 

Successful outsourced agile projects are built on collaboration and trust. Watch out for contract terms and engagement practices, such as:

• Fixed-scope projects and burdensome change management processes;
• Arrangements where communications between the product owner and the team are filtered through an intermediary; Unnecessary or burdensome documentation and approvals; and
• Contract performance terms that assume an adversarial relationship.

Successful arrangements can be built on the foundation of a cooperative buyer-vendor relationship. Agreements premised on an on-going and long-term affiliation foster this environment. Capacity-based or cost-plus arrangements tend to work better than fixed-price.

Capacity-based models are similar to contingency fees common in the legal profession. The buyer agrees to "purchase" a specified amount of development capacity which can be measured in terms of features, story points, or time. Capacity can be increased and decreased with reasonable notification periods. 

If the contract has performance standards, ensure they are incentivizing desired behaviors. Story points can be inflated. Poorly coded features may be technically complete, but not acceptable. 

On one project, the vendor committed to delivering a certain number of features each sprint. As the vendor fell behind, quality declined. They were technically compliant with the contract terms, but not with the intent. We had to revise the agreement and reset expectations. 

The Product Owner [6] is one of the most important and underappreciated scrum roles. A good product owner should have vision, deep operational experience, and political skills. Often a proxy is designated because people with these skills are hard to find, or unavailable. 

Proxy product owners are usually a poor stand-in. They may be a junior resource that lacks the strategic perspective or a technical resource who does not understand the business and its customers. Rarely does a proxy have the political skills to manage the stakeholder community effectively. Teams with proxies often struggle to develop features that meet the strategic objectives consistently. 

I recommend that agile teams have a product owner who has an understanding of the business needs, along with strong influencing skills. If the product owner is not available to work with the team fulltime, then look for second-best options:

• Assign someone to be responsible for the administrative tasks associated with the product owner role;
• Establish a regular cadence where the product owner meets with the stakeholders to build and review the product backlog; and
• Create cycles where the product owner periodically reviews the product and provides feedback. 

I worry when the Scrum Master tells me is that they just received their Certified Scrum Master (CSM) certification and have no prior experience. CSM training is an introductory course providing an overview of the scrum roles, ceremonies, and artifacts. It is the first step in developing agile mastery.

Great Scrum Masters have a breadth and depth of experience and training. They are facilitative leaders and have a depth of experience that allows them to comprehend team dynamics and respond creatively; for example:

· If the team is discussing a new practice and those most affected by the change are silent, the scrum master might invite them to share their thoughts; or

· If the team is struggling to estimate effort using Planning Poker, they may propose an alternate sizing tool.

Becoming a good Scrum Master can be a Catch 22 [7]. Experience is needed, but getting it can be hard. An experienced agile coach or mentor can be a valuable resource to develop and mature a new scrum master.

A veteran facilitator can enhance the experience of any team. That is particularly true on agile teams. Teams with poor facilitation present several symptoms: 

• There may be an awkward silence during ceremonies or meetings;
• Meetings and discussions are rambling and not time-boxed;
• The loudest members dominate the conversation, and the quiet ones do not contribute; or
• There is an unclear or vague process for making decisions.

Facilitation is not a natural talent. It is a set of skills and practices that can be learned. If the team is lacking a good facilitator, then provide them with training. It will be a great long-term investment. 

Agile teams are involved, collaborative, and accountable. When I observe limited engagement and participation, I am suspicious. 

For co-located teams, I expect members attend meetings in-person since face-to-face communications are most effective. If there is poor attendance: Is the meeting held at a bad time? Are team members demonstrating a lack of engagement? 

When teams are remote or virtual, it is harder to spot disconnection; some things I look for include:

• If the team is using video conferencing, do the members have their cameras turned on?
• When asked a question, do people say, "Can you repeat that?"
• Can I hear keyboards clicking in the background?
• Is there a dialogue, or just a series of monologues?

Meeting avoidance is often a symptom of a larger problem. The sprint retrospective is the ideal time to raise this issue. Hold a dedicated retrospective and focus on the topic of team disengagement. Ask probing questions. Use the 5-Why Analysis [8]. Return to the fundamentals of team formation [9]. Create measurable indicators and check for progress. 

The Deming Model of continuous improvement is Plan-Do-Check-Act. We plan an improvement and execute the work. We measure and analyze the performance (check) and then, adjust the process (act). Unfortunately, too many agile teams forget to check the effectiveness of the changes.

Teams should review (check) the implementation of improvements to ensure they have achieved their desired results. Reserve a few minutes at the beginning of the retrospective to assess recently implemented changes. Should we: keep, kill, or modify the changes?

• Keep. The change met the expectations and resulted in improved outcomes;
• Kill. The experiment did not achieve the desired benefits or made things worse. These efforts should be stopped.
• Modify. The team believes that the improvement idea was good, but they want to modify the process.

Identifying the patterns of good and bad agile practices is one of the first steps to maturing your practice. Creating fun labels to describe what we observe about ourselves and others is a fun and safe way to begin this self-analysis. To build your organization's agile practices, create an opportunity for teams to identify their agile anti-patterns, and discuss the best ways to address them.

Let me know what you find.

© 2019, Alan Zucker; Project Management Essentials, LLC

To learn more about our training and consulting services, or to subscribe to our Newsletter, visit our website: www.pmessentials.us [10].

Related Project Management Essentials articles:

• Forming a Team? Plan for Success [9]
• The Importance of the Product Owner and the Product Backlog [6]
• We've Been Agile for Years, But… [2]
• Road Trippin' Organization Change: The Journey [11]

Image courtesy of: https://cbsaustin.com [12]