Distributed Lean & Agile Teams in the Public Sector: Lessons Learned

Editor's Notes

• #2: Inscription on an old globe, now in the New York Public Library Hic Dracones, which translates as Here Be Dragons. The end of the known world. Terra Incognita when asked to deliver on two mandates simultaneously: Transform IT from Waterfall to Scrum, and Move a bunch of IT offshore to save money. Distributed Agile was going to be just a combination of two things I had done very successfully before. What followed was like the middle part of the Lord of the Rings, all darkness, woe and frightful danger. What I found was that I was going into Terra Incognita: distributed agile wasn’t just not recognized by traditional Scrum practitioners; it was actively rejected as a concept by traditional Scrum thinking and writing. So, I had to do a bunch of experiments
• #3: I am going to use the words Lean and Agile somewhat interchangeably in this talk, since the concepts I want to highlight today apply to both, but given the mixed audience we have here today it might be helpful to sort out our terminology first…
• #4: This whole conference is all about Lean, and many of you are more expert on the subject than I am so I won’t go into too much detail on this, but at a high-level we could say that Lean is about removing the 7 forms of waste through Kaizen events. A common characteristic of Lean teams is the use of Kanban boards to organize and visualize work: traditionally this has been done with sticky notes, but there are huge disadvantages to sticky notes when we are dealing with distributed teams, as I will illustrate today. And with Kanban boards, your goal is generally to manage and optimize flow: whether it is for your personal list of tasks, or for your team’s tasks. One of the methods that people frequently use for this is by limiting Work-In-Progress, for example. And the great thing about Kanban boards is that you can do continuous improvement as frequently as you like: you can tweak your process and reprioritize your workload on a daily basis as you deal with shifting priorities and changing resources.
• #5: So, where would you want to use Lean? Lean is a great model where you have new work coming in continuously, for example, when each day something new lands on your plate by way of an email, a phone call or a meeting. Ideally, all the work is roughly of the same size and shape, so it can all go onto the same Kanban board. And if you are working in a team environment, ideally all the work that comes in can be done by your, or someone like you: in other words, anyone on your team could potentially take on a new task as soon as they are freed up from their old task. Of course, if something much larger or very different from usual comes in one day, you are probably going to have to use a different Kanban board to take care of that. As new work comes in regularly, you are going to have to re-prioritize your work frequently: probably daily, sometimes more than once. A new work item may make it to the top of the list, or end up in the middle or the bottom, depending upon how urgent it is. Examples of where Kanban boards make sense are for Personal Kanban, where you organize your personal work load – and maybe give visibility into that to your manager and coworkers, and support teams, e.g. a technical help desk that deals with similar PC support issues all day.
• #6: Here’s a real-life example of a Personal Kanban board: this one comes from Melissa Wideman in OFM, who has organized all of her tasks into a simple online board that she can view in her browser – and share with her manager and coworkers. (We’ll talk more about how she does that.)
• #7: Agile is a similar model to Lean, but it’s roots like in IT rather than in manufacturing. With an Agile model, you have a team that works in project iterations called “Sprints” The Sprints are always of a fixed, usually constant duration: for example, a team may choose to work in 2-week Sprints. The actual duration of a Sprint is entirely up to the team, but 2-3 weeks is generally a good rhythm. At the beginning of each Sprint, the team commits to a chunk of deliverables that called the Sprint Backlog. The key differentiator for Agile vs. Lean is that a Sprint is a protected space: while the Sprint is underway, no one outside the team can attempt to change the team’s commitments. At the end of each Sprint, the team will do a retrospective and look for process improvements, while also looking at all the work that remains and reprioritizing that to reflect any changes in reality that have taken place in the past 2 weeks. So, if Lean is about removing waste, Agile is about reducing the cost of change.
• #8: So, where would you want to use an Agile model? You should adopt Agile in any scenario where the work is new, in other words it is a type of commitment that has never been made before by the team, and consequently the strategy is uncertain. Anytime you undertake to do something completely new, there is really no way that you can have a fixed strategy and a fixed plan: that’s been the basic flaw of the old Waterfall model of doing work, where you tried to define and specify every aspect of something that you have never done before, and then you were judged entirely upon how well you followed the agreed-upon plan, even if that plan makes no sense by the time you finish the project. Unfortunately, government projects are too often associated with these kinds of disasters that are years in the making, even though the flaws in the plan become evident fairly early in the project. Like with Lean, you are also looking for process improvement in Agile, but you are trying to do this on an rhythmic process: at the end of every Sprint you do a Retrospective where you look back and try to understand what went well, what didn’t, and how you could do better in the next Sprint. The cadence of a Sprint also means that work is getting re-prioritized only episodically: during the Sprint you cannot change priorities, so it’s at the end of a Sprint that you get to review all the work that remains, and shuffle it around. So, where would you use Agile? Pretty much for any all software development.
• #9: Here’s real-life example of an Agile project. This board looks a lot like Melissa’s Task List, the Kanban board we saw earlier, but it’s got some critical differences, and the one I want to focus on right now is the list of people who are working on this board. You might recognize some of these names, and if you do, you will quickly realize that this Agile project actually involved people from 8 different agencies, who had to come together to deliver the state’s overall commitment: that someone living in Pierce County wouldn’t inadvertently get sent a bill for King County taxes!
• #10: Distributed teams are everywhere. Historically, they were embraced first in the Non-Profit Sector, before coming to the Private Sector and finally the Public Sector
• #11: Non-Profits have always been what I would call a cottage industry. If you look at the statistics in Washington State alone, there are over 55,000 non-profits, which is an astonishingly high number. And, more importantly, most non-profits are tiny: 80% of them have assets or income that’s less than $100,000 And while you can think of non-profits in many ways, from the perspective of state government they are really service delivery organizations that are sub-contracted to deliver civic services. There are examples of outsourced civic services across the U.S., from literacy programs to nutrition programs to family services. So, how do these tiny non-profits survive and thrive? They do so by getting good at leveraging multiple, transient partnerships. They partner among themselves, with donor organizations, and with the public and private sector to deliver a greater impact than they could on their own
• #12: The Private sector has also embraced distributed teams, and this has largely been out of necessity. This is a fun example of distributed teams: Google and Google’s CIO are on opposite ends of the United States. When Google hired Ben Fried as their CIO, he was a long-time resident of New York, and guess what: he still is!
• #13: Large organizations in the private sector have to embrace distributed teams because, ultimately, no room is roomy enough for everything that needs to get done.
• #14: Anybody familiar with this building? It’s the Department of Ecology – the infamously long building in Lacey, where I discovered, a couple of weeks ago, that it’s a quarter-mile walk from my car to my meeting room.
• #15: And the public sector is undergoing transformation too: At a most fundamental level, unless you work in a really tiny agency you are going to have to work with people located in multiple locations. With budget flat or declining, as far as the eye can see, you are going to have to get better at partnerships, not just across agencies – which, frankly, has always been close to non-existent in the past – but also across sectors. When your budget goes down but your population goes up, and all the citizens continue to demand the same services and even more, you are going to have to figure out how to deliver more with less. Because more is a given, and less is also, unfortunately, a given. And for most agencies, you have field teams to support: 75% of the State Auditor’s Office, for example, is not located in Olympia. And, finally, you need to think about how to deliver on the Governor’s mandate for Telework, because, after all, we all want to have a better work-life balance!
• #16: So, we are looking at a more complex environment, what I would call a model of social collaboration, where you are a member of multiple collaboration networks that are changing. The networks are changing because people come and go from projects and teams. And the projects are changing because you are embracing change: whether it is through Lean or Agile, you are trying to affirmatively deal with changes in priorities and workloads and resources, and to periodically improve your processes, reduce waste, and reduce the cost of change.
• #17: So, if you went down to Cupertino, California, and asked the Jedi Master himself what really matters for distributed Lean and Agile teams to succeed, what might he suggest?
• #18: These are some of the key critical success factors for making distributed Lean and Agile teams succeed. First, there needs to be a way to visualize the work. You need to be able to see at a glance all that’s on someone’s plate, or all that a team has to get done. You need to be able to see this on a high level, and to be able to drill-down if necessary to an individual task or person. But what’s different with distributed teams is that everyone needs to have visibility, not just you. And that inevitably means that your Lean or Agile project board has to be maintained in some way that makes it possible for people to see what’s going on, without having to be in the same room as you
• #19: These are some of the key critical success factors for making distributed Lean and Agile teams succeed. First, there needs to be a way to visualize the work. You need to be able to see at a glance all that’s on someone’s plate, or all that a team has to get done. You need to be able to see this on a high level, and to be able to drill-down if necessary to an individual task or person. But what’s different with distributed teams is that everyone needs to have visibility, not just you. And that inevitably means that your Lean or Agile project board has to be maintained in some way that makes it possible for people to see what’s going on, without having to be in the same room as you
• #20: These are some of the key critical success factors for making distributed Lean and Agile teams succeed. First, there needs to be a way to visualize the work. You need to be able to see at a glance all that’s on someone’s plate, or all that a team has to get done. You need to be able to see this on a high level, and to be able to drill-down if necessary to an individual task or person. But what’s different with distributed teams is that everyone needs to have visibility, not just you. And that inevitably means that your Lean or Agile project board has to be maintained in some way that makes it possible for people to see what’s going on, without having to be in the same room as you
• #35: Here’s another great real-life example of a distributed Kanban team that was working on a cost saving initiative. There were Lean teams located in 25 different locations in Australia and New Zealand that had been trying to collaborate by having a video camera trained at a physical Kanban board in one location. See how little was getting done!
• #36: This is the same team, just a few weeks later.
• #38: By the way, 2 weeks after our initial visit, we went back to DOL to take some more pictures of the Post-It Palace, because it was such a remarkable sight and our initial pictures were a little blurry. This is what we found…