The Pain of Same: Steer Clear of These 6 Agile Pitfalls

DZone 's Guide to

The Pain of Same: Steer Clear of These 6 Agile Pitfalls

Agile transformation demands handling changes properly and avoiding six pitfalls, including giant chunks of functionality and promise dates.

· Agile Zone ·
Free Resource


There is no clear-cut prescription or magic bullets in Agile transformations. It is hard to do and rarely done well. However, success comes to those with a willingness to accept change and incorporate learning to improve and move their maturity forward. Transformation is a moving target and it constantly forces you to deal with the unpleasant and uncomfortable emotions associated with change.  Throughout the course of 8 years, I have had the opportunity of seeing customers adopt and scale their people, work, and time to find some repeatable pattern of sustainable innovation.  The top 6 challenges I observed were common and spanned across all clients, industries, and roles. 

These 6 behaviors are some of the common pitfalls that keep you stagnant and at the status quo.

#1 – Swinging for the fences

Trying to implement scope that is large in scale without breaking it down into smaller deliverable pieces is a recipe for disaster.  Simple, smaller increments can be delivered faster. Try to think about feedback and capturing it early and often, in order to be more responsive to your customers' needs or market opportunities.  You can’t tackle common support or enhancement requests if you are bogged down with delivering large chunks of work.

#2 – Project-Centric Mindset vs. Solution-Centric Mindset

Trying to “staff” individual resources to the work is more complex and prone to failure.  It is much easier to think about funding 10 teams than it is to think about planning for 100 people on a release train. Teams should stay together over the long haul for them to reach some productivity lift.  This also allows the team to focus in on their domain expertise.

#3 – Nostradamus Estimation

Accurate estimates are flawed in reasoning. Without a crystal ball, you can’t reliably count on estimation accuracy when uncertainty is present. A swag is good enough to get you thinking about the level of effort required to implement a chunk of functionality. Over time, you will get more reliable estimates when you include those who will be responsible for the delivery of the work.

#4 – Promise Dates

The one thing you can count on is change. We all know that agile works best when faced with uncertainty.  Instead of dictating delivery dates, consider instead a way to allow teams to change course when needed to focus on maximizing value delivered over time. The definition of success is not, “we delivered on time and on budget.”  Stop forcing your teams to stick to promise dates, especially as the market demands something different each week.

#5 – Prioritizing Work for Strong Personalities

Yes, strong personalities exist in the workplace, but let’s make sure status isn’t prioritized as “critical” just because your voice is the loudest or you get paid the most. There always seems to be a direct correlation to throughput slowing down when multiple “critical” issues emerge from the highest paid person in the room. Context switching kills productivity, so instead of trying to multitask think about delivering work in sequence. 

#6 – The Trials and Tribulations of Measuring Progress

The best way to measure your value being delivered is to measure the actual work as it progresses over time. The Burn-Up and Burn-Down Charts show this progress quite well.  The common blunder I’ve experienced is reporting measurement based on a percentage complete. I’ve come to find that a team can be 99% complete for 3 months. 

These challenges are just the beginning. Each agile journey is different, but once you complete your agile transformation, buckle up, because the results will be amazing.

agile, agile adoption, agile environment, pitfalls

Published at DZone with permission of monte.montoya , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}