“We Are Going to Implement Agile at Our Company.”

(I started thinking about this a week ago and I’m not sure exactly where I want to go with this, so I’ve decided to put it out there and see what people have to say before adding any further.)

Companies, in increasing numbers, have been deciding to implement Agile within their organizations, in some form, for at least a decade. However, as Tomasz Wykowski suggested in a blog post he write in October of 2018 (https://procognita.com/post/agile-has-crossed-the-chasm-what-does-it-mean-for-agile-coaches-413), two different organizational patterns seem to exist.

There are organizations looking for revolutionary change and there is what he calls “the mainstream market” seeking “a standardized solution that will not impact the existing structure or way of doing the business…that can be rolled out through the whole company without taking a risk.”

Robert Galen, earlier that same year (https://rgalen.com/agile-training-news/2018/2/19/is-agile-in-late-adoption-stage) suggested that “if you look at many large organizations, there are many iterations, or stages, or chasms being crossed at different times.” In one example, he describes a pattern where some senior management “would push it as a transformative initiative across the enterprise and there would be incredible focus and change for a few years.” However, a management change would result in someone who “wasn’t as sold on agile approaches. So, they would defocus the efforts and institute their own initiatives.” The pattern would go back and forth for many years. In large organizations, some groups could be seen “accelerating thru agility and achieving an early to late majority stage.” Other groups would not have begun and yet others would be seen to “regress” when leadership changed.

The challenges of organizational change are no different for an Agile adoption than other forms of substantive change. VersionOne’s State of Agile surveys (http:// https://stateofagile.com/#) have noted the challenges to adoption (and scaling) for years. If one removes the word “agile” from the survey response reasons for such challenges where that word appears, there is nothing unique about what remains regarding organizational change. John Kotter’s “The 8-Step Process for Leading Change” (https:// https://www.kotterinc.com/8-steps-process-for-leading-change/) highlights the importance of understanding necessary considerations in bringing about, and sustaining, successful change.

One can even go back decades to advice Dr. W. Edwards Deming offered in his 14 points (https://en.wikipedia.org/wiki/W._Edwards_Deming) “for transforming business effectiveness” where he noted the need to “create constancy of purpose toward improvement” and to put “everybody in the company to work to accomplish the transformation.”

My own opinion as to why Agile adoptions often fail to produce strong, successful results is that those who initiate, or become responsible to sustain, such efforts seem to misunderstand what they are getting their organizations into when they decide to pursue such adoption. I agree with Wykowski regarding adoptions that desire not to really change much or focus the change effort on people who have little authority to determine how that change will happen.

My primary advice to people who believe they want to adopt an Agile approach is simply to “understand what they are getting their organizations into” pursuing such adoption. Understand what the Agile values and principles mean for your organization to adopt an Agile way of working before you bring in some framework and set of practices. Realize that these values and principles may ask you to make changes you are not prepared to make at least not in the near-term.

Considering the Agile Manifesto’s value statements, understand that

· If your organization has problems with individuals and groups interacting effectively (e.g., across organizational silos), do not expect a new set of processes and/or tools to fix that.

· If your organization has problems delivering solutions (e.g., products or services) that meet customers’ expectations (whether internal or external), do not expect some more rigorous approach to documentation to fix that.

· If your organization has problems with people collaborating effectively (i.e., sharing mutual responsibility for achieving satisfactory solutions), do not expect more formal agreements between them to fix that.

· If your organization has problems responding to change so you can lower risk and reduce costs, do not expect more detailed plans to fix that.

From some of the associated Agile principles, understand that

· You and your customers must expect to work together closely and frequently to provide the necessary feedback to establish trust and confidence that the solutions you are providing will satisfy their needs.

· Project success depends on people who are motivated to work in an Agile fashion and that you give them “the environment and support they need” to produce a satisfactory solution for your customers through trusting in their ability to do so without micromanagement.

· If you do trust them, show that by respecting their estimates of the work they can deliver employing a sustainable pace, along with your customers, throughout the entire project/release period.

· Help your teams to devote time to grow their “technical excellence and good design” as way to improve the quality results expected and become more agile in doing so.

· Support, and expect, the regular practice of reflection and adaptation to grow increased effectiveness in how people function, individually and as teams.

If you consider that doing these things will not be what you can expect to achieve as key aspects of your adoption, seriously consider if you can expect a fully successful adoption.