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.
Working software is the primary measure of progress.
Software is Your 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.
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
Co-owner of BuildingBetterSoftware
Agile Coach and Trainer
Rasmus Kaae is working world wide as an agile coach, mentor, presenter, facilitator and trainer. As a certified Scrum Master, Scrum Product Owner and Scrum Professional, Rasmus is dedicated to bring Scrum and agility into organisations by having a full stack end-to-end and top-to-bottom approach. He is a member of the national board of Round Table Denmark, and primary driver of an internal agile community in Danske Bank.
You can find more of his writing at agilerasmus.com.