Is it just my company that has a hard time with Agile?

After an Agile adoption is underway and the feedback mechanisms of most Agile processes begin to function, one or more team members usually ask me something like the following:

Is it just my company that has a hard time with Agile?

No, it’s not just your company. However, don’t take comfort in that.

I shared something on Twitter that I think sums up why companies have a hard time with Agile:

Agile practices and processes serve motivated, self-directed teams who work hard. It does not create them. @barryhawkins

When most groups decide to start embracing any Agile process or practice, they usually begin by attempting one or more of the discretely observable activities. This is almost always undertaken with no understanding of how that one piece fits into the cohesive whole of the given process or what underlying cultural elements are assumed to be present in order for it to work as expected. This is how you end up with a team having a “daily standup” (even better if it’s called a scrum) where most folks sit and talk about their day while staring at the wall, floor, or someone’s pen, waiting for the magic to happen. (Spoiler: It doesn’t.)

Why would a group even think this would work? Most likely because some overzealous (and typically unseasoned) practitioner or charlatan “coach” sold them on “Agile” (the fact that it was used as a noun is often your first red flag) as yet another silver bullet. You simply begin mimicking these few things that someone heard about in a talk (no need to read up on them; it sounded really simple), and sooner or later the excellence will kick in. The rhetoric usually reads like an infomercial for commoditized excellence in software development.

If you have a hard-working, self-directed team, an Agile process will most likely add some structure to your operation and show you areas to keep improving. If your team exists within an unhealthy culture, that is where it will begin to encounter its greatest difficulties. Effective cross-functional collaboration does not come about as a result of declaring a group “Agile”. The team will have to really push their ability to communicate and forge relationships with cross-functional groups. Be ready to adapt as you find out who is willing to work with you in this way and who is not. You can start a decent-sized cultural upheaval before you know it; count the cost of such a thing and decide if it’s worth it.

If you have an average team in a company where the technology is an afterthought, that process will probably be somewhat like salt on an open wound. Have you ever heard of a person who sent to rehab or for whom an intervention was staged, but they were nowhere near ready to admit they have a problem, much less deal with said problem? The outcome is seldom desirable, typically driving a wedge between those desiring to help and the one in need of help. Bringing an Agile process into a place that sees the current situation as perfectly acceptable is much like that.

If your team and the company it works for do not have a compatible culture for fully embracing a process like Scrum (that is my preferred one), prepare yourself mentally and emotionally for the fact that it will not “look like it does in the book”. That doesn’t mean you should not try. Almost any place there would be benefit from increased communication and accountability.

Agile processes and practices are hard for a reason; they are vehicles for pushing forward and honing your craft. Activities that drive toward mastery are always difficult; do not be surprised by this.

 

Ask an Agile Coach: What is an Agile Coach?

This installment of the Ask an Agile Coach series is a question normally asked by persons outside my field, but lately I have been asking it myself:

What is an Agile Coach?

Good question. I am not sure anymore.

The more I encounter others who call themselves Agile Coaches, the more I think I may not be up-to-date on what that is supposed to mean.

As I have historically interpreted it, an Agile Coach is someone who first actually established a proven track record of successfully leading a series of Agile adoptions as part of the actual teams. The insight, perspective, and expertise gained through that effort are what enable them to coach others. Multiple Agile teams in varied settings challenges what a person “knows to be true” and (hopefully) beats some humility into and the dogma out of them.

I have been under the impression that an Agile Coach also understands software development and the technical practices that support an Agile team. One must understand why testing, automation, code review, and pair programming exist. One must know what it feels like to work both with and without these things, know why professionals should adopt these practices, as well as when one or more of them are not a fit for the culture. It must be very strange to have management bring in a coach who tells you to do these things but cannot show you how.

I also thought that coaches should understand how to apply an Agile process in a way that stresses cross-functional participation. If what a coach is doing isn’t helping the company to function more effectively as a whole, I fail to see the point. Agile Software Development is neither a defense mechanism for engineers nor a tool for more effective exploitation by management.

It feels weird to have to point this out, but I believe a coach should understand Agile estimation and planning techniques, especially the ones laid out in Mike Cohn‘s books. Estimating and planning are among the most painful parts of software development, and one of the most fulfilling parts of coaching for me has been mentoring groups in Agile estimating and planning.

I also think an Agile Coach is someone who can say no. Agile Software Development is a challenge at best, and a cultural nuke at worst. There are places where the introduction of Agile process and practices would wreak havoc. I suppose the toughest part of this is that it requires a willingness to turn down paying work.

I am seeing things these days that make me think my idea of what an Agile Coach is might be incorrect. If it is, I might need to stop using that word. It doesn’t mean what I think it means.