That mysterious box labeled « Agile »

I make my living as an agile coach and for some odd reason, I regularly find myself in an inquiry as to why companies decide to adopt agile practices in their organizations. When I speak with other coaches or people at conferences about agile implementations, I have a hard time lining up the business objectives they identified with what they tell me is actually happening in their organizations.

Here are some of the popular reasons that show up for me in conversations when asking why organizations are adopting agile practices :

• “We want to our teams to be more accountable and engaged in their projects”
• “We want to deliver our products on the market more rapidly”
• “We want to deliver solutions to the business (or the market) that meets their needs”
• “Well, we’ve been hearing about this Agile thing and it’s time to hop on the bandwagon”

What really irks me in these conversations is that at times, they give me the feeling there is a mysterious box somewhere out there with a big “Agile” label on it from which we can make all sorts of magical things appear.

I can picture in my mind this box just arriving on someone’s desk one day, three or four people gather around it and start making an inventory of it’s contents:

- “Self-organizing teams” calls out Paul, pulling something out of the box

- “Got it” answers Mary who is jotting down the contents

- “Rapid delivery” says Paul pulling out something out from the box

- “Got it” answers Mary once again

- “Oh wow!!! Continuous Integration!” calls out Paul, now all excited about his discovery

- “All righty! By the way, did you see the client collaboration piece in there?” asks Mary

And so the conversation goes until the box is empty. That image sticks in my mind because it occurs to me as if all these things will just magically happen because we declared (or believe) our software development teams are now Agile. The great thing about this box is that these things come neatly packaged and all we need to do is unpack them throughout the organization as needed.

When we want self-organizing teams, as a manager, we need to let go of our old paradigms and give people the right to make decisions and also to make mistakes. In an organization with a history of a control and blame culture, how would it occur to a team with people that have been in the company for a long time to tell them they can now make decisions on their own. Experience tells me it occurs to people like a trap. In such a context, before making such a statement, the management team needs to acknowledge and own their shortcomings of the past if they want to move forward.

Simply saying we want to increase our collaboration with our clients or business partners means nothing until we start acting like a good partner ourselves. As an organization, we must give ourselves the teams and the time to learn to better communicate with our partners and build real meaningful relationships. From the business side, we need to have a clearer idea of our vision and needs and from the development side, we need to have the courage to propose the best solutions.

Wanting to deliver to market more rapidly will never happen if the development teams do not have a clear vision and objectives on the solutions they need to deliver. As an organization, we need to be clear on why we are doing a project and have a short and medium range vision for our products. Our internal projects must be well targeted and be more than just giving a department a proverbial kick at the development team can.

Adopting agile practices does not come out magically out of a box and it is more than just a simple project, it is a transformation process for an entire organization. It is important to take the time to reflect on the changes we want to bring and be able to clearly communicate expectations to the people impacted by these changes. For example, not letting a team know self-organization is an expectation and setting the right boundaries for them is the first logical explanation to why self-organization is not happening at all.

If you truly want to be an agile organization, there are times where it is necessary to take the time to look at agility in the larger context. How could agile practices impact and transform the rest of your organization? From the sales pitch to the way you interact with your clients on a daily basis to your entire development cycle, what is the agile experience you are looking to provide your clients? Is it possible to incorporate some pieces of agility right at the start of your sales cycle?

Remember that although this mysterious box may appear on your desk one day and it may very much tickle your curiosity, agile transformations do not happen without the efforts of many people in the organization. Understand what you are trying to do and why then go intrigue and involve others in the process. Do not forget, your own efforts are part of this change too!