If you have any familiarity with DevOps before this class, you may have heard one of several myths related to it. One myth I'd like to address in this video is related to the idea of making work visible. At the end of this lesson, you should be able to discuss the importance of surfacing work to help improve workflow, describe methods and tools that can help surface and track work, and explain how to leverage what you learn from surfacing work into effective prioritization. All right, let's begin. Skeptics often say that making work visible really only works in manufacturing. However, I argue that visual displays are just as applicable in software delivery, and when used with other lean techniques, contribute to high-performing organizations. In this video, we'll discuss several approaches to making work visible in order to help teams better understand the workflow of the various projects they're working on. One important aspect of making work visible is capturing all the work that your team is responsible for. Using a KanBan board, can help you capture the work that is happening. In my experience, that can be a whiteboard with sticky notes, with columns for to do, doing, and done, or it can be a digital board. I've used both Trello, and Jira, to capture work tool. I'm not advocating for any particular tool, it's just important that whatever tools or methods you employ, serve to engage teams. So, do some experimentation and find out what works best for them. The goal is to surface the work so flow can be better understood. Using this technique allows problem-solving when teams are overburdened or not meeting commitments. High-performing organizations practice these techniques, so they can handle competing priorities and trade off decisions. The first step though is to make the work visible. Once you've done this, you will start to make observations about the flow of work. You'll see work that needs to be broken down into smaller batches. We will talk more about small versus big batches in a later lesson. Surfacing work will allow you to see if work is not moving as quickly as expected, and that will create an opportunity to ask questions in order to understand what is blocking the team. Before we move on, I just wanted to let you know that Dominica DeGrandis has written a great book called ''Making Work Visible,'' and has done a number of talks about how to make work visible to help with managing conflicting priorities and work in process, also known as WIP. I've included a link to this resource in our module and I encourage you to check out her ideas. In my current role, we have been very focused on how we can understand what I consider to be the number one constraint in any organization, engineering capacity. The first step we're taking is to make the work visible. Most of the teams are already leveraging Jira for their work. So, we had been capturing the team level breakdown of work in Jira. Sorting by features, operational, compliance and risk, technical debt, and unplanned work. We're not being prescriptive about how teams define each of the categories, only that they are tracking the work. We focus on knowing the current condition, reviewing the allocation every month, looking at trends, and ultimately, picking targets. It's about improvement, using the data to inform decisions, and keeping an eye on the percentage of unplanned work occurring. Let me share with you an example of how the data is used to inform decisions. We've had teams with a high ratio of features versus other work, and ultimately, that has resulted in more incidents, and issues with resilience. We can use that data to help with prioritization with our stakeholders. Teams have also asked a lot about why we're tracking the data, and the goal is to reduce burden on the teams. If that isn't the outcome, then we are likely doing something wrong. I also use this approach at Starbucks. We were tracking our work in any detailed way, and it wasn't at all visible. We continue to make slow progress on a major initiative, and couldn't completely understand why. Once we made the work visible for the initiative, and also started tracking our unplanned work, we quickly saw that the unplanned work was causing the disruption to the initiative. We couldn't accurately predict the delivery of any of the initiatives work, because we continue to have team members getting pulled into incident resolution, and discovery activities for other efforts. We knew that work would not go away, so instead, we started planning for the unplanned. We used our past data to predict the amount of unplanned work we were likely to encounter, and place that in our Jira board, so we could get a better view into the future delivery dates. This also helped us with managing expectations with leadership, and our stakeholders. Everytime we pulled a key resource off the initiative, it had an impact on our dates. We use that data to show the value of starting to plan for the unplanned, and resetting the dates based on reality. I expect that most organizations will struggle with this concept. I can say from my experience and from talking to other peers in the industry that you will absolutely get the value from making work visible. It will create a way to manage priorities, and give a clear picture of the work happening within the technology organization. If you haven't done this within your team in any meaningful way before, I suggest you give it a try to see if it can help your organization.
