Welcome to part three of Ian’s articles about how we manage your requests and issues: Herding Cats – Release.
There’s a whole industry wrapped around agile software development, continuous delivery, and release cycles. Over the years we’ve revelled in our freedom to push urgent updates to our customers as quickly as it is safe to do so, and it wasn’t until around 2008 that we discovered our ‘process’ had a name – and then we firmly aligned ourselves with the Agile Manifesto. It took a few more years to ‘discover’ Sprint, with the final Eureka moment in 2014 when we married our processes with Jira and discovered the joy of backlogs!
I’m including snippets from the Principles behind the Agile Manifesto throughout because it grounds what we do. Here’s the first principle:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
This is (hopefully) the final part in my series in which I intend to convince everyone that what might look like chaos is actually a well thought out process. My stakeholders include our customers, the development team, and anyone else who is still awake after the first two parts.
Nothing is Set in Stone
The second principle of the Agile Manifesto is to ‘Welcome changing requirements’ – this obviously applies to our software, but over the years our core processes have grown and adapted to both external and internal changes. If I’d been writing this series six months ago we would only have two sprint teams, but this changed dramatically when we decided to hire two new team members who started in September.
Over the years we’ve tried lots of different ways to make sure the P1 Sand doesn’t stop the P3 Rocks, and whilst we like to be firm with our planning cycles we also realise that we need to be flexible with how we release changes to our customers.
Onions
The third principle of the Agile Manifesto is ‘Deliver working software frequently’ – this was easy back in 2004 when we only had a handful of customers, and we were working on just a few big features. These days we have more than 70 customers using the same product, so features range from the boring to the scary, and we can’t just rely on pushing changes while Mike and I are on a train going to a meeting.
To solve the natural conflict that happens between change and stability we’ve introduced a set of processes. These are layered, so that each one supports the other, and allows us to both react to immediate requests from customers, and also commit to a smooth and stable user experience.
We run a two week sprint cycle, we aim for a monthly release cycle, and the most urgent changes are back-ported to the existing release so they are immediately available to customers.
“Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.”
Scrum <> Agile
We believe we follow a concept called Scrum. The ‘scrum methodology’ is a way of dividing changes into smaller chunks of work called ‘sprints’, and defines how ‘backlogs’ and ‘goals’ build together to push the product forward. Agile powerfully emphasises flexibility and adaptability within a project, but without restricting ‘how’ you achieve it. The first concept, scrum, is a way of managing the work; the second, agile, is how you approach the process.
We plan two weeks of work at a time. We look at all the issues our customers have raised with us and agree as a team what we are going to work on. This is a collaborative process between the management team (Mike and me), the support team (Tim, Chris, Ella), and the whole development team. We organise the dev team so that we can effectively work on a mixture of high importance tasks, urgent tasks, and paid work.
Issues that come in during the fortnight are prioritised and categorised. If appropriate they are merged into the current sprint, and affect our goals – both immediate and for the next release.
Scrum Teams
Over the years we have played with many ways to make sure that we progress all the important tasks while still coping with the quick and easy tasks. At the moment we have three distinct sprint teams. These teams directly map to Rocks/Pebbles/Sand, and if you don’t know what I mean by that then you need to go back to Part 2!
Team ‘Rocks’ work on high importance tasks that progress our product in ways that we think are important. For example, we spent six sprints last year looking at cross platform rapid mobile app development. We wanted to see how we can support both IOS and Android in the future, and how we can build small apps that would be a nice addition to the core product. Earlier last year we totally rewrote the User Interface layer of the mobile app so that it was fresher, quicker, and easier to use. We normally have two developers working together in this team on the same project, and we rotate the team members so that everyone can share experience and ideas. In any fortnight this is probably the most exciting sprint we do, and in the long term will have a potent effect on the product – but in the short term there’s often almost nothing for customers to see.
The ‘pebbles’ team is focused on feature changes to our core product. The pair of developers working on this will split their goals between features agreed with our customers, and features that generally improve the performance of MARKUS, or make it easier for the day-to-day team to support our users. If we have agreed to do quoted work, then the pebbles team will deliver it. Just like the rocks team, we rotate everyone through the pebbles so that we get a good mix of ideas and experience.
The final sprint is for ‘Sand’. This is our core day-to-day team and intimately merges the developers with the support team. They all sit together in the office, and the developers on this team have to answer the phone when you call them! All P1 issues land immediately in this sprint, and once all P1s are dealt with we pick the easy wins from the P2 backlog. This split focus on urgent and easy tasks means that we can really quickly deliver benefits to all users – if a bug pops up we can squash it, and if a minor inconvenience happens we can solve it for everyone.
What You See – P1s
All coding issues go through a review and testing process. The highest priority fixes follow the most urgent release process. These typically affect a small number of customers, but in a high-impact way, and we categorise them as Priority P1. The day-to-day ‘Sand’ team will answer the phone, understand the problem, fix, test, release, and notify the customer of the fix.
In June last year we received twenty P1 coding issues – a mixture of bug fixes, urgent coding tasks, and a couple of bits of paid work. These were hidden amongst the 193 P1 tasks for the month, which also included user guidance, free-of-charge, and correcting data tasks. The help desk team and the dev team work on these together which means the development team are constantly working on a wide range of different tasks. The quickest P1 that we fixed and released took just six minutes from the customer phoning us, the longest took us three days to get to the bottom of, and the average fix was released within 14 real hours of being reported.
What You See – Everything Else
Every month we try to do a full release to all our customers, which includes everything that everyone has worked on in the month. This normally covers a couple of sprints, but the process is deliberately flexible. We tag the release with all changes that have passed review and testing, update the release notes, and start the process of pushing it out to customers.
The release notes include descriptions of all the changes, including P1s, and normally we cherry pick a couple of key updates to highlight. If you’ve asked for some high-importance changes then we will probably release that early to you, and then slowly work through all other customers systematically. If you’ve asked for any changes that have made it into the release then one of the team will get in touch to let you know when it is pushed out to you. For everyone else, they are notified of all the changes, and can give us a call to chat about any new features that need turning on.
We manage the whole release process so you don’t need to do anything, and it is in our best interest to get it right. However, we also know that all our customers use MARKUS in different ways – so problems are inevitable. We try not to change how MARKUS works for people who haven’t asked for a change, whilst also allowing for big feature changes. This can sometimes be a tricky balancing act. However, the day-to-day team is always briefed on the ongoing release process, so as problems happen we jump on them to make sure the release works for everyone.
That probably brings us to one of the other Agile Principles – and ultimately this is why we embrace agile development. When something goes wrong, we have in place a set of processes that allow us to fix it quickly.
“Working software is the primary measure of progress.”
Why It Matters
The reason we have a development culture that encourages urgent fixes to be released quickly, and bigger changes to be released regularly, is so that our customers can use and benefit from our product. There’s no point us working on changes that take years to be used, and it is even worse if there’s a problem and we don’t fix it quickly.
Additionally, the best people to tell us how well we are delivering what they need are the users – and they can only see what we are doing if we show them.
“Business people and developers must work together daily throughout the project.”
It’s impractical to have all our users around a big table to discuss all our changes – however, we believe that the release process, the issue prioritisation, and planning framework of sprint working means that we can get almost real-time feedback from all our users on all our changes. This is why MARKUS is focused on solving problems, providing business benefits, and delivering a stable platform. MARKUS thrives on the input from a variety of stakeholders across a wide range of different companies.
I hope you’ve enjoyed this look behind the scenes at how we manage the issues you raise, if you’ve got any questions please let me know!
(If you’ve missed the last two parts of this series about herding cats you can find Herding Cats Part One here and Herding Cats Part Two here…)
