11

Agile way forward

It is important to ‘think big’, as it gives us clarity over the problem we are trying to solve, the value and benefits that a solution will bring, and we may even have a clear picture of exactly how that solution will look and function. But the world changes every day by the time we have fully implemented that solution, we may be out of date and the problem may have altered its impact to a greater or lesser degree so it is better to ’act small’.

So, what we think, or even know, will work now may not be sufficient by the time we have finished the job. By releasing early work for feedback, we should be able to identify change sooner and respond appropriately, as well as deliver value early.

• Which is the preferred option to take forward?
• Are there any actions to be taken before an option is chosen or progressed?
• What metrics can be used to measure success?

Agile is a test-driven development methodology; it aims to validate success by verifying assumptions and measuring acceptance as early as possible into the creative process. This is achieved by continuous releasing and integration and gaining feedback until a point of satisfaction and success is met. Our work has to integrate with our day-to-day working and improve satisfaction, and so we must understand how our solution integrates into an existing environment in which it resides before we can know if it will be successful. Systems thinking helps us to understand connections and dependencies, ensuring solutions are compatible with the wider environment.

Systems thinking

‘Systems thinking is the process of understanding how things, regarded as systems, influence one another within a whole. In nature, systems thinking examples include ecosystems in which various elements such as air, water, movement, plants, and animals work together to survive or perish. In organizations, systems consist of people, structures, and processes that work together to make an organization “healthy” or “unhealthy”.

Systems thinking has been defined as an approach to problem solving, by viewing “problems” as parts of an overall system, rather than reacting to specific part, outcomes or events and potentially contributing to further development of unintended consequences. Systems thinking is not one thing but a set of habits or practices within a framework that is based on the belief that the component parts of a system can best be understood in the context of relationships with each other and with other systems, rather than in isolation. Systems thinking focuses on cyclical rather than linear cause and effect.

‘SYSTEMS THINKING’, WIKIPEDIA, 2014 (Available under the Creative Commons Attribution ShareAlike License)

Assumption-driven development

When we have an idea about a new project, product, way of working or option that we would like to progress, we can be driven by facts and assumptions. We can interpret what is going to be involved through experience, gut feel, evidence, what we have been told or in numerous other ways.

We need to validate our ideas and assumptions as quickly as possible. We can do this more easily if activity is broken down into slices of work that can be produced, released and integrated quickly to gain feedback and validate the options. This provides a staged release process that provides the opportunity to reflect on the results and make changes, based on our learning before all resources are spent.

Where we are working on something new and unpredictable or uncertain, this experimental approach enables a measured and informed method. Often we have finite resources to achieve an outcome: cash, time, people, equipment, etc., which can deliver the features that will create the value and benefits desired and be accepted as fit for purpose. We can reduce risk by taking an iterative and integrated approach to solving problems and developing new ways of working. The cycle is continuous and aims to achieve continuous improvement through repeating short activity cycles with regular integration, followed with periods of review where we can observe the outcomes and make decisions based on what this tells us.

Test-driven development

Test-driven development is the name given to a method of software development developed by Kent Beck (http://en.wikipedia.org/wiki/Test-driven_development). The methodology is based upon measuring requirements and acceptance through observing outcomes when work is integrated into existing structures and practices.

Performance and progress is measured by feedback gained from testing the solution against success metrics, and used to inform what further work and change is needed to deliver the value needed and fit with existing systems.

This form of decision making requires that those people or activities that use or depend upon the solution are engaged in the development process throughout, providing the feedback and information needed to establish what is and is not effective, and adapt accordingly.

The benefit to continuous testing through interaction is that we can identify practically if the option is viable to progress, and gain feedback to test the requirements and needs rather than accept what has been said is correct and true.

Behaviour-driven development

‘If I had asked my customers what they wanted, they would have said a faster horse.’

This quote reportedly was made by Henry Ford when talking about the adoption of his motor car. The reality of a motorised vehicle was not even an option in his customers’ minds; his product was a new option for travel that he needed to prove was viable and attractive.

What we think we want is not always what we want, because we do not know what we do not know. It is important to test out our solutions on those who will be using them or those who are reliant on them, so that we can observe behaviour as well as listen to verbal feedback to identify if a solution works.

There was a period before the Model T Ford was mass-produced. The first Ford cars were bought by innovators and early adopters who were willing to consider a new and different option. By sharing our solution in the early stages with those who are eager for improvement and change, we can gain the feedback needed to refine and scale our solution to fit. If feedback is sought only at the end of the process, nothing can be done about it. When we are working on something new, we look to make iterative improvements, testing as we go and tweaking our solution as needed to best fit those for whom we work.

A key benefit to taking a test-driven and iterative approach is that value is delivered early, so the user gets to gain value. They also get to see the development of the solution and therefore get accustomed to it more easily when it becomes normal practice, by providing an incremental delivery process. Rather than having to accept and adopt something overnight, the users get used to seeing and using the solution in stages. This means that there is time to absorb and become familiar with the product, and prepare for integration and manage change over a period of time.

Behaviour-driven development is the name given to a method of software development developed by Dan North (http://dannorth.net). The method develops test-driven development as a measure of success further by focusing on needs, benefits and value, as well as the delivery of a specified feature to achieve acceptance. This allows an element of flexibility in how the solution is delivered and enhances the ability for developers to deliver innovative solutions that are fit for purpose and meet the needs of the client. Behaviour-driven development aims to develop working solutions that can be tested for acceptance by observing behaviour.

‘Think big, act small.’