Business transformation using scrum

‘Everyone gets everything he wants. I wanted a mission, and for my sins, they gave me one’

Captain Willard, Apocalypse Now

My mission for 2018 has been to take on the leadership of a bunch of new teams in the wake of a major restructure, and to get them up and running in a completely new service model, delivering the potential efficiencies that the new structure affords – and it’s been a doozy. This post in no way flags the end of the mission, if anything it is a minor pause in the conversation to reflect on where we’re at now, and consider one possible way of moving ahead – scrum.

I’ve spent today in the first half of a scrum training workshop, which has been good so far – not much in the way of new information, but certainly helping me tighten up my knowledge of scrum, and agile methods in general.

The room has been a good mix of IT and business users, but includes lots of people who work in a primarily project context. I really like scrum – I’m currently the Product Owner for the Digital Workplace project I’ve written about earlier and it’s a really good way of working with a dedicated project team – but listening today made me ask some questions about the applicability of scrum in a business transformation context.

Business transformation is something we desperately need to do within all my teams to varying levels, but to be honest, ‘Year 1’ of the new model has primarily been about recruitment, re-recruitment, letting people find their feet in a new structure, and just generally recovering from a period of large change.

But next year we need to hit the accelerator on transforming the way we work and how we deliver services, and the reality is that we need to do it whilst simultaneously doing our service delivery day jobs, sort of like refitting a 737 while in mid air and fully laden with passengers…

Which is where scrum becomes interesting, and I’d love to hear from people who might have given this a try in the past, and how successful it was (or wasn’t).

If I was to break down the work across the seven teams and 100-odd people who make up my collective, I’d break it up into three primary types:

1. Known knowns. Some of the work we do is of a highly seasonal and predictable nature, and there are plenty of big tasks that we can very reliably forecast in terms of their size and timing. This would include the delivery of services that had a known quantum, but also all the preparation tasks that are necessary to keep some of the more variable work as predictable as possible, which leads us to…
2. Estimatable knowns. In addition to the stuff we know we need to do, there is the stuff which we will over time be able to reliably forecast – customer demand. Whether the customers are staff or students, they too are driven by the seasonal nature of Higher Education, and in most cases we can have a pretty good handle on levels of demand that are coming. My first Flinders team – Flinders Connect – have this down to a fine art, and the others will no doubt reach that point too in the years ahead.
3. Predictable unknowns. We can assume some level of ‘predictable unknowns’ (or ‘expected surprises’) as the world around us evolves, whether that be course changes, innovations in teaching practice, changes in technologies, expansion into new territories – whatever. Even though we don’t know when they’ll hit, we know they will at some stage or another.

So far this year we’ve spent a lot of time just learning the extents of 1 and 2, and coping with 3 as it happens.

The problem we have though is that the organisational model relies on a high level of process efficiency, consistency and effectiveness, and right now we’re a long way off achieving that goal.

And yet we have made progress. Business Improvement projects run by the IT area have helped address specific pain points in specific processes, working one-by-one during the year. Some teams have had the headspace to take on small improvement projects, and have done their best to share their improvements with the other teams. There has been plenty of work put in, and full credit to the people involved in making these changes happen – they are definitely, gradually, helping.

What we’ve not had though is any wholesale transformation of the way we work to systematically embed a culture and process of improvement in most of our operations. This is where scrum becomes interesting.

One of the most common ailments I hear from my teams (and others by the way) is that is it extremely hard to free up time to focus on improvement projects when 1 and 2 are hitting, and when the threat of 3 is always lurking in the background. I get that. I feel it myself. This is particularly true in service delivery teams like mine. Customers don’t tend to care that much about internal projects if it interferes with them getting their problem solved in the here and now, so any time which is available to work on improvement projects needs to be leveraged as effectively as possible. 

Customers don’t tend to care that much about internal projects if it interferes with them getting their problem solved in the here and now

My question is this: can we plan and deliver our core business operations using scrum to attempt to balance 1 & 2 work, better manage our 3 work, and use what’s left to ruthlessly pursue improvement projects which will take the pressure of all three?

What could it look like in practice?

I can see in my mind a year made up of twenty-six sprints, neat two-week blocks laid out in front of us for the year ahead.

Each sprint (fortnight) would start not with a team meeting of vague purpose and variable use, but with a sprint planning session. In this session, we’d look at the number of story points we had been achieving in the sprints from late last year, and tweak this capacity based on availability of staff. We’d look back over the past one or two years at the amount of work which was done in previous years for types 1 and 2 work, and we’d use this to identify how much (if any) capacity was likely to be left over for project work.

We’d look at the backlog of stories with a Product Owner (this is a post in itself though on who the Product Owner should be, and why), and define a sprint goal for the time which is left for project work. We’d estimate some of the high priority tasks on the backlog and either allocate them, park them or break them down into smaller stories which could be tackled within the sprint. This backlog would be continually revised and updated, including the type 3 work – the surprises that come out of the shadows and announce themselves with a polite ‘don’t argue’. The team would guide the estimation and commit to focusing energy on these tasks in their ‘down time’.

This work would be highly visible. Each team could see what each other team was focusing on, and cross-team collaboration would be seen as a normal part of sprint work to solve a particular goal.

Every fortnight would end with a ceremony – a sprint review and/or retrospective. The results would be published across all teams, the amount of story points delivered both on project and ‘business as usual’ work would be tracked, the latter of particular importance to look back on in future years to further refine the planning process…

But what would it take to make this a reality?

I can see at least three big blockers that would need to be addressed in some way for this to work.

1. How would we create the capability within each team to work in an agile way? Whilst a training session is a good start to raise awareness, it isn’t going to give people the level of expertise needed to make it happen in a team. I wonder if embedding a scrum master in each team for perhaps four sprints (two months) and taking the lead in transforming all work to a scrum model would be the most effective way to do it, and training those in the team along the way about how to keep the process going once they were gone, which leads me to…
2. Who would take the role of scrum master within the team, in addition to their day job? To be fair, the kind of role who would take on the scrum master function would hopefully just be replacing a chunk of their role with scrum techniques, and over time the effectiveness of the process would deliver returns in their efforts. That said, there would need to be a very clear decision about who would take this pivotal role on, and in a way that was sustainable alongside their other work.
3. How would a scrum model work in a matrix organisation, where teams have multiple masters? Most of my teams have me as their ‘hard line’ manager, but a local Director as their ‘dotted line’ manager. How would a scrum method work in this context with two Product Owners? Could it even work?

This will take me some time to think through in collaboration with the Managers of each team. It wouldn’t be easy, it would be more change for teams who have already been through a lot of change in recent times, and I’m not even sure if it would work. That said, if it did work, it could give us a far more predictable, effective and efficient environment with business improvement built in to the culture and operations of how we work.

I’d love to hear from anyone who has led a similar transformation in a non-IT, business-as-usual environment – and lived to tell the tale!