5 Things I Learned in a Year Rolling Out Scrum

I've not posted here for a while, because I've been heads down building a brand-new engineering team. This post is about some of the key things I learned from that.

The product I'm responsible for, HCL Digital Experience, came to us as a result of an acquisition from IBM. A year ago, I took on the responsibility to build a new engineering team to work on this product, with the goal of shipping a release within the year. Problem was, there were only a handful of engineers: we had not only to build a release, we had to build a team, and a process.

We achieved the goal. Here are 5 lessons that I take from this experience.

Lesson 1: Go for it, and do it all

When we started out down this path, our lead programmer was the most vocal advocate of following Scrum (and LeSS). He convinced the management team that this was the right way to go, so we jumped in feet first.

We might approach a change like this incrementally, rolling out one bit of the process and then another. I learned through this year that all of the parts of the process are interconnected, they reinforce one another both when they work and when they don't.

By now, Scrum is well proven. I found Jeff Sutherland's book very helpful in understanding the intent of Scrum, and highly recommend it.

When Scrum feels hard, before you blame the process and start to bend or skip bits of it, ask yourself why a particular ceremony isn't delivering what it's intended to. In our case the answer is pretty much always in how the meeting is run, or the content of the meeting.

The ceremonies work if you make sure you really understand their intent and ensure they have the right content. That last part is really important. We found that people were skipping stand-ups because they were just being used for status reporting, or that sprint planning wasn't effective because the backlog refinement hadn't been done properly. It's all linked, and each part of Scrum supports the others.

Lesson 2: Compromises add up, keep count

It's pretty common to hear people say "there are lots of ways to do agile". Approach with caution: that statement usually precedes a bunch of excuses.

Sooner or later someone, including you, is going to want to add a planning meeting, make a team responsible for some component (and hence make a bottleneck), hire testers, have a separate design phase or whatever. You'll figure out a rationalisation that you're really "still doing Scrum".

But keep count, because one compromise leads to another and they add up.

In my team, we made some explicit decisions to subvert our own Scrum processes for a period, because for business reasons we needed our immature team to hit a hard deadline with a specific scope. We didn't kid ourselves that this was somehow still Scrum, because it wasn't. Now we're undoing those compromises, and recognising them for what they were helped us to do that.

Lesson 3: Everyone says they've done agile, few really have

I read this sentence in an actual press release recently "To ensure we kept pace and control we adopted Agile scrum delivery method with 3 sprint teams: design, build and test. Each sprint team providing the input for the other I.e. Design team feeding the build followed by test". Hmm.

Alas this is pretty common. In the last year I interviewed literally hundreds of engineers, and almost every single one said they followed an "Agile" process. After hiring about a hundred of them, I am pretty sure that only a few really did. Pretty much everyone was in the position of the quote above, with specialist teams and a waterfall process organised into sprints.

Don't assume that just because you hire people with Scrum on their CV that they are going to know how to do it properly. You are going to need to educate people.

Lesson 4: People love hierarchy

Scrum is pretty radical in its decentralisation and flat hierarchy. This leads to a management problem that, if I'm honest, I haven't really solved yet.

A lot of people seem to measure their career by a progression in job titles. They want to know how a fully implemented scrum process is going to give them "career progression". You need an answer.

Amongst Engineers, people want to be "architects" or "team leads". This has led to some difficult conversations with some of the more seasoned team members, who want to see their knowledge and experience recognised in formal responsibility for something. We need to divert that into continuous learning and a leadership of a more open communities, rather than formal roles.

For scrum masters and managers it's a bit harder. We don't have programme managers or delivery executives in a scrum organization, and a lot of scrum masters come from a project management background and expect those kind of roles. Being honest, I've sort of dodged this when it's come up, because we've been focussed on building the team, but this post from Mike Cohn contains a lot of what I'll be saying.

Lesson 5: See the wood for the trees

Keeping the backlog straight for a hundred engineers means that JIRA is full of stories, and it's really hard to keep a handle on what people are supposed to be focussed on. There's a lot of content there, and if all we had was the detailed backlog in JIRA we'd be in real danger of losing focus. What's more, the operational backlog is much too detailed for customers and senior executives to consume.

We use a 30/90/180 day view of the backlog and priorities to communicate with customers and with senior executives.

To bridge this gap, I started using a 4-column view of our backlog and priorities, showing items we expect to work on in 30 days, 90 days, 180 days and "later". To avoid this becoming some kind of release planning that commits both time and scope, the later time horizons are explicitly less detailed and less certain than the near-term ones, and we review and update regularly.

Coupled with regular delivery, this helps everyone stay focussed on the overall priorities, and keep our stakeholders on board.

Conclusion

It feels much longer than a year since we started on this journey. We've accomplished a lot, but the next year is where we really make Scrum stick. It's been useful to reflect on what we did, and I hope these observations can help others too.

----

Find out more about my product, HCL Digital Experience, at this site and on this blog.