Home » Technology Strategy & Innovation » On Becoming Agile

On Becoming Agile

I regularly help clients with adopting repeatable and sustainable product development and delivery capabilities. One form this can take is the adoption of agile development practices, i.e., “agile transformation”. Over the years (about fifteen or so now), I’ve come to recognize a few recurring patterns within organizations that have decided to go on the Agile journey that either slow down adoption (impediments) or accelerate it.

Here are a few of those that come up almost all of the time (the topics are abstracted and distilled for the purposes of this blog). Keep these in mind and watch for the impediments in your own agile journey. This is intended to be a handy short-list of topics to pay attention to when bringing agile into your organization, in order to be successful with it.

Know what Agile Software Development is
Have you and your team read the Manifesto for Agile Software Development? All of it, it’s not that long. It’s a really good place to start. Read the twelve principles behind the manifesto too. You should even get your stakeholders together and talk about it. I can’t tell you how many times I’ve gone into an organization that wants to do agile and discover that most of the folks in the driver’s seats haven’t looked at this.

Yes, there are a ton of books on Agile, how to do Agile, how to implement Agile, how to scale Agile but…. IMO, the manifesto is kind of where it all starts, first principles and all that. You can find it here: http://agilemanifesto.org/. Once you know what the agile principles are really about…

Commitment and buy-in are critical
Getting developer buy-in is not (usually) the problem. OK, so this is only partly true, but often this is because the developers don’t believe management and adjacent organizations will embrace the required organizational and process changes, so why bother. Or worse, the idea of a Sprint is setup like an ongoing, syncopated death march. Agile software development needs commitment from all stakeholders, not just the developers.

Leadership has to demonstrate buy-in and commitment to lasting and profound change; this is manifested via actions and decisions. Yes, that means concept of what leadership is has to change. It doesn’t take much for a CEO or a VP of anything to undermine the whole thing. Now that you know you are going to do this thing…

Agile is not rocket science
Educating stakeholders on agile principles and processes should not be an impediment. That said, investing in the team’s knowledge uptake is most definitely required. Agile via osmosis or “read this and get started” does not work, really.

There are myriad ways to do this: classroom training, embedded agile coaches, train the trainer. Which methods work for your organization depends on a number of factors, take the time and figure it out, involve your stakeholders in this process. Once people understand the nature of the changes coming up…

The culture has to change
Arguably, the biggest hurdle to adopting agile in an organization is changing the culture, breaking down the old roles and patterns of behavior and institutionalizing new ones. This requires commitment, a lot of energy from people in leadership positions, and continual reinforcement of good behavior. Peer pressure to do the right thing – up, down, and sideways (yes, I said peer pressure). The best way to get started is to…

Do it manually first
Before you invest in tools, do things manually a few times. Yes, use stickies and whiteboards and (gasp) meetings. Look for gaps, roles evolving to get the needed work done, observe how the individuals and teams organize. Debate the issues, understand the mechanics and the process, and the method to the madness. Reinforce what is working and cull what does not.

Besides, how are you going to know which tool supports how you work until you know how you work? I am always nonplussed when companies buy tools before they know what they need. It’s sad really, but all too common. And now that you are on your way…

Plan to fail
Change is hard. I know a joke I like to tell clients about this. It goes like this:

Q: How many psychologists does it take to change a light bulb?
A: Only one, but it can take a very long time and the light bulb has to really want to change.

Becoming agile is like that; it’s an evolutionary process that will change the culture and psyche of the organization. Evolutionary processes for groups are even more complex than for individuals. There will be dead-ends, failed experiments. Learn from them and keep going. You won’t turn agile overnight, but the journey will make you better if you plan to learn as you go and embrace the philosophy of the whole thing.

And finally….
Agile is not a destination. I like to think of goals as being either point goals or process goals. Becoming an agile shop is a process goal, that is, you can always be better at it. There is not some fixed endpoint that checks the box, next goal please. There are many point goals along the path, and these vary from organization to organization- both in terms of what they are and how they are expressed. This is why continuous improvement is always part of an agile culture, why it’s even baked in the manifesto. If you stop evolving, you are not agile.



Comments are closed.

Scroll to Top