Don’t Sub-Optimise Your Development

Over the years I have heard different ways of expressing agility in an organisation. Some of the metrics look at how great your organisation is at adapting to change, some look at the process maturity level and others look at velocity. They are not wrong. But they are not the best measure of performance.

Agile principle no. 7 states:

Working software is the primary measure of progress.

So, what does this entail? For starters, it means that your organisation must be set up to develop software efficiently and demonstrate that it works frequently. If you don’t develop, the principle falls. If you don’t demonstrate/deliver, the principle falls.

Optimising for Increased Delivery

If we optimise for increased delivery of working software, we notice that we have to chunk our deliverables into smaller pieces. We have to deliver in an iterative and incremental way. Doing so allows us to add value and demonstrate working software more frequently than we shelve our software and seldomly release. This minimizes the queue of requirements from the customer and reduces the queue of produced software waiting on the shelf.

Lean Software Development Principles:

The whole idea of delaying commitment is to make every decision as late as possible, allowing you to make decisions based on the most current knowledge. Start every development activity just as soon enough information exists to get started. Don’t wait for the details; get everyone involved in figuring them out together. 

Basically, the mentioned principles from Lean Software Development indicate that it’s better to experiment towards a solution rather than spending too much time on early decisions and analysis. Let’s see if we can put the agile and lean principles into play.

Optimising for Delayed Commitment

If we optimise for delayed commitment and decisions we have to shorten the distance between customer, development, and user. Funding the development based on a rough idea, moving the customer and user closer to development, and empowering them with a decision mandate will allow for delayed commitment and join forces in figuring out the solution.

Most development teams work in a constellation where the following flow is identified:

1. The customer communicates a need for changing the software

2. The development team develops the software and deploys it

3. User gives feedback that may result in changing requirements

4. Go to 1

Using various mechanisms we strive to optimise the time spent on development (step 2) and deliver high quality at a high pace. This can be achieved using Scrum, Kanban, or other flow-focused mechanisms. What we fail to do, is to look at the whole development process from customer to user. Often we perform business analysis on the customer side and prepare detailed needs and requirements that are handed over to the development team. The development team iterates on the needs and requirements and delivers increments as fast as possible to the user. The user gives feedback that is handled by the development team or customer.

Optimising Development Flow

To optimise the whole development flow, we must consider business and IT agility as a joint effort and not two separate activities. Looking at the diagram, one should find the sweet spot where lead time is sufficiently low while output has a sufficient value to the customer and user.  Low lead time is not a measure that can stand alone, just as delivered value cannot stand alone. Take a look at our Agile Playbook for ideas on how to start optimising today.

Try to experiment with different approaches to reach the sweet spot in your organisation:

1. Have customers, users, and developers work together daily throughout the project

2. Reduce the time spent doing business analysis at the customer side and start development sooner and adjust swiftly after user feedback