Three reasons you’re not seeing results from agile

BrandPost By KPMG
Apr 09, 2019
Agile DevelopmentCIOIT Leadership

The doctrine of “agile” has been preached far and wide, and information technology (IT) executives and entry-level personnel alike have swooned to the promises of a better way forward.

gettyimages 476804267 8556
Credit: KPMG

By Naveen Dhanpal, Nathan Bailey & Anouchka Depasse

The doctrine of “agile” has been preached far and wide, and information technology (IT) executives and entry-level personnel alike have swooned to the promises of a better way forward.

Well done on embarking on the agile journey—but now that you’ve taken this step, do you see results? Is a smaller team delivering more? Are fewer defects reported? Are you seeing a faster time to market? If the agile methodology was successfully implemented, then you should be seeing all these benefits and more.

The line of failed agile implementations is long. These include organizations that have not seen results, lost enthusiasm, and have begun to lose focus on “that whole agile thing.” Through such agile implementations, we can see common reasons that lead even the best IT groups to fail.

Reason #1: Culture matters

You read that article, heard that speech, and thought, “We could do that here.” Agile processes and policies begin to be laid out in the organization, but one thing is forgotten—culture.

Agile techniques have to be baked into the culture of an organization. As stated in the 12th State of Agile survey (VersionOne, 2018), “The leading cause of failed agile projects is an organizational culture at odds with agile values.

To change how your IT group operates, you have to start with culture. Culture is the seldom thought-about factor that shapes your meetings, deployments, infrastructure enhancements, and everything else an organization does.

How do you ensure old processes don’t block being agile?

To ensure that existing processes don’t impede agile, a new operating model must be defined. Business was done a certain way in the past and the old operating model supported it. Now, organizations want dynamic funding. Teams want to be self-organizing, with the autonomy to prioritize products and key deliverables. Success and contributions to team are now measured by key results of the product team.

To adapt to such changes, the operating model of the old world can no longer be relevant. A common pitfall is to let old culture bleed into the new one, thus using old techniques to solve new problems.

How do you tailor culture into your agile organization?

Organizations should go through an internal discovery phase to identify the kind of agile setup they need and can handle. There are many tools and techniques to dive deep into how the organization currently operates, what its goals are, and the problems it is trying to solve.

What is driving people within your IT organization? Competition, job-security, achievement perhaps. What does being a happy employee at your company look like? How is performance measured? Who is likely to be resistant in leadership and within groups? A detailed assessment provides the planning needed to answer such questions. This proper planning will be fundamental in preventing poor agile performance.

Reason #2: Lack of product-centric mind-set

Organizations often limit the focus of product enhancements to fulfilling the specific feature requirements. This could mean that though the organization has shifted to an agile model, it may still be operating with a project-oriented mind-set. It is imperative to delineate the operational activities that demand a project-oriented approach from all initiatives focused on product enhancements that require a product-centric mind-set.

If the conditions for a particular function are stable and predictable with clear requirements, a detailed list of specifications, and a previously implemented solution, then it is the wrong candidate for agile. Typically, activities in the realm of run-the-business operate in these conditions. Trying to subsume them in an agile framework tailored for product innovation could eat into your resources with little impact on your products.

What is your organization’s vehicle for innovation?

Innovation for an IT group is about providing technology solutions their customers need. Who from your group is sitting down with customers and understanding their experience?

A product-centric approach demands that every enhancement be measured from the customer’s perspective. Customer requirements should be inputted and prioritized by product managers, and design decisions and back-end processes should be left to engineers and designers. Sounds simple, but oh how often leaders and sponsors get it wrong!

Reason #3: The wrong “tool chain”

When switching to be agile, the focus frequently is on changing processes; however, often when these processes change, organizations still cannot see differences made by the switch. Why? It is because of the tools they use. The company’s original tools have been bended and flexed to be agile. However, in order to see tangible differences, tools have to be picked from the ground up.

Finding and implementing tools that are fit-for-purpose exercises the continuous improvement tactic that is at the core of agile.

How do we make sure our tools lead to results?

Even when companies pick the right tools for an organization, personnel often lack a consistent playbook of how to use them.

We have seen that when a tool is used to manage software development, inconsistencies on processes within that tool can lead to poor results. For example, a client using agile development teams did not have a standardized method for assigning story points, determining sprint lengths, etc. How can this organization measure velocity among teams?

Equipping your organization with fit-for-purpose tools is step one, and having a consistent playbook within these tools is an equally important step two.

Pushing to see results

Your company may have tried to implement agile, but to solve for why you’re not seeing results yet, a fresh culture, a product-centric mind-set, and the right tools are three points that should be taken into consideration. Process and policy changes alone will not help you reap agile’s full benefits.

Once these points are addressed, your organization will be able to say, “The smaller cross-functional team delivered 80 percent more than our previous team structure.” Or, “We reduced defects by 45 percent.” Or, “We got to market twice as fast.” It will take a push to drive these last mainstays of agile into the fabric of your organization, but to see results, that’s what must be done.

For further reading on agile, please visit: