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.

What does this entail? For starters it means that your organisation must be setup 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.

If we optimize 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 frequent than we shelve our software and release seldomly. This minimizes the queue of requirements from the customer and reduces the queue of produced software waiting on the shelve.

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 indicates 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 in play.

If we optimize 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. Customer communicate a need for changing the software
2. Development team develops the software and deploys it
3. User gives feedback that may result in changing requirements
4. Goto 1

Using various mechanisms we strive to optimize 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 is 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.

To optimize 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.  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