The Savvy Pm Blog

Don’t Blame Agile for Bad Agile

Alan Zucker

|

Home The Savvy PM Blog Don’t Blame Agile for Bad Agile

An agile backlash is underway.  Some organizations have declared victory, fired their agile staff, and moved on.  Others are agile in name only or are “doing” agile but have not fundamentally changed the way they work.

We should not blame Agile for bad Agile.  The problem is not with the values, principles, and practices. Instead, it is with organizations and their approach to agility.  This article highlights some common issues I have encountered in my consulting and coaching practice. 

Failure to Adopt the Agile Mindset

Agile is a mindset.  It is a fundamentally different way of managing, working, and delivering projects based on a set of values and principles.  Too many organizations only adopt agile practices and tools without changing their mindset.

Agile teams are empowered and collaborative.  They deliver value to their customers incrementally and iteratively. 

There are multiple frameworks and toolkits that enable agility.  They provide the structure and practices to guide the teams. 

But, adopting a framework or practices without the mindset may yield short-term improvements but will not lead to long-term success.  High-performing agile teams are characterized by the following:

  • Psychological Safety.  People must feel their opinions matter and will be listened to. 
  • Empowerment.  Team members are empowered.  They are heard.  They make decisions. 
  • Creative and Innovative.  People are encouraged to develop solutions to serve customers and define how the team operates.
  • Shared Accountability and Collaboration.  The entire team feels accountable for delivering the solution. 

I worked on many “agile” teams before Agile was formalized.  We developed our own lightweight practices.  We embodied the first value of “individuals and interactions over processes and tools.”  And we were committed and focused on delivering solutions quickly.  These teams were magical.  It was amazing what we were able to accomplish. 

Maintaining a Command-and-Control Culture

We have been transitioning from an industrial to a knowledge economy for over 60 years.  Despite this shift, many organizations are stuck in the top-down, command-and-control culture associated with Frederick Winslow Taylor and Henry Ford. 

The industrial mindset is pervasive and hard to shake.  Managers make decisions, and dictate solutions and timelines.  One of my old bosses was fond of saying, “Trust, but verify.”  Well, if he really trusted, there would be no need to verify. 

Giving up control and trusting the team is hard.  Cultural norms conflate management with micro-management.  David Marquet explains the standard expectations of a Navy captain, “…we give orders, we sound like Russel Crowe…”  His ship became the highest rated in the entire Navy because he reversed years of tradition and stopped telling his crew what to do. 

Relinquishing control is the force multiplier.  Rather than being limited by one person’s knowledge and experience, we benefit from the innovative and creative energy of the entire team.  Diverse teams consistently generate better solutions to complex problems than individuals. 

Even well-meaning scrum masters and managers of agile organizations ask me, “My agile team is struggling. What should I do?”  My response is, “What does the team think?  What do they say?”  Resisting the knee-jerk reaction of management-derived solutions is difficult. 

Trapped in Fixed Delivery

Traditional project thinking is built on the fallacy of the triple constraint.  Believing the project scope is fixed and changes must have a corresponding impact on time and cost creates traps and false expectations:

  • Project scope can be adequately defined upfront;
  • All scope items must be requested at the beginning, or they will never be delivered, and
  • The entire scope must be delivered for the project to be successful.

Shifting from a fixed- to an incremental-delivery mindset enables opportunities.  Since only a third of the features in enterprise software are commonly used, delivering incrementally reduces waste.  It allows solutions to be delivered sooner and for the organizations to learn and adjust more quickly. 

Inadequate Agile Training

The Scrum Guide states, “Scrum is easy to learn but hard to master.”  Too many organizations do not adequately train their teams or hire sufficiently experienced people to guide and support their agile journey. 

Deciding to adopt agile without adequate training is a recipe for trouble.  People may be able to execute the practices but will not know why.  Or, they may not know other options or better ways of doing it. 

Agile practices are not mechanical.  They enable the mindset.  Without understanding the principles, the actions are hollow. 

Learning does not occur by osmosis.  We cannot just send a few people to class and hope it magically spreads to others.  Whole team training works best.  Everyone is exposed to the same concepts and practices.  They all hear the same thing.  There are no in or out-crowds.  There is a level playing field. 

Teams are social organisms; when people learn together, they bond and become high-performing. 

Wrong or Abused Framework

There are three primary agile approaches: Scrum, Kanban, and Scaled.  Then, there are multiple supporting frameworks.  Scrum is often the default because it is the most well-known but should not be the default approach. 

Scrum is optimized for complex problems where the requirements are unclear, and frequent user feedback is needed to assess the solution fit continuously.  Teams conform to a 2-week delivery cadence, creating a standard operating rhythm and predictability.  Scrum may not be the best solution for all projects, such as re-platforming efforts or programs. 

Poorly executed or immature agile practices are also common.  These teams do not realize the potential benefits and miss the comfort of traditional approaches.  We observe:

  • Teams trying to execute a design-build-test waterfall in a 2-week development sprint;
  • Low or non-existent customer engagement during the iteration reviews resulting in  inadequate feedback; and
  • Conducting out-of-cycle testing weeks or months after the software has been developed. 

Unfocused Teams

Agile promotes long-standing and focused teams.  Long-standing teams are more likely to be high-performing.  Teams focused on a single project are more likely to meet their commitments and be more productive.  When members are part of multiple teams, prioritizing work is complicated, productivity is lost due to task-switching, and quality suffers. 

© 2023, Alan Zucker; Project Management Essentials, LLC

See related articles:

To learn more about our training and consulting services or subscribe to our newsletter, visit our website: http://www.pmessentials.us/.

Image generated by Dale E 2.0