You’ve been on a 4-year Agile journey. You adopted Scrum or some other framework. You’ve even done the hard stuff: realigned your funding model, re-organized your IT structure, trained everyone. So, why are your indicators for product success still lagging?
It could be a few reasons:
- Ill-equipped Agile Champions (e.g. Scrum Masters). Setting up Iteration Reviews and running Daily Standups does not a Scrum Master make.
- Failure to revamp your delivery pipeline. Two week iterations are great, but if you’re still releasing and delivering to production every 6 months you’ve missed the mark.
- Your IT Portfolio is largely comprised of monolith applications which make it hard to do the above as opposed to a more adaptable micro-services framework.
Tackling all three are difficult but not impossible. While experts in the industry debate endlessly about which one deserves the most focus, no one will tell you to only do one, one at a time maybe but not just one. We’ll focus on the first now since its impacts aren’t as immediately apparent as the latter two.
Depending on which side of the organization you sit in, you’ve seen blame about project success pointed at either business (they didn’t clearly know what they wanted, weren’t as involved) or IT (we told them what we wanted but as usual the costs doubled and we didn’t get what we asked for). Considering IT projects fail at a rate of 55-68% depending on what study you look at, we hear these complaints a lot. Yet I guarantee that percentage doesn’t translate to the executive’s project dashboard, go ahead look it up, I’ll wait.
It’s all green isn’t it?
You are either the exception to the norm or you’re not as transparent as you think. I’ve seen this happen at multiple levels of an organization, opaqueness creeps in. Developers close stories when there’s just a one more task that needs to get done (testing), Program Managers ignoring irregular velocity when reporting out their status, Product Managers turning a blind eye when customer feedback is screaming “Pivot!” The indicators are there, they’re just being ignored. Enterprise tools like Jira, Agile Craft, VersionOne, etc. all make transparency easy but transparency does not equal awareness.
For that, we rely on Scrum Masters and middle management.
It’s their job to facilitate difficult conversations, communicate cold pragmatic truths in the face of overtly optimistic thinking, and engage multiple perspectives outside of just IT. Admittedly this a tougher job for middle management as they are rewarded for project not organizational success, which often means delivering what was promised and not what makes sense, now.
So, communicating the results of a failed experiment will fly in the face of these organizational norms. That leaves Scrum Masters who operate in a more neutral capacity. Many Scrum Masters unfortunately operate at level one capacity (e.g. keeping daily scrums to 15 minutes, scheduling iteration planning, reviews and retrospectives), that stops short of doing the difficult work: creating the environment for a high performing team to develop. For that deeper often overlooked skillset, we need to build bodies that can:
- create the environment for team success
- embody the Values and Principles of Agile so that the Practices that support are truly supporting
- gain participation and perspectives from team members and other organizational stakeholders
- facilitate divergent and convergent thinking and ultimately know when to do so.
These skills can also allow a Scrum Master to align IT, business, and operations on the same page with outcomes that everyone can stand by.
If you are on a Scrum Master career path and looking to get tools and intermediate practices, then the Certified Scrum Master Training (CSM) or IC-Agile Agile Fundamentals training will cover that. Join LitheSpeed’s IC-Agile Team Facilitation to get a grasp on more advanced facilitative skills, so that you are able embody the Principles of the Agile Manifesto to create a potentially safer environment for teams to excel.
