Agile Adoption Requires Agile Transformation

ONE of my mentors recently made the comment, “Agile adoption is different than Agile transformation”. This made me really think hard about the implications of this statement. I reflected on how companies incorporate agile practices into their organization. Typically they bring in outside help to train team members on agile methodologies. Often this will be the extent of the learning and teams will go off to “do” agile. Teams will have a ton of questions and no one to guide them. The few elite companies will also bring in team coaches to reinforce the training. Unfortunately, many companies stop here and then wonder why agile isn’t working for them.  In their minds they have “transformed” their teams and the company should be agile now. They’re unaware they’ve only started adopting agile and there’s more needed.

Agile adoption cannot be fully implemented without agile transformation. To achieve true transformation, Enterprise/Transformation coaches must be brought in to move the entire organization into agility thinking. The real reason agile doesn’t work isn’t because the teams don’t understand agile or aren’t doing it right (although this may be true). The main reason is because organizations do not transform other areas outside the agile teams. These areas engage in anti-agile behavior or smells that impede the team’s ability to go from “doing” agile to “being” agile. And as the smells linger, the adoption of agile diminishes.

What are some anti-agile organizational smells that impede agile adoption? Setting deadlines is one. When deadlines are set, teams can’t be creative and ensure they build the right thing well. Technical wealth is diminished as teams take shortcuts to meet the deadline. This results in poor engineering practices, code and infrastructure that must be cleaned up later. Innovation is killed or the deadline is missed. Morale declines too as teams work extra hours to get work done in the timeline.  Teams need to focus on delivering value. The Product Owner can decide the best time to release features to the market. If teams are building small increments of value, the PO can plan what gets shown at those crucial conferences through backlog prioritization.

Projects are another smell. If your company is looking at everything as a project rather than looking to promote products, your agility adoption and transformation will suffer.  There is little room for innovation and improvements when teams focus on a project rather than a product. End-user or customer focus is lost as everyone concentrations on making the project a success rather than the product. With product focus, the Product Owner has the ability to quickly change focus to address whatever market changes may occur. These changes may fall outside the original “project” scope and instead of spending time negotiating to introduce the changes, the Product Owner can swiftly adjust the scope to deliver what’s needed now.

There are other smells such as lack of trust, command and control management, endless status reporting/meetings, missing roles (think no Scrum Masters or DevOps) and  individual evaluation versus team evaluation metrics to name a few. It is these impediments that actually thwart agile adoption and inherently make agile transformation impossible. I’d argue that true agile adoption can’t exist without agile transformation.

As Scrum Masters and Agile Coaches when we are approached about helping with agile adoption, we must stop and ask, “What are you really looking to achieve, agile adoption or agile transformation?” If leaders request adoption, it’s our responsibility to let them know they will never achieve full adoption without transformation. Then we need to validate they’re OK with that. Explaining why adoption won’t work without transformation will set expectations around what they will and won’t achieve. Maybe then, companies will change their approach to agile adoption and include transformation in their decision to become agile.