Introduction to Agile Transformation

By Steve Garnett, Business Transformation / CTO, Aquila Heywood

Steve Garnett, Business Transformation / CTO, Aquila Heywood

Agile Transformation, a term that should inspire and describe the metamorphosis of a company into a more adaptive, collaborative and effective enterprise. Unfortunately, Agile is rapidly becoming a swear-word and the word transformation has become diluted to the point of inspiring nothing but cynicism. There’s a lot of hype and not enough substance.

Regardless of what we call it, or how well individual companies are changing, successful Agile adoption delivers higher quality, higher value, customer-led solutions in a shorter timeframe.

A desirable outcome worth pursuing.

It is not a cost-reduction strategy. It is an investment strategy, changing how you do things requires investment - whether in time, resources or capital. If you are seeking cost-reduction, Agile is not a route to achieving that goal.

Effective Change

From my experience, the most successful, sustainable, and culturally embedded transformations need more than passion and determination. They need a single business-defined target metric, organisational alignment and executive sponsorship.

A single business-defined target metric is not an ‘Agile metric.’ Measuring the number of certified Agile people is not a business metric.

The goal of the business should be along the lines of ‘increase enterprise value by x%,’ ‘reduce cycle time to market by y,’ reduce risk exposure across the portfolio by z.’ Adopting Agile approaches is a means of achieving those goals, not the goal itself.

Organisational alignment from the board through the leadership and into the workforce. Changing the fundamental shape of how a company delivers value to customers needs all parts of the business to collaborate; Sales, Marketing, HR, Operations, Technology, Finance - because each area will need to change to a greater or lesser extent. Executive sponsorship is fundamental and having that single dot on the wall (target metric) that we are all focused on.

Initiating Change

As with all change activities, we start with the people and understanding the culture, values, organizational structure, and reward & recognition systems. We need to engage, motivate and inspire on a personal level by understanding the perspectives of each area of the company and introducing regular communication across multiple channels, i.e. face to face, townhall, social, blogs, meetings, events and email.

An Agile transformation touches financial governance, customer engagement, contracts and licencing, portfolio & product management, solution delivery, engineering pipeline, quality systems, infrastructure, service introduction and operations. It introduces new methods, practices, tools and approaches in each of these areas, so we need simple, unifying language.

“Build the Right Thing”

“Build it Right”

“Build it Fast”

Off each of these simple messages, we can hang the more profound change initiatives such as automated testing, DevOps, or engineering practices.

Lean & Value Stream Mapping

The most common driver for the transformations I’ve led has been to reduce the cycle time to market. From idea to the customer, smaller, more frequent deliveries, means a smoother deployment, less operational disruption, less consumer disruption and less risk to the business. It also provides more opportunity for market and customer feedback to alter and improve the product offering.

When you’re reducing the cycle time by 50-90%, you need to look at the problem holistically and using Value Stream Mapping (VSM) is highly effective in both mapping the route from idea to the customer, but also providing measurements and metrics to show where the most significant pain points are located.

Successful agile adoption delivers higher quality, higher value, customer-led solutions in a shorter timeframe

VSM metrics aid in demonstrating the effectiveness of your initiative as you progress.

Product

The changes required within the Product arena are usually the most difficult to achieve because fundamentally we are changing the way investment decisions are made. Rather than planning the scope of investment for an entire year before that year has started, we’re looking to invest smaller amounts more frequently at the point of creation, and adapting the scope to the feedback (or response) to the previous release.

To gain rapid insight into Product adaptation, stronger use of customer forums, product analytics, market analysis, multi-variate testing and beta programs are required to obtain tangible, actionable feedback.

To enable this investment and portfolio flexibility, roles, tools, practices and interactions need to change significantly and involve Finance, Governance, Portfolio Management and Product teams.

Development

Generally, when a company has a vast complex software landscape, people are aware of the legacy problems and are taking remedial steps, that are often palliative in nature. As a metaphor, the problem could be described as finding your basement completely flooded, but with a line of willing volunteers in a row with buckets, emptying the basement to get rid of the technical debt.

Everyone is pleased that something is being done about the problem. Then someone points out that, while it is great that the water is being emptied, no one has turned the tap off!

In terms of a software landscape, this means that software is still being created in a non-disciplined way and so the underlying issue is not being solved. Without changing the skills, processes, tools and environment within which software is created, the organization will end up with the same result.

So how is the tap turned off?

By introducing disciplined programming techniques such as pair programming, continuous integration, clear coding standards with static analysis, gated builds and build monitors for visibility and transparency. It is about treating software development as a value-added activity, rather than a commoditized event to be executed at the lowest cost available. It is about providing development teams with the autonomy, tools and responsibility for producing the product.

Test Automation

The first place to start with an Agile testing strategy is risk. What level of risk exists when deploying your solution and what is the risk appetite for your business?

Once you’ve assessed your risk, you can then look to build a targeted strategy around test automation focusing on security, performance, stress, data, functionality, compatibility, or devices as befits your context. As you execute more frequent releases and monitor the impact, you can adjust the test strategy to protect your customer and operations teams from disruptions to services.

Automation of tests is a fundamental part of reducing cycle time to market, but the use of Behaviour Driven Development (BDD) not only reduces the cycle time, but increases the functional accuracy of your delivery.

BDD put most simply, combines both the specification and the test in a single artifact. Before development on a component begins, the team defines the required behavior of the software in a predefined format (Gherkin). This acts as both the specification of the software and the test to be carried out once it is built. The beauty of the Gherkin syntax is that it can be converted into automated tests using tools such as Selenium and Cucumber, run continuously, and provide the business with not only a continuous check that the product’s functionality is correct but also a living specification of the system’s capabilities.

DevOps

DevOps evolved out the need for the rapid provisioning, configuration and deployment of both infrastructure and software across multiple environments intra-day. Faster deployment cycles required automation, but more significantly, regular, frequent deployments (daily/weekly) required collaboration.

Traditionally, Development, Infrastructure and Service Operations could work relatively independently with hand-offs between each other… however, with regular deployments requiring changes to product software, 3rd party software and infrastructure into operational and customer environments, the need for highly collaborative Development Operations capabilities is required, in order to seamlessly make changes across development, test, infrastructure and service management areas.

Wrap-up

An Agile transformation is a wide-ranging suite of changes an organization makes across all departments to achieve a specific benefit-driven change - ultimately delivering higher quality, higher value, customer-led solutions in a shorter timeframe.

To be successful in adopting this level of change requires significant investment, executive-level sponsorship, organizational alignment, communication and engagement.

It could be argued then, that the frustration around Agile transformations is not related to the methods themselves, but that companies struggle to transform themselves and establish the right drivers, alignment and organizational-will to achieve the goal.