Project Practitioners > Are You Elegantly Solving the Wrong Problems?

Are You Elegantly Solving the Wrong Problems?

By Brian Irwin

I recently read an interesting article by Mark Shead outlining how good we are at problem solving and how notoriously bad we are at identifying the correct problem to solve.  That notion resonated with me in both personal and professional contexts.  Being emotionally invested in outcomes can occasionally obfuscate the true underlying issues; or, if we are aware of the underlying issues, we might dare not address them directly for fear of the unknown (insert personal reason here).  Alas, we attempt to address what we perceive to be the real issue which often turns out to be only a symptom of some deeper, more significant problem.  This is frequently an issue with teams and organizations when attempting to adopt agile mindsets. 

In my own work as an agile coach I find that it’s not at all uncommon to see teams and organizations working hard to find a prescription to ease the pain of their symptoms.  The intent is improvement but the result is often the same as treating a chronic illness with aspirin—superficial at best.  Treatments for these illnesses are long-term and can be difficult, but the effort is well worth it because it will be lasting.  As an analogy: if you have chronic back pain and are told that it’s because one leg is longer than the other, do not seek to get one leg shortened or lengthened—it may take back surgery to get lasting relief.  But isn’t it more appealing to go for the easy, quick fix? 

I’ve assembled what I hope is an easily-referenced table of the most commonly perceived problems, typical incorrect solutions, and the most probable illness(es) and potential lasting solution(s).  Remember, agile will NOT solve your problems but it will perform exceedingly well at exposing them.


Perceived Problem (Pain)

Incorrect Solution

Common Illness(es)

Potential Lasting Solutions

Daily standups are ineffective and feel like status report meetings.

Reduce standup meeting frequency to less than daily.

Objectives of standup not well understood

Coach the team on the purpose of standups—plan and coordinate daily work and demonstrate individual-to-team accountability

ScrumMaster operating in project manager mode

Coach ScrumMaster and the team on the daily standup objectives.

Remove the ScrumMaster if he or she is unable (or unwilling) to remove PM habits—they may not have the correct skill set.

Managers in attendance take over the meeting

Demonstrate courage and kindly explain the purpose of the meeting and ask them to hold their input until after the meeting.

Teams consistently have unfinished work at the end of a sprint.

Increase sprint length.

Agile engineering practices are weak or non-existent.

Introduce good agile engineering practices slowly, such as Test-Driven Development (TDD) and Continuous Integration.

Insufficient (or non-existent) definition of done

Create a definition of done that leaves completed features in a potentially shippable state.

Team has issues with estimation and/or decomposing larger stories into smaller ones.

Work with the team on estimation and breaking down stories into smaller ones, perhaps getting some external coaching could help.

Stories are ill-defined and/or incomplete.

Work to establish a definition of ready, where stories are not able to be pulled into a sprint unless they’re estimated, small, and adequately understood by the team.

There is no time to test at the end of the sprint.

Create sprints that focus on one activity only, such as: design sprint, development sprint, testing sprint, etc.

Agile engineering practices are weak or non-existent.

Introduce good agile engineering practices slowly, such as Test-Driven Development (TDD) and Continuous Integration.

Individual team members view themselves as specialists.

Create an environment that fosters a musketeer (all-for-one and one-for-all) attitude. 


Perceived Problem (Pain)

Incorrect Solution

Common Illness(es)

Potential Lasting Solutions

Defects are frequently discovered in production, often by customers as the product is used.

Introduce additional release procedures to catch more defects before they escape into production.

The release process may actually be too rigid, adding bureaucracy and overhead to teams and not allowing software to get to a potentially-shippable state within a sprint.  Downstream activities can undo what a team has built in a sprint.

Review the current release process and work hard to identify items that were added in an attempt to ensure past mistakes were not repeated.  This is process bloat and adds cumulative waste.

Legacy systems have an incredible amount of accumulated technical debt because shortcuts were frequently taken so teams could hit artificial deadlines.

Slow down to increase speed.  Technical debt is a tax which must be paid sooner or later.  If you pay sooner, it will usually cost less than if you pay later.

We have commitments which must be kept to implement our strategy that will require us to complete a myriad of projects.  We must make progress on all projects simultaneously

Allocate individuals to projects based on skill set and availability.

Thinking that effort and activity equate to progress. 

Reduce the amount of work in progress (WIP).  Ultimately this maximizes the probability of faster delivery.

A mindset that values individual allocation based on skill set over team-based work allocation.

Allocate complete teams to projects, not individuals.

We have no way to coordinate work across the enterprise using agile, especially with very large initiatives.

Bolt on a defined and prescriptive process which provides a way to control uncertainty.

The organization believes that complexity demands more headcount.

Create cross-functional teams capable of delivering entire solutions—even complex ones.

There is a general inability to decompose work or decouple efforts.

Focus on feature development by team.  Identify project managers who can help coordinate enterprise efforts and allow software architects to work as a community of practice to ensure cross-platform architectural integrity.

 I do realize that some of what’s said in the table is controversial, and I also understand that everything is contextual and the above is far from exhaustive.  But, in my experience, it illustrates the most common issues that teams and individuals face when first transitioning to agile from environments where more traditional management techniques were employed.  What are your thoughts?  Is there anything you would add or change?

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.