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.