Is Half-baked Agile Enough?

Don’t stop short of your true Agile potential.

Is being good at Agile enough? Making the change to Agile does not happen overnight. It is tempting to stop short of the true potential of Agile. The journey, while long, is worth it. If the expected improvement is not quickly realized for your Agile transformation, it is easy to conclude that Agile does not work for your context. However, this is unlikely.  

If you review the Agile values in the Agile Manifesto, are there any efforts, software or otherwise, where they do not apply?

• Would you ever want to favor processes and tools over individuals and interactions?
• Can you imagine a situation where it would be better to have comprehensive documentation instead of something working?
• Do contract negotiations seem like a much better activity than customer collaboration?
• Does following a plan and ignoring the reality of change provide calm in a storm?  

I can’t think of one software development effort where I would answer, “Yes,” to the above questions. If Agile is a perfect match for not only software but many other endeavors, why is its full potential so often unrealized?  

In my experience, Agile transformation stops short for three frequent reasons—the rejection of transparency, the belief that Agile does not apply to the context, and impatience with experimentation.

---

The Rejection of Transparency

It is uncomfortable to find problems. The frequent inspect and adapt loops in Agile shed light on your problems, forcing you to face them. If you ignore them, they will show up again and likely will be magnified. If the environment is not safe for raising problems, it is all too common that issues will be swept under the rug, optics will be managed, and the message will be controlled especially as it moves up the organizational hierarchy. Opaqueness will rule.

If you do not address problems as they arise, you will be unable to respond to change and adapt to the circumstances on the ground. Agile will fail if you do not reflect and improve. Feeling safe is paramount. There can be no fear of criticism.   

Recommendation: 

In the Agile community, we talk at length about the importance of a “safe” environment. It is key for transparency to thrive. The unfortunate reality is that most traditionally managed companies do not promote a safe environment for raising problems. Due to a fear of criticism, nobody wants to raise that a flaw exists with the current design, discuss defects that were missed, or admit that users are not using what was built. Unfortunately, waiting on safety to emerge can be a long wait and will delay, slow down, or even halt an Agile transformation.   

So if you can’t wait on safety, what do you do? If you do not feel comfortable raising issues, speak with your manager about it. See if your manager will allow you to learn from failures as a means of building both your skills and a better product. 

Ask your Agile coach or team member to assist you with raising a problem and asking for help. At the beginning of your transformation, it will help to pair with a coach, another team member, or even your entire team to raise issues. There is power in numbers. It will take courage, but without this courage, your transformation will stall. 

Agile Does Not Apply Here

The belief that you, your project, or your company are different can impede your transformation. Usually, the rejection is not of Agile in its entirety. The rejection is usually of what is called “pure” Agile in favor of something less drastic of a change from the existing norms.  

This results in a compromised version of Agile where elements are selectively chosen and altered to fit within the existing status quo. You may have heard terms such as Iterative Waterfall, Scrum-But, or Agile-fall to describe these pieced-together, partial adoptions.  

Recommendation:

You must fight back the urge to pick and choose elements of Agile. Strive to achieve a pure version of Agile. There are many patterns and techniques that others have implemented and work in a variety of contexts. It is imperative to learn how to properly implement these new behaviors and techniques. Rather than reinvent the wheel, enlist an Agile coach to help you do this. An Agile coach has implemented these patterns numerous times and will help retrain your behaviors. 

For more details on utilizing your coach, see the prior posts: 

• Can Coaching and Self-Organizing Behavior Co-Exist?
• Is Your Agile Coach Out of Touch?  

Impatience with Experimentation

Who would not want a silver bullet solution to solve delivery inefficiencies? We often want immediate results. However, Agile transformation takes time. It takes patience to retrain our belief system and learn new techniques.

When we experiment with Agile techniques and patterns, we often want to measure the results of that experiment. When we learn Agile behaviors, often the experiment is simply trying patterns that others widely use. Numerous existing patterns have proven to improve the delivery of working software for the vast majority. We are not trying to prove that the pattern works. It works for many people in many contexts. Often, we measure when we are learning the new method and become disillusioned when the new behavior is not yielding results immediately. We may even incorrectly conclude that the pattern does not work.

Recommendation:

First, you must simply learn the technique. The results may not happen if the technique is not properly in place. Rather than embark on this alone, enlist the help of an experienced coach to retrain you in the new technique. 

When the new pattern is being implemented correctly and applied properly to your context, you can then assess the outcome and see the results. It may take several sprints and several retrospectives to reflect on and improve the implementation of the technique before the results are achieved. You must practice patience to allow the change to take root and to see its fruits.  

---

Conclusion

For total transformation to take place, you must embrace transparency, admit you are not unique, and have patience for the change to take place. Don’t stop short of your true Agile potential with half-baked Agile. Embrace all the Agile values, and stand on the shoulders of those that have come before you. Avoid stopping short of truly mastering proven patterns. Be great instead of just good.