One of the central tenets of agile software development is the ability to quickly respond to change. Instead of planning for months or even years at a time, as was common before agile, many software teams plan in short 2-3 weeks iterations. While that's certainly an improvement, to a much lesser extent there are even more nimble teams that deliver daily.
There are many things that impact a teams ability to deliver quickly. Technical debt, unclear business needs, and constant interruptions are a common few. However, by and far the largest one of them all is not widely recognized. It's all of the waste we have baked into our processes.
Let's examine a typical scrum sprint. The product owner comes up with requirements in the form of user stories. During the sprint kickoff the requirements are reviewed with the team. While many questions are answered during this meeting, ultimately more questions will come up afterwards. If the product owner is not immediately available to answer these questions, it introduces delays in the process. The developer either has to make do with the information that they have, and risk having to go back and rework things, or they will move on to something else.
Once a developer finishes a deployable piece of work, they will hand it off to QA. Often the QA person isn't immediately available to start testing. In the meantime the work sits in a queue until the QA person has the time. Most often issues are found, and the QA person kicks back this item to the developer. This essentially puts the work back into another queue, as in the meantime the developer may have moved on to another task. It's not uncommon to have a single item passed back and forth several times. When the communication is poor, is greatly exacerbates the situation.
Those are two common examples, but there are many others. The dev team hands off their work to a dev ops team for deployment. A UX person needs to review and sign off on the work, similar to QA. A senior developer needs to conduct a code review. A front end developer needs to wait to integrate their code with an API that is being developed by a backend developer. The product owner, or someone above them, have to give final sign off before deployment. All of these hand offs introduce delays, including simply waiting for the next person to become available. And all of these are extremely common scenarios that software development teams face.
Changing gears for a moment, the manufacturing world has dealt with the concepts of queues and delays well over a hundred years. The history is quite fascinating, which I wont be getting into but I encourage you to look into W. Edwards Deming and also the Toyota TPS system. Many credit them with the rapid rise in the Japanese auto industry. In the early 1990s some of these ideas were codified as Lean Manufacturing, with the elimination of waste being a central theme. These concepts can be applied to other fields as well; not just manufacturing.
Coming back to software, while a team member might see the bottlenecks in the system, they often have poor visibility to the larger organization. Even people on the team might not understand the impact that they have, let alone upper management. Lean manufacturing has a way to make these items visible in the form a value stream maps. I plan on going into value stream maps in more detail in a future posting, but here's an example of what one may look like.
Once you have identified the wastes in the system, and measured them, they can be visualized. Having this visual aid will go to great lengths to help convey that change is needed within an organization.
In Part 2 we will examine what a more lean software development process might look like. For now, I'll mention that Kanban is a tool in lean manufacturing to eliminate waste, and is now commonly used in software development. We'll cover more next time, but in the meantime feel free to read up on Lean, Kanban, amd muda (the elimination of waste.)
Until next time; onward and upward!
There are many things that impact a teams ability to deliver quickly. Technical debt, unclear business needs, and constant interruptions are a common few. However, by and far the largest one of them all is not widely recognized. It's all of the waste we have baked into our processes.
Let's examine a typical scrum sprint. The product owner comes up with requirements in the form of user stories. During the sprint kickoff the requirements are reviewed with the team. While many questions are answered during this meeting, ultimately more questions will come up afterwards. If the product owner is not immediately available to answer these questions, it introduces delays in the process. The developer either has to make do with the information that they have, and risk having to go back and rework things, or they will move on to something else.
Once a developer finishes a deployable piece of work, they will hand it off to QA. Often the QA person isn't immediately available to start testing. In the meantime the work sits in a queue until the QA person has the time. Most often issues are found, and the QA person kicks back this item to the developer. This essentially puts the work back into another queue, as in the meantime the developer may have moved on to another task. It's not uncommon to have a single item passed back and forth several times. When the communication is poor, is greatly exacerbates the situation.
Those are two common examples, but there are many others. The dev team hands off their work to a dev ops team for deployment. A UX person needs to review and sign off on the work, similar to QA. A senior developer needs to conduct a code review. A front end developer needs to wait to integrate their code with an API that is being developed by a backend developer. The product owner, or someone above them, have to give final sign off before deployment. All of these hand offs introduce delays, including simply waiting for the next person to become available. And all of these are extremely common scenarios that software development teams face.
Changing gears for a moment, the manufacturing world has dealt with the concepts of queues and delays well over a hundred years. The history is quite fascinating, which I wont be getting into but I encourage you to look into W. Edwards Deming and also the Toyota TPS system. Many credit them with the rapid rise in the Japanese auto industry. In the early 1990s some of these ideas were codified as Lean Manufacturing, with the elimination of waste being a central theme. These concepts can be applied to other fields as well; not just manufacturing.
Coming back to software, while a team member might see the bottlenecks in the system, they often have poor visibility to the larger organization. Even people on the team might not understand the impact that they have, let alone upper management. Lean manufacturing has a way to make these items visible in the form a value stream maps. I plan on going into value stream maps in more detail in a future posting, but here's an example of what one may look like.
In Part 2 we will examine what a more lean software development process might look like. For now, I'll mention that Kanban is a tool in lean manufacturing to eliminate waste, and is now commonly used in software development. We'll cover more next time, but in the meantime feel free to read up on Lean, Kanban, amd muda (the elimination of waste.)
Until next time; onward and upward!
Comments