How Agile helps deliver innovation

With so much C-level focus on innovation, you could be forgiven for thinking that as long as a business keeps coming up with new and better ideas, success must be guaranteed. What this ignores however, is that you can’t innovate until you execute. It doesn’t matter how many amazing ideas you generate if your organisation is unable to implement them.

It’s very easy in IT to blame ‘the business’ for raising impediments or delaying change. But really, a business must continue to be able to perform and deliver to its clients. Therefore, innovation has to be delivered predictably. And that means IT must deliver professional, quality products. For Agile teams, this need for predictability raises a difficult question: how to resolve emergent design with upfront architecture?

The role of architecture

At its most basic level, architecture is a way of ensuring an organisation is in a position to take advantage of future opportunities. It sets out the technical infrastructure and platforms necessary to deliver what is required now and to provide the flexibility to grow and evolve in the future.

This means it is critical for architects to anticipate. They must see beyond current needs so they can predict the immediate, medium-term and long-term demands that will be placed on the organisation’s platform, its environment and its market now.

Architects take those needs and convey them to the organisation in a form that helps to steer the decisions that need to be made by teams from moment to moment.

The only problem is that most architecture groups can’t move at the speed of development and that can hamper execution.

The execution engine

When an Agile organisation successfully creates a development culture, it soon finds high quality software is being pushed out on a frequent basis. While this is the desired result and therefore good, it also makes it impossible for anyone to predictably dictate the design that must be used.

Predictability comes from the ability to give the development organisation a direction, so teams know they can implement at full speed without incurring problems, introducing challenges or creating huge operational costs further down the track. This is the tension and the balance that comes from the intersection of intentional architecture and emergent design. It is also what fuels many of the ideas around service-oriented architecture and the DevOps microservices mindset which is leading to ever smaller groups and decentralised decision-making around architecture.

Immature Agile organisations typically struggle with architecture because they struggle with looking ahead. They still juggle how much attention needs to be paid to planning and predictability, and how much focus should be applied to speed. This is where a visionary architect can round-out the capabilities of an Agile team. The architect provides a perfect complement to the detail-oriented skill sets of other members, enabling them to better negotiate this balance between intentional architecture and emergent design.

Planning for the big picture

There is another equally important Agile practice that improves an organisation’s ability to execute and that is ‘big room planning’, when everyone involved in a delivery group or a release train is brought together to plan a quarter’s worth of work.

Organisations new to Agile often resist big room sessions due to concerns about cost. Specifically, they worry about the cost of travel, the cost involved in tying up so many people, and the cost incurred through distraction to the business. It’s an understandable reaction because the upfront investment in bringing people together can look big. It’s much harder to see the downstream benefits until you’ve actually executed the event.

However, these planning sessions are invaluable for setting priorities, as well as identifying and mitigating risk. Once an organisation has undertaken its first big room planning session, the benefits usually ensure such events soon become a regular feature on the calendar.

Planning doesn’t preclude continuous delivery
Having extolled the virtues of quarterly planning, it’s important to point out that this doesn’t mean you can’t work to a continuous delivery model. Planning answers questions such as: What should we be working on? What’s the next right thing to do? What do we need to know to get that done?

It’s an activity that reminds everyone what the goals are and identifies ways of accomplishing those goals. It helps to align the organisation.

Continuous delivery is what happens once the ways of accomplishing those goals have been identified. It occurs when priorities are set and a fast response is required, and is part of the execution. To know whether your continuous delivery efforts are on the right track, you need to measure results. Fortunately, Agile projects tend to be awash with metrics.

To my mind, perhaps the most useful metric is lead time. Start by measuring the time required from identification of idea to feature delivery, business implementation and revenue recognition. After all, this is the number one goal for most organisations. If your Agile efforts result in a faster cycle, the business is likely to be very happy and you’ll know you’re successfully navigating the divide between innovative ideas and execution.