Moving Towards Continuous Delivery and a Better Agile State
For almost two decades, agile and continuous delivery has had much focus in the software development business. Many startups are founded on an agile culture of prototyping and experimenting until a sellable product or service emerge. For older software development companies, it has become a new way to revolutionize the business and deliver more “functionality” faster to get happier clients. The agile tools no matter framework, are easy to implement and use – only a few artifacts that are easy to understand.
By Jan Mikkelsen, Manager I 25th June 2018
Applying the Agile Mindset
Applying the agile mindset is much more difficult. Companies with a lot of history and culture often struggle to turn the ship and leaving old and “proven” virtues: “Nothing is stronger than habit.” [Ovid]
When you have applied an agile framework, how do you make sure your organization move closer to an agile mindset?
A lever to pull is measuring your development team on agile behavior; you will get what you measure (and maybe you will only get what you measure, but that is another discussion topic).
In the following I will try to discuss a couple of agile measures fairly easy to implement, but hopefully will get you and your teams to move towards a better agile state:
1. Burndown chart
A burndown chart shows how many of the User Stories/tasks of the team-committed delivery has reached the state “Done” (The existence and usage of a Definition of Done is important).
A burndown chart can show under/over commitment of the team, scope changes mid-sprint and other types of anti-patterns, so the team has to focus on a steep decline of task during sprint to ensure a trustworthy velocity of delivered stories/tasks.
The velocity is important for planning purposes and create a predictability and transparency in delivery.
SEE ALSO: Being Agile? Really?
2. From Idea to Delivery
When an idea emerges, start the timer, and stop it again when you have tested if the idea is good or bad.
An idea in this context has a wide definition – it can be the implementation of a User Story, or test if a new business idea will fly. No matter, the importance is the focus to minimize queue time in all phases to get the idea create value for the client.
3. Build break time
How long time is a build broken?
The first step towards deploying code is to have a build. To be able to deploy new features continuously, it is essential to be able to produce a build at all times. Tracking how long time we are not able to create a build is one of the first measurement to focus on and should be the first priority of any team to fix if broken.
4. Reported Defects
If a bug in a feature is discovered in production that has been reported done by team, we want to track them. A bug found before the “Done” state is not really a defect, but merely unfinished work.
Shipping defects into production is not good, and they should obviously be avoided. Everyone involved in software development know we create defects when we develop, but we can become much better at making sure our quality is better. So, the default reaction to bug in an agile world is if the defect is important enough, to put energy into fixing the defect and create automated tests that will ensure it will not happen again.
5. From check-in to test-ok
To make the team work as efficient as possible, it is important the developers get fast feedback of code created. At the latest when code it checked-in it must be tested to a good level of confidence. To have a full-confidence test will probably be very time-consuming and the developer will have “forgotten” what they checked in. Aim for a simpler, but still solid test that may take a few minutes to received feedback from.
There are a lot more measures that could be applied – but the above measures create a good start and will get your team on the right track.
It is important when you try to improve these measures, you might have to rethink the fundamental governance and organization of your software development framework. Have you considered to create your infrastructure as code? Are your test cases checked-in with your code? Can you create a cheaper and better development environment by leveraging cloud technology? Get your development and devops teams started to bring you to the next level of agile.
Jan Mikkelsen, Manager
Jan Mikkelsen has since 2000 been working with development and implementation of wealth management software and translation of business challenges into digital solutions for financial institutions globally. Jan has comprehensive experience as a consultant, implementation of software, hereunder agile/SCRUM facilitation, as well as optimizing work processes for the financial businesses around the world. Jan has a broad understanding of businesses and a system related understanding of Front, Middle and Back Office, with agile facilitation, and automation of processes, data, system selection and solutions as primary focus areas.
Read more about Jan and our other consultants here.
