6.1: Continuous Improvement - Video Tutorials & Practice Problems

<v ->Welcome to Lesson 6.</v> Let's talk about continuous improvement as the most important characteristic of agile delivery. In Lesson 1, we mentioned that the roots of agile are in lean manufacturing. Continuous improvement, where kaizan, in Japanese, is the foundation of successful delivery. By continuous here, we mean ongoing. By improvement, we mean positive change. The ability to analyze, find better, faster, cheaper more beneficial ways of working and delivering outcomes and create processes based on these experiments is the foundation of agile mindset. Lean defines continuous improvement as a strategy where employees at all levels work together proactively, and proactively is a key word. And their goal is to achieve incremental improvements in any way that they work. Similarly in agile, a team is continuously improving its delivery, the outcomes, the quality, the speed and the way they work together needs to be improved. The measures of improvement can be quantitative and qualitative. For example, to measure the speed of delivery, agile teams use burndown charts. Let's take a look at it. During a sprint, each team measures its progress towards successful delivery at the end of the sprint. For this, they use the burndown chart which shows how the work progresses throughout the sprint by subtracting the number of story points completed during the sprint. In gray, you can see the ideal burndown line is going down in a straight line from the top left to bottom right, and it's flat on weekends. This indicates a healthy product and well-designed, well-functioning scrum teams. Value is being delivered constantly in a linear way. If the burndown chart is flat, the team is not completing any work. Now let's talk a about an actual burndown chart and how it is created. Here horizontally, we put every day within the sprint. So let us say the sprint for our team has two weeks, which is 10 working days. So these are 7, 8, 9, 10 working days. This is day 10, and this is day one. Vertically, we put whichever way we do planning and estimation. Could be days, could be the number of features. I like to use story points, which is the agile way of estimation and planning. We'll talk about it later, but basically here, we put equal units of scope, whatever they are. And we start with, what did the team commit to? So let us say by using user story points and the team committed to, here is 55 story points. So by day 10, they said they will complete the whole work within the sprint. So this is the ideal burndown chart. So if the team completes work evenly, that's how the burndown would look like, which means by day 10, they have zero units of work left and they fully met their commitment. In practice, it rarely happens this way. Usually in the beginning of the sprint, the team spends some time figuring out what the requirements are, understanding what prerequisites are. So it goes flat but then they start picking up and completing user stories. And ideally they complete the whole scope by the end of the sprint. Let us look at different configurations of the burndown chart. So tell me, how is this team doing? Probably by now you understand this team is not doing well. That was the scope they committed. Let us say, again, 55 story points, and they ended up the sprint by not really completing anything. Let's look at this team. How is this team doing? This is the end of this sprint. This is where they start. And this is their day 10 for a two week sprint. And they completed here. Is it good? You may say, "Yes, that's great. They completed their job earlier." I would just say the commitment was not accurate. They under committed. What happens in this team case? So, again, 55 story points here, data over here, but actually by the end of the sprint, they are still here. Let us say they are 35 story points, which means that they did not commit, complete their commitment. They overcommitted. And we'll look at the percentage of this commitment. Let me take an easy case. Let us say you have 100 story points they committed to, and they completed only eight. In this case, we see their commitment rate is 80%. If they committed only 50, then their commitment rate would be only 50%. We usually see that 80% were higher, ideally to 100 is really good and consistent planning and estimation that is done by this team. And 50% or lower, there is definitely some agile coaching and support from this scrum master that needs to be done for this team. So this is the sprint burndown chart in a nutshell. Many agile teams measure the quality of delivery, such as the number of so called escape defects during a sprint. These are defects that are released into production. The number of defects during the sprint itself is not meaningful since the purpose of the sprint is to establish a cycle of testing, fixing, and refactoring. So any fixes within sprint are completely normal. However, escape defects are not good because they release low quality software to the customer. But also continuous improvement is not just about software delivery. It is about the happiness and cohesion of the team members. Many agile teams measure such as objective parameter. They call it employee satisfaction or employee happiness. Every team member indicates their professional happiness on being part of this team. Usually the scale is 1 to 5 or 1 to 10 and the highest number indicates a team member who grows professional and feels happy about the organization about the team. Basically just enjoys coming to work every day whichever metrics are established, the agile team thrives to continuously improve their delivery. There is concept of vanity metrics in agile. It means that the numbers measured do not really reflect the outcome, such as the absolute number of story points within the sprint. Story points are specific to a team. So one team may produce equal amount of work and 40 story points. Another will take 100. It's not meaningful. However, the progress of a specific team within one year sprint to sprint as a trend line is very meaningful. If they grew their productivity of delivery from 40 story points to 80, their productivity grew by 100%. That's quite meaningful. Instead of quality of delivery or customer satisfaction, some companies focus on the number of lines of code or the absolute velocity of the teams. And those numbers are called vanity metrics. They're not helpful. So it is important for the team to select the right metrics which are relevant to the user and reflect user outcomes. And if they don't do so, you get what you measure. Remember from OKR's theory. In this case, continuous improvement in the wrong direction will only bring the team back. So it is very important for any scrum team or any agile team to select the right metrics and continuously measure it.