Search This Blog

Tuesday, January 9, 2018

Adoptions, implementations, and transformations... oh my!

As an Agile Coach I need to help my client identify why they believe Agile will help them so they can set themselves up for success.

Adoption. Implementation. Transformation. Transition.

I've heard, and used, these terms when discussing a client's desire to be Agile. I've heard them misused as well.

There's a difference between all those terms. And that difference matters, because it sets so many up for failure. It also allows a mindset that is anathema to Agile.

Adopt is to choose or take on; as in adopting a child. When we adopt Agile we might be adding it to our existing processes, practices, etc.

Implement (the verb) is to put something into place or effect or start using. When we start using Agile, we can either be replacing or adding to current processes, practices, etc.

Transition is the process of changing from one state of condition to another. When we start using Agile we are transitioning away from other methods or practices.

Transformation is a thorough or dramatic change in form or appearance; a metamorphosis. When we transform ourselves with Agile we are affecting a change throughout the organization. One which, when complete, will leave us looking very different.

I think diction is important and try to be precise when speaking and writing. But I have found that sometimes I must be less precise to appeal to my audience. Not everyone believes diction is important or even thinks about it. And if you sound like a pedantic professor all the time, people might lose interest in what you're trying to convey.

But when it comes to what I'm trying to help a client do, I think the distinction between these terms is critical. And I would call out two more as well, adapt and adjust; these come into play along with all the other terms.

Adopting or implementing Agile means the client either doesn't know what that means or they aren't willing to change their whole organization to be Agile. In many cases, I've heard a client say they only want their software or IT teams to use Agile because they feel that's the only place it will work or that's the only place they feel it's necessary.

But if you soup up your car engine without increasing the the air intake or the exhaust manifold you will have paid all that money for nothing. You won't go faster and in fact you might have problems with the powerful engine choking, sputtering and even stalling.

When I hear clients say they are transitioning or transforming to Agile it sounds like they understand this, but not always. Because a true transition means you're readying everyone and a true transformation means everyone is changing how they do what they do.

We are no longer a society that works primarily in factories mass producing widgets on conveyor belt assembly lines, with pieces and parts humans pull and fit together and then pass on to the next human.

Now we're asking people to think about how we can best give the customer what they need/want whether it's a financial product (quick loan on your credit card via your mobile smartphone), a game (for the kids, to vent frustration or maintain brain growth), or an feature that helps them be more efficient (e.g. voice dictated emails).

That requires living life so you understand the need and what features and functionality are best to offer; and keeping up with what is already out there. None of us wants to copycat another but we often end up doing that without trying because we don't pay attention.

We need to be out in the world interacting with our customers so we understand them and the world they, and we, live in. This might mean carving out a day or two a week or month to allow employees to explore the world outside work. Or fostering an environment where different business teams collaborate and share and learn from one another. Or sending them to conferences where they can interact with the customer as well as peers.

It also means inviting others to the table where we have the discussions about what we're doing and why and when. In this case, more heads are much better than the proverbial two. Especially if those other heads have information that might impact our decisions.

Sales knows that a competitor just released a similar app. Marketing knows the timeline puts the app on the market at the wrong time. Staffing/Talent Resourcing (aka Human Resources-a phrase I am on a mission to eradicate) knows they won't be able to find the developers necessary in time because they're hiring process takes six months.

Security knows that they will be in the midst of a compliance and regulatory driven audit and unable to review the changes or open the fire wall for them. Operations knows that the ramp up for procuring hardware will take three months of the timeline. Finance knows that there isn't enough money for six months without pulling it from elsewhere. Support knows that the lead time to hire and train enough people to support the new product is six months plus at least two weeks.

Why would you not take all this into account when making a decision about where you're going to spend money, on what, and when?

By all means, introduce Agile to your development teams, whether delivery or IT, but take a look at how your annual goals are selected and what the organization does to drive to them. Is everyone in sync?

Are the problems you run into because those other units didn't know the plan or didn't realize how they fit into working toward the goal? Did they (or you) think it didn't matter how they did things?Are the obstacles due to those other units inability to deliver what is needed in the time allotted?

Maybe Staffing/Talent Resourcing needs to examine why the hiring process takes so long. Maybe Security needs to create a Jedi team that takes on the annual audit freeing up others to review new releases. Maybe Finance should look at how to fund a team or a product so there is no need for creative financing (which gives everyone heartburn). Maybe executives should examine how many initiatives make sense to run in the same time frame.

Maybe you need to adjust or adapt your adoption and implementation of Agile to include a transition to a transformation where you get everyone one the same page. Increase the air intake and the exhaust manifold; your engine will run much more efficiently.