Transforming Delivery With Agile & DevOps - A Test Case

Do you need to transform your delivery capability, but unsure how?

This test case will hopefully help you break down something that is often seen as insurmountable in to something achievable.

Test case.

A large enterprise organisation with multi-channel capability that plays a key role in their future, however online is only part of their business. The organisation are used to buying large-scale enterprise software, as is the case with online. A large, Gartner magic-quadrant eCommerce platform has been rolled out, at much expense. Change has historically performed using waterfall, with a small project taking at least 4 months and costing over £500k. Recently they have been using Agile to capture requirements and to manage development. They are releasing into production once a month, but would like to increase the frequency, weekly would be good, but possibly more frequent than that would be better.

So the problem statement (in User Story format as we are trying to be more Agile) might read something like this:

“As a business, I want to deliver high volume change at pace, so that I can innovate quickly to create a competitive advantage, react quickly to reduce the impact of competitor innovation and to enhance our solution rapidly to delight our customers more frequently.”

This must be business focussed, not technology.

Realistically most people in this position do not know how fast they would like to go, only that what they are doing now isn’t delivering fast enough. This is fine. Do not fret. Start by going faster than you are now and see where this takes you. We believe that you should treat the whole process as an Agile project and therefore you will continually improve over-time. You will quickly find out what works and what doesn’t. We would recommend committing to 9-12 months and continually asses your backlog to see if there is benefit in keeping the transformation team going. The end goal should be for process enhancing changes to be made on an ongoing basis without the need for a dedicated team.

Step 1: Assemble a team. We are a fans of highly capable small teams, so to get us going something like this should be a good start. Scrum Master, Product Owner, Tech Lead, Senior Dev, Senior DevOps and a BA.

Step 2: Discovery.The first goal is to understand what the current processes are from requirement gathering through production deployment and into support. Be sure to record how long things take (in effort and time), along with any issues encountered at each delivery stage. i.e. funding take two months (average), testing takes six weeks (average), three out of the last six production releases have caused serious outages, a production deployment takes ten man-days effort over 48 hours lapsed. 

Write User Stories for specific things that need addressing, these can start at a high level and then be broken down into smaller bite-size deliverables later in the process.

These should cover cultureprocesspeople and technology.Do NOT focus on technology solutions for everything.

If you goal is to innovate quickly, but it takes you two months to secure funding, technology is unlikely to resolve this. If your Operations team are incentivised to keep the site up and are kicked when it is down, do you think that they will want to deploy more change? Culture plays a huge part in the transformation to really delivering at scale. Be sure to focus on engaging with the right people and take them on the journey with you. 

Score yourselves based on existing capability in each areas of delivery, such as culture, testing, continuous integration, code quality, deployment, environment provisioning, change management, etc. Try and agree targets for each components and then use this to give you an overall delivery score. Think of it as an Apdex (https://en.wikipedia.org/wiki/Apdex) score for your delivery capability. You will use these scores to track progress over time when you are delivering the transformation. 

Step 3: Grooming.

Groom and size the back log of User Stories agree on what should be delivered first. Sanity check the team make-up at this point. You may need more automation capability or more developers - this will be specific to what you find. If you have real cultural barriers to encounter you will need to engage with your leadership and possibly human resources to rectify. 

Priorities to get some quick wins under your belt to gain traction, make your stakeholders smile and boost the team's morale.

Step 4: Sprint.As this transformation is being treated as an Agile project - start sprinting, delivering small manageable pieces of the end solution. These might be process, organisation or technology changes. 

Chart your progress on the transformation using the scoring defined in Discovery, as well as the typical Agile velocity reports. Share the progress with your stakeholders regularly. When are you done? That is up for you to decide. But as I mentioned earlier - the goal should be to create a delivery capability that has the processes in-place to allow for ongoing improvements to be made without a dedicated transformation team.

Do not be in a hurry to throw away your existing technology stack. There is often much to be gained before your existing platform is a real bottleneck to achieving  pace. Be tangible - demonstrate how each initiative will reduce time, improve quality or gain other benefits.