Jamie Arnold has been part of GDS since the very beginning, working on the early stages of GOV.UK and many other projects since.
Back in February this year, he posted a drawing that sums up his experience of agile service delivery. We’ve re-posted it above, and you can see the full-size original over on Jamie’s personal website.
As part of this week's focus on all things agile, we asked Jamie to talk us through what the drawing means. In this short audio interview, he talks about the importance understanding user needs, iterating as you go along, starting with a small team, and much more besides.
Join the conversation on Twitter, and don't forget to sign up for email alerts.
Transcript
Jamie Arnold: This is an illustration of some of the concepts I’ve used in the past to deliver services for government using Agile techniques, i.e., iterative and incremental delivery of software and service.
Interviewer: What are the different bits of this? Can you take us through each one as briefly as possible?
Jamie Arnold: Yes. So, it’s trying to say the importance of a clear and inspiring vision with a set of goals that describe an outcome rather than a set of deliverables. It’s suggesting that drawing that service, drawing the thing, is a really useful technique to help align your stakeholders and team around a vision, and a service delivery. And it tries to describe how using user needs and the language of service capabilities can help you understand, and deliver bits of that service incrementally in alpha, beta and live stages. And then it makes the point about, you should be careful about growing your team. Don’t throw people at the problem because the problem won’t be solved that way. In other words, start small and grow organically.
Interviewer: You’ve drawn this down on a single sheet as a summary, but I’m trying to understand where it’s all come from. How did all of this get into your head?
Jamie Arnold: It’s through experience of running different types of teams within government. So for example, GOV.UK, it was mostly a software programme but there were other aspects to the service that was nothing to do with the website. For example, a service desk where people send you an email saying, “I don’t understand this or this is wrong, or can you help me with this?” And so a real person responds better to that. That started me thinking that we should be using Agile not just for software delivery. There’s lot of non-software bids within government services that are good to deliver in an Agile way.
Interviewer: And although this is not necessarily relevant to the picture you’ve drawn, what are the big myths or misconceptions about Agile?
Jamie Arnold: I would say, things like, it’s hippies and sandals, things like there’s no plan. It doesn’t give you the certainty that people are used to with methodologies like PRINCE2 and big Gantt Charts. I think that’s a myth. What other things? Myths that there is not enough upfront planning.
In other words, people are - the focus with Agile is to always deliver something within a short time box, say two weeks. Whereas traditionally you design the system upfront, you hand over a big set of documents and say, “Build this.” And then three months, six months, six years later, something pops out the other end. So I think, yes, the myth is, there’s not enough planning with Agile but I think that’s totally wrong. The opposite is true. There’s more planning in Agile.
Interviewer: But that doesn’t seem to go with the description of Agile, which - Mat Wall's famous thing where he says, “What do you want by Friday and how can we make it better than we did last week?” If it’s myth that there’s no planning, then how do you make the planning happen in Agile? If I’m somebody in charge, where do I get my plan from in Agile?
Jamie Arnold: What I’m describing in this drawing is, for example, rather than have a big plan that designs everything upfront or decides when everything is going to be delivered upfront; you typically have a bunch of deliverables. With an Agile approach you would describe a set of outcomes using a roadmap. So you’d say, “The first waypoint is that we have a service, the core service we can test with 100 testers or 1000 users.” That might be your first outcome you want, rather than say, “The service must have this deliverable or this deliverable.” So you’re describing the outcome, so that is what you plan. You plan for a set of outcomes.
Interviewer: Can you briefly explain why scoping of user need is so important?
Jamie Arnold: Good question. I’m just thinking out loud here.
Interviewer: Yes, that’s good.
Jamie Arnold: I think if you view the service through the eyes of a user, what are you actually, what service are you trying to give to users? If you think about their needs first rather than the organisation, the government’s need, you’re building the right service. So many projects I’ve seen in government and outside of government start with what the business needs and you forget that actually, it’s people you’re trying to deliver the service for. So, a list of user needs defines your scope or your service. Obviously, it doesn’t give you all the detail. You’ve got to work out a lot from this list of user needs, but typically, 80% of users need only 20% of the features of a service, so that’s maybe a clue. That’s where you might start.
Interviewer: What is so good about drawing the thing on the wall? Why does that help?
Jamie Arnold: So this is from experience. I’ve been in teams where someone has been able to say, “Well, I think the service is this,” and they’ve drawn a conceptual model on the wall. It’s not necessarily tech architecture or a user journey, or a mock-up of a user interface. It can be a mix of loads of things.
If you start with that, people go, “Yes, I can see where we’re going. I know what this service is. I don’t know the detail of it but I can see the breadth of it. I can see that it’s not just a website. There are phones involved. There are trucks delivering piles of paper to and from, let’s say, DVLA or something like that.” You can see the breadth of the service in all its parts.
And I think that helps teams say, “We’re doing this,” pointing at a wall and saying, “We’re doing this bit.” You can create your user stories from that. If, on the other hand, you don’t have a drawing, you’re always trying to describe the service in a list of user stories, a bunch of cards, and that’s just noise. You can’t take in, let’s say, 100 cards, to understand what the service is trying to do. A drawing, a picture paints a thousand words.
So the drawing helps you understand the shape and possibly the size of the service, and that allows the team to all be on the same page. Annual stakeholders, we’re building this, pointing at the picture, and allows you to get the right user stories out. It’s just a - in teams where you don’t have a drawing, you spend a lot of time crafting words on cards or in a tool, and you don’t get the same understanding.
5 comments
Comment by Jamie Arnold posted on
Hi Charles, I've been in this situation and drawing a pic was still invaluable. Share it via email, Slack, on a wiki... Still helps increase understanding and is usually better than words.
Comment by Charles Roper posted on
If you have, or are part of, a remote team, what would be an effective alternative to a picture on a wall?
Comment by Rob posted on
Great insights. Really helpful that you share this look into your process.
Comment by John Fitzpatrick posted on
Super blog so helpful to help articulate a service vision and delivery plan to a non agile SRO and team. It's hard to do - sharing your experience this way accelerates our delivery - thank you 🙂
Comment by Brian posted on
Jamie's views are hugely valuable and grounded in real experience. If you get a chance to see him present this in person, take it! - he's an entertaining speaker as well!