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 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,” 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:
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 and welcoming changing requirements.
When clients tell me, they have outsourced their development, I begin to ask questions:
Successful outsourced agile projects are built on collaboration and trust. Watch out for contract terms and engagement practices, such as:
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 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:
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:
Becoming a good Scrum Master can be a Catch 22. 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:
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:
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. Return to the fundamentals of team formation. 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?
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.
Related Project Management Essentials articles:
Image courtesy of: https://cbsaustin.com