The Ultimate Secret of Agile Adoption in Two "Simple" Steps

Don't believe when people tell you Agile will make your projects faster or cheaper. Don't trust consultants who promise cost reduction, higher ROI, better quality or customer satisfaction as a result of Agile adoption.

Here's the truth: Agile will give you only two things:

1. All problems will get exposed
2. You will start delivering.

The rest (speed, quality, cost efficiency) will happen, but not immediately. It will probably take years for the organization to solve the problems exposed by Agile, automate, eliminate waste, learn to collaborate and achieve synergy across horizontal and vertical silos, but it has to start with frequent delivery.

Starting Agile adoption is easy. You only need to do two things. They are not easy, but if you're persistent and really want to solve problems and start delivering, you'll be successful.

All you need, is to ask yourself (and everybody in your org) two questions.

Ready, set, go!

1. What are our teams?

First of all, build teams. Without teams, there's no Agile. Teams are the heart, the soul the the body of Agile adoption. Each team has to be cross-functional, which means it has to include specialists that cover all functional layers: back-end and front-end developers, manual testers and automation engineers. The team should have the skill-set and domain expertise to be able to cover a module or a product area. It's also great if the team is co-located.

One great thing about teams: once the team bonds and matures, it doesn't have to be married to a specific product area. You can move it to a different space and it will ramp up and start performing in no time. That's the absolute beauty and the ultimate super power of great teams!

If you think "ah, teams, that's easy", think again. Even at this early stage the organization can get stuck. Product areas that have no clear boundary or consistent stream of requirements, monolithic applications in which everything depends on everything else, trust issues and control issues (senior vs junior, on-shore vs off-shore), lacking skill sets, inadequate headcount, uneven resource utilization (some people overworked while others have nothing to do) - these problems are only the tip of the iceberg and chances are you will experience them all.

Unravel the issues one by one, don't stop until you have independent teams, each one equipped with knowledge, decision-making power and a backlog to pull from.

The second question you'll ask yourself (and will continue asking for the rest of your professional life) is this:

2. What do we need to do to ship a small release in two weeks? two days? two hours?

Aha! And that's where the fun begins. You'll probably notice that in order to develop, test and deploy in two weeks you'll need clear requirements (cue product owner and the quality of user stories).

Then you'll notice that your developers and testers are not used to collaborate, instead they do some version of a relay race (also known as "waterfall" or its shorter version "scrummerfall").

Next thing you know you either have no access to your environments, or building an environment takes four weeks, or your deployment team is buried in requests and you have to wait.

You'll make interesting discoveries about dependencies across modules and products that make your testing a nightmare. You'll see how much manual work you do and how much time the team is wasting on it.

Once you started shipping frequent updates, you'll learn amazing things about your customers and how they really use the system.

It will be a long and painful process, but at the end it will be worth it. At the end you'll achieve true agility.

But don't be scared. Always remember, your goal is to keep the teams self-sufficient and deliver every two weeks (days? hours?). Anything that stands in the way is a problem! Identify each problem and tackle them one by one.

Now, see what I did here? I never said "Scrum". You don't have to have standup meetings, retrospectives and demos, burndown charts and velocity calculations to be agile. But if it gives you a framework to develop and deliver in short iterations, if it helps you to establish pace and track development - then use it!

What was your road to Agile and agility?

Please like and share with your network! Comment, share your thoughts and send me your questions, follow me on LinkedIn and Twitter to read my articles on practical Agile.