Diagnosing the Challenges in Scrum

When people go to the doctor's office, they often complain of superficial manifestations of a problem (i.e., "chief complaints") that don't present any serious concerns, but in reality, are indicators of a much more serious systemic illness.

I've come to the conclusion that we in the Scrum field are also dealing with a similar type of scenario.

For those of us who have been coaching for a while, it's probably a common experience to have a team member or a manager come to us with what appears to them as a "key problem," but in reality, turns out to be a symptom of a much more serious underlying dysfunction.

On June 1, 2015, there was one-day agile conference held in New York by a well-known local agile community: Big Apple Scrum Day. It brought together more than 250 Scrum and agile practitioners from around the globe.

I organized the "Scrum Coaching Clinic" for the event. I personally coached about a dozen people that day, and my experience only solidified the notion that it's crucial to trace a presented problem back to its original root cause.

From that event, here are some examples of local/topical challenges that were initially presented as "key problems" by attendees, but were then traced to more systemic issues …

Example 1

Symptom (chief complaint): Lack of honesty in retrospectives. Individuals very reserved in retrospectives.

Details: Individuals are very reserved in retrospectives. Too many generalizations, not enough specifics. Real problems are not discussed or downplayed. Actionable items are not identified. Too much "political correctness" and fudging.

Further discovery: Direct line management attends retrospectives, usually at senior management's command. Retrospective recaps are viewed as "official documentation" to be shared widely - this puts many people in harm's way (reprisals are not uncommon). In retrospectives, management frequently looks for individual accountability, as oppose to team accountability.

Example 2

Symptom (chief complaint): Miscommunication in executive reporting.

Details: Team-level metrics and data (velocity, throughput, forecasted dates) are not easily "translatable" to communication and reporting that is presented to senior management.

Further discovery: Metrics and data collection at the team level are not reliable in the first place (e.g., velocity is very volatile). As information travels up the chain of command, it is "formatted" to fit what is perceived as the "usual format" at that level. Along the way, data gets skewed and fudged. Individuals with limited understanding of work size and complexity also contribute to estimations. While agile implementation is attempted at a team level, senior management is not educated enough to comfortably read agile metrics and reporting.

Example 3

Symptom (chief complaint): Lack of reliability with estimation techniques.

Details: Velocities are volatile. The same work is estimated differently by the same team at different times.

Further discovery: Inability to normalize work size and translate it into "money." Poor teaming. Lack of cross-functionality. For every developer (coder), there is at least one (non-coder) whose understanding of work size and complexity is rather limited. Team members don't get a chance to work together long enough due to resource re-shuffling and can't "normalize" their view on work.

Example 4

Symptom (chief complaint): Difficulties with talent retention.

Details: Companies heavily rely on temporary staffing, instead of building their internal technical expertise.

Further discovery: Acquire unpredictable quality staff (usually lower quality workers at a lesser cost) who must soon depart a company due to HR policies. As a result, talented people are in scarcity, and so is knowledge retention. Continuous knowledge transfer is required with much of the knowledge falling through the cracks and getting lost, as people tend to protect their jobs by taking their knowledge with them as they leave.

Example 5

Symptom (chief complaint): Lack of synergy with product ownership.

Details: Odd relationships between product owners and teams. At times, direct reporting lines between POs and team members. At times, multiple "equally important" stakeholders stepping into a PO role simultaneously.

Further discovery: Very few POs have combination of knowledge, authority and willingness to intimately engage with technology. Frequently, the PO role is assigned as a mandate and is in competition with other responsibilities of an individual. Poor definition of a customer. Difficulties finding an individual whose "paycheck" truly depends on product development success. There is no traceability between efforts and money spent on development, and extra revenue generated as a result of development (i.e., no analytics on ROI).


While speaking to individuals that day at the clinic, I came to the conclusion that very few are actually willing to travel "upstream" from a topical problem to its deeper root cause.

As Scrum coaches, we should refrain from jumping too fast to conclusions. Sometimes, the effect of anchoring is too strong and hard to resist; the initial information presented may be loaded with hidden anticipation for a particular recommendation - a trap that we, as coaches, should avoid falling into.

By emotionally detaching from the company and people we are coaching while at the same time collecting information and not allowing ourselves to be led into false and premature conclusions, we are improving our chances to build a more objective, unbiased view that spans far beyond superficial symptoms and much deeper into organizational layers.

Gene Gendel is a Certified Scrum Coach, Certified Large-Scale Scrum (LeSS) Practitioner, CSP, CSM and PMP.