Changing Company Culture For Agile Project Management: Avoiding The “Can’t Ban”

Yet another study has listed “culture” as the most difficult hurdle to an organization’s transformation. According to the survey of 1,100 software managers, “General organization resistance to change” (48%) and “Organizational culture at odds with Agile values” (44%) are two of the four top obstacles thwarting the improvement in project management. This is not new, however.  In 2015, Kugler Maag Cie conducted an Agile in Automotive Survey and found one of the major barriers was organizational culture. And Forbes’s 2011 article stated, “Changing an organization’s culture is one of the most difficult leadership challenges … [where] single-fix changes, such as the introduction of Kanban, Lean, Agile or Scrum … may appear to make progress for a while, but eventually the interlocking elements of the organizational culture take over and the change is inexorably drawn back into the existing organizational culture.”

Instead of Kanban, company cultures quietly and accidentally institute a “Can’t Ban”.

But what does “culture” mean, though? That term is so vague and amorphous that a high school chemistry teacher’s lecture might reference it or replace it by “bacteria” or “aberration”. To help make culture more tangible, here are four examples of anti-Agile cultures that have been personally experienced within the auto industry and avoidance strategies for teams witnessing such organizational dysfunction.

The Urgent Trumps The Important

Those readers familiar with Stephen Covey’s “The 7 Habits of Highly Effective People®” know the basic premise: If something is urgent, it will naturally pull attention away from the important because of its burning need. Improving a way of working akin to Agile constitutes important, but disaster is urgent and scary. That malevolent interruption usually comes in the form of flailing coworkers on a different project about to miss a near-term delivery and/or at the brink of a plant-shutdown. These high-profile emergencies force executives into knee-jerk reactions that override any improvement strategies. The common mistake: reorg key firefighters from the Agile team to extinguish the raging blaze elsewhere, thereby creating a dysfunctional hole on the healthy project. The result is mistrust between the supposedly-empowered team and the poorly-supporting managers.

Strategy to Overcome:  Emergency assistance can be applied without breaking up the band. In the scenario where another team needs help, the whole Agile team may apply a portion of its upcoming development time to the higher-priority work. This would result in applying less effort on the current project, but tradeoffs are the very foundation of Agile and build transparency via plotting the effects downstream. “If we do this supposedly critical item, then we cannot deliver this lower-priority item until much later. OK?”

If They Can’t Figure Out, The Adults Will Step-In

Frequently managers’ lip-service supports empowerment until they feel things have stopped proceeding according to their Fantasyland expectations. Therein, a “catastrophe” arises on the Agile team’s current project, and the management’s misguided, cultural gaffe is to dictate a solution. Sometimes that’s rigid oversight including attendance and domineering the team meetings — a.k.a. “getting things back into shape” — or maybe it’s the worst-case scenario of falsely imposing a desired velocity to supposedly beat the crisis. In this case, the director dictates an efficiency 20-30% higher than what the team can naturally achieve. The team quickly realizes the difficulty with that inflated number and works significant overtime to temporarily achieve the expectations. However, “shock the cage” jumping isn’t sustainable, and either turnover, illness or both turn the velocity southward after a few weeks. The results are usually missed deadlines, disgruntled teams, and a failed improvements. The end of the organization’s improvement initiative mirrors its foolish beginning, i.e. zero improvement (at best).

Strategy to Overcome:  When facing an impossible, near-term deadline, there are three scenarios towards healthy resolution: 1) add new team members, 2) re-negotiate the deadline or 3) throw off ballast. The trickiest is probably adding new team members since this usually doesn’t happen quickly, may upset the project’s business case and many times can reduce the throughput of the team.  Renegotiating the deadline seems equally improbable, but this happens occasionally by either downloading software after delivery or retrofitting prototypes after assembly. The last strategy is the most probable: making hard decisions upon as a holistic team about what development is presently ballast and can be postponed until a later delivery. Does that slightly-nagging defect have to be eradicated for this build or could it wait? Could regression testing substitute for the full integration or qualification testing for now? Making these decisions with all stakeholders – possibly including the customer – will help with the cultural aspects of transparency and trust.  Management can help facilitate discussion but should avoid being heavy-handed.

Interruption vs. Intraruption

A common mistake is a functional-line manager or executive having a pet project needing some help from a portion of the team. “I need Jim for just a little bit to fix the test bench” or “Allison’s expertise would be great for this offsite Strategy Workshop.” In a culture of interruptions where everything is the #1 priority, these are managed just as everything else: supposedly minor disruptions and possibly even referred to as “some quick non-Agile work”. And if they are quick assignments, that might even be true.

And if not, this repeatedly disrupts the Sprint Plan and the team wonders why they bother planning.

Strategy to Overcome:  Imagine instead of interrupting (“inter” being a Latin root meaning “between”), the executive intrarupts (with “intra” being a prefix meaning “within”). Those projects could easily be a bundle of work for the Agile Team (a.k.a. Epic or User Story), which the Agile Team could prioritize based upon feedback from the management. Doing this planning from within the team once again helps with the aforementioned cultural issues, but additionally addresses some of the other top obstacles such as “Not enough leadership participation” (46%) and “Inadequate management support and sponsorship” (43%)..

Fear of Failure Becomes Self-Fulfilling Prophecy

Despite quotes from Samuel Smiles and Sir James Dyson (e.g. “It is a mistake to suppose [people] succeed through success; they more oftener succeed through failure” or “Success is made up of 99% failure”), fear of failure plagues 31% of the population on average, which far exceeds the fear of being home alone (which was 9% before coronavirus; arguably higher or lower after sheltering-in-place). Agile teams supposedly disperse that anxiety, but the Product Owner especially can experience the heavy weight of urgent decisions and unyielding second-guessing of every decision. “Agile turns into micromanagement as a result of middle management’s resistance to change,” states Age of Product. “Despite better knowledge, changing an organization into a learning one … is not in the best interest of everybody.” In the end, the Product Owner or Agile team may revert to capitulation, e.g. “Rather than guessing and being wrong, why don’t you tell me what to do?”

Strategy to Overcome:  Even if the manager recognizes that a ship captain is mostly responsible for the safety of the crew, vessel and long-range destination, the crew already has conditioned fear that must be overcome. The best way to eradicate that fear is to enable slack in the schedule to allow learning. If the punishments for failure are missed bonuses, forced overtime or resulting layoffs, the static inertia for change will be too great to overcome. If, however, the team may flirt with learning sans bludgeoning, it will experiment more with self-directed activities.