Mastering Remote Work: Key Insights for Agile Teams to Thrive in a Digital World

Hello, my name is Martin Henchy Wood. I’m the owner at Naked Agility in Glasgow, Scotland, and I’ve had a couple of questions come in from a few folks, and I wanted to cover a few of those things. So first off, I’m going to be doing this as often as I can. I think it’s important to help people in this time. It can be very difficult to figure out what’s going on and get things done, so we’re going to look at this.

The first thing that I want to talk about a little bit was remote working. A lot of us are in that, if I probably most of us are in that space of having to work remotely. We’re going to be working distributed from our teams, and while we talk about in Scrum and Agile in general, we talk about co-located teams, the reality is when these types of circumstances arise, and even just based on your organisational context, you might work in an organisation that doesn’t have everybody in the same place, and it can make things very difficult.

So while one of the values of Scrum is focus and openness, we are trying to have a group of people who can work together effectively regardless of the context. We need to think about the values we want to have people working together as closely as possible, and obviously in the current context, that closely as possible is over webcam and using video conferencing technology. So we just have to figure that out.

But don’t forget to continuously, and even though we are separated by space and only doing video conferencing, we still need to be able to figure out what the best way to use the tools that we’ve got is. So don’t get stuck on a tool that is not working for you. Make sure you continuously adapt, try new things, figure it out. I did a web conference on Wednesday using Microsoft Teams, and I found that it wasn’t particularly awesome for that setup, just in the way that I wanted to do it. It wasn’t quite working. I’m going to try some other technologies, but I used Teams a lot for other things.

So I think it’s important when you’re remote working to think about how you interact with other people. Are you interacting with your teammates enough? Do they know what you’re working on? Do you know what they are working on? Make sure we have that focus and context to understand what’s going on and what we’re doing. We talked about this a lot in the Professional Scrum Master class. I’m hoping to do some remote PSM once the Scrum community figures out how best to achieve that. We’re going to try some stuff and see if it works. I have a class coming up that I’m going to move to remote, and we’ll see what happens.

So I think it’s also important to think about taking some time, that idea of “poo-poo the chain” while we’re in this remote state, and we maybe don’t have such laser focus on delivering value than we had when we were in person, high bandwidth in person. We can still focus on some of the things that need our help. So in the Scrum world, particularly in all of product development, the work we’re doing is really complex, and it’s not really suited to that production line mentality. But our DevOps pipeline is suited to that production line mentality.

If we want to take an idea from our product owner and turn it into working software, we’ve got that bit that we can’t understand how long it’s going to take because it’s the creative endeavour of solving that cognitive problem. So we’re going to solve that problem, but then we make a change to the software, we commit that to our repository, and then somehow it goes off and ends up in production. How quickly does that happen? And how that is your production line? That’s the bit that we want to shorten and figure out and how to make as fast as possible.

I usually use an example from Brian Harry, who was the product unit manager for Azure DevOps, and he talked about zero build. I think he called it a zero build, an awesome phrase. But he talked about it as if he does our build of the product. So the team creates a version of Visual Studio and TFS at the time, and then they ship it to production. It has to go through a whole bunch of checks. So there was legal, there was validation, there were all kinds of steps along that way. He would look at not how long it took to get through that process because there may be things just now while we’re not so good that would fail, so that’s going to go back into the feedback loop.

So you’re not looking at how long it takes to get your software out the door because there’s some stuff engineering-wise we need to fix in there, and that’s good to disrupt our data. But once we’ve got that version of the product in production, if we do another brand new build from exactly the same version of code that passed all the checks and see how long it takes that to go through the process, that’s your zero build. Zero changes in the code, zero changes in the platform. How long does it take you to get that into production? And that’s your zero build time. That’s what you want to focus on as a production line. We need to make this as short as possible. We need to reduce the process, and in order to do that, you need to get feedback from every stage along the way.

I just found this diagram on the internet that is enough stages that I think was valid. So you need to focus on engineering excellence. You need to focus on improving your definition of done, but also focus on team building. You want your team to care that these things are important. It’s important to get into production as quickly as possible because without feedback, we may not be building the right thing. I need to figure out how to do that, and that means to focus on people.

Something I’ve been looking at recently is how to use extreme gamification to help people understand how to work together a little bit better. Some of those things that I’m trying to get people to look at is through board games. There’s a board game that I had in mind called Pandemic, which is a cooperative game of saving humanity from a pandemic, so it’s kind of apt. But one of the things that you see when a group of people play that game is that it’s very prone to one person telling everybody else what to do, which is kind of analogous with software development.

So if you can get a team together for 45 minutes to an hour to play the game and do a diagnosis at the end, get the team to play the game together and then talk about who you’re observing, potentially as a Scrum Master, and then have a discussion about the different interactions that you saw during the game. You can have that kind of safe environment where you can run a little experiment with your team. It’s fun for them, so they get into it, and they forget that you’re running an experiment because they’re getting into the game and solving the puzzle that they’re trying to solve. But you can have two observations, and usually, you’ll find that there’s one or two people that are very loud. Everybody else follows along. How do you make sure you get everybody’s opinion? Hear the people that are very loud to understand that they’re maybe being overbearing in that conversation.

So that’s part of that focus on people and how people work together. I think cooperative and fun games are definitely a way to help make some of those ideas a little bit more real. I also got a question from one of my old friends, Ian Frame. He was talking about UX in the context of larger organisations and how do you make sure that UX is not just an afterthought?

Now, I’ve worked with the author of Lean UX, Jeff, on this. We have a class from Scrum that is called the Professional Scrum with UX, which he describes as an olive branch to the UX community. The UX community is off doing their own thing because they’re getting pushed away by engineering teams, but really the thing that they’re doing is one of the most important parts of product delivery. Understanding what your product is, what you’re going to do to solve the business need, how you’re going to do that, and how those interactions and behaviours of users that you’re going to change. I think that’s so unbelievably important to a product owner and building the right thing story that it’s going to be detrimental to any organisation that is leaving it behind.

You need to get your UX skills available on the Scrum teams with the people that are doing the work because they are doing work as well. I do think there’s some confusion and difficulty around what happens with long-running work. You might have a bunch of stuff that takes longer than a sprint to complete. So how do we deal with that? The reality is we have that built into Scrum. In Scrum, we have something called refinement, which is that work that the team does on things that are coming up in future sprints to create the most awesome ordered backlog possible, and so that everybody on the team fully understands what is in the backlog that you’re planning on bringing into the sprint by the time you get to the sprint planning session.

In order to do that, you have to spend a bunch of time refining that product backlog, probably looking out into the future. The recommendation is to start with about a current sprint plus two more, whatever that means to you. That might be your effective planning horizon, but really you need to plan as far out as you need to action the things that you find. So if you find you need some extra information or you need to do some paper prototyping or you need to get something in front of users in order to understand better what the need is, you need to know far enough in advance for you to deal with those things.

So how do you do that in this refinement? There’s a lot of UX work working with the product owner and the development team in refinement, just like there’s a lot of security work there. There’s a lot of architecture work, there’s a lot of testing work. All of the skills are required in the Scrum team. So there’s this terminology that I hear used a lot called dual track, dual track Agile, dual track Scrum, dual track UX, whatever you want to call it. People are using lots of different terminology, but the idea behind dual track is not that there’s two separate streams of work. It’s that there’s one development team that moves through different modes for a particular backlog item.

So you get something on your backlog, PBI, product backlog item. It might be a user story, it might be a requirement, whatever you call it. There’s something on your backlog, and it probably starts a little bit vague. So we maybe need to do some amount of discovery work to understand what that item is to get the team up to speed to really focus on and how to bring all of that together. Then that will move into maybe a combination of discovery and delivery. Maybe we’re going to figure out what’s the smallest possible thing that we can build that will help us understand whether to continue to invest in that or that we need to build something else.

That’s that discovery versus delivery work, and then maybe your entire engineering team dives into delivery for the period of a sprint. So we deliver a bunch of things, and then we shoot back up into discovery again, where we’re going to analyse the data that we’re collecting for that. We’re going to look at what our hypothesis was and whether the features that we’ve built have managed to change user behaviour in the way that we expect, create the outcomes that we expect, and then we come up with what are we going to go do next to solve that problem. So that will bring us back down into delivery again. So we keep going through that cycle for a particular idea, and that result might result in many PBIs that are delivered over multiple sprints as we flip between discovery and delivery and somewhere in between.

So the reality is that things on your backlog are not just UX work. They’re not just engineering work, just like they’re not just coding work, not just testing work, not just architecture or security work. Each product backlog item should represent a unit of value, and that unit of value should include coding, testing, security, architecture, as well as UX. So what are the UX ideas you need to do in there? Deciding how much time you want to spend on UX for a particular backlog item will depend on how unsure you are of whether that thing will provide value. Sometimes if it’s just a small, simple, low-risk thing, I would just go build it and see if it’s useful. If it’s a high-risk, big thing, then maybe I want to do some paper prototyping. Maybe I want to do some additional investigation work as a development team around that.

So it’s important that the entire development team is involved in that process. In the Professional Scrum with UX, we focus very heavily on team accountability for UX, but there are many things in UX that you need a significant amount of expertise to be able to deliver on. You need experience, training, understanding within the UX world of many years. So everybody can’t learn all of that, just like everybody can’t be deep security experts or deep testing experts or deep coding experts. You’re going to have deep UX experts, but there is a certain amount of work that makes sense for everybody to help out with.

One of the things we focus on, I have one on the wall behind me, is the Lean UX Canvas. This is from Jeff’s website. This is the second version. The Lean UX Canvas is v5, but it says v2 on it. The Lean UX Canvas helps the engineering team understand the value and context within the work, which they’re making decisions every day on how to build parts of the product. This is a really important tool that I think anybody on an engineering team can learn how to use and utilise, but you still need that deep UX expertise to tackle some of those harder core things that you might do.

So something you should have is all of the things in your backlog should include some amount of UX work, depending on the context. We also talked about emergent design, just like we talked about emergent architecture. A product backlog supports emergent architecture, and that idea is that in sprint one, when you’re working towards your first unit of usable increment, your first piece of working software, at the end of sprint one, you’re going to probably spend quite a lot of time on UX, just as you’re going to spend quite a lot of time on architecture and quite a lot of time on infrastructure. So the amount of value that you deliver in early sprints is probably going to be quite small.

Maybe during the sprint, you spend during your first two weeks sprint, you and the whole team spend four days working on UX. How are we going to build this? What value are we going to get? What user behaviours are we trying to change? That sets you up for the next couple of sprints, where you spend most of your time in that delivery with a little bit of discovery before you need to jump back to food. You’re spending a lot more time on discovery.

So that idea of team accountability, we’re all working together. We are all as a team accountable for users getting the best experience they can, and I think that’s really important. Focus on those behaviours that you want to change in users, and it will help you focus your product backlog as well, working with your product owner. While the product owner is accountable for value delivery, the entire Scrum team is responsible, and we are all in it together. If the product owner is not successful, we’re just as much out of a job as they are.

So I think that it’s important that we all work together to solve those problems. Hopefully, that was a useful, quick dive into those three things. I talked a little bit about remote working and about taking some time for engineering excellence, team building, doing some things around that. I talked a little bit about integrating UX into your overall strategy. I hope you found this useful. Remember the values and principles of Scrum, those ideas of transparency, so we can get those feedback loops built upon trust. In order to get trust, the Scrum community feels the commitment, courage, focus, respect, and openness are of utmost importance.

So if you’re trying to make a decision about how you’re going to do something, especially during this crisis, think about how and how will the way we’ve decided to do something support those values? Do those values kick those values to the curb, or are they going to add to those values and help us create more trust, build transparency, and create feedback loops?

If you want to get in touch with me, you have any additional questions, please do. There’s my email address, my WhatsApp, and my Twitter. You can get in touch with me on all of those places. I’ve done two presentations recently that I wanted to call out. One is an enterprise evolution that shows that you can - which is from the Microsoft story, the story of how the Azure DevOps team of the TFS team went from delivering every two years in a waterfall manner towards delivering to production every three weeks and the improvements that they made. They started back in 2012, delivering only 22 features to production each year, and now they’re delivering over 270 features to production each year. So it’s a big change with the same number of people, and it’s about paying back your technical debt, getting better at working together, improving communication lines, and getting all of that sorted.

Last week, I also did a presentation on detecting Agile BS, which is from the Department of Defense article of the same name, the white paper. I would definitely recommend going and reading Detecting Agile BS and seeing what’s going on there. It’s a fairly awesome article.

Well, thank you very much. I hope you found that useful. If anybody’s got any questions, then please let me know. I don’t see any questions coming in yet. That doesn’t mean they’re not there; it just means my tool might not have been very good at pulling them out. I’m just going to check, and then if there’s no questions, that’s folks want answered. I might well… I don’t see any questions, so thank you very much for having listened to me, and I hope you have a good day and a good weekend. Okay, thank you very much.