In part 1 of my Achieving Flow series, I discussed some of the hidden wastes that occur with most agile projects. Essentially each time there is a handoff in a project, it introduces delays. This includes handoffs to QA, handoffs to DevOps, handoff from a Product Owner (via Sprint planning), or even just handoffs within the team to name a few. These handoffs might just seem like a regular part of the process, but there are ways to eliminate them, and thus save a lot of wasted time.
One concept in agile is to have cross-functional teams. What it means is that, ideally, the team is capable of taking care of a desired feature, from start to finish. If the work requires back end work, the team should have that capability. If a feature requires UX work, the team should have the capability. Taking it a step further, it can encompass DevOps, QA, UX, Product Ownership, etc. After-all those are all roles, not just titles. A developer is capable of learning DevOps. A front-end developer can also focus on UX. Some developers are full stack, and can handle everything from databases to UI code. Quality is something that everyone on the team should focused on, and not just one person. The same is true for adding business value; to some extent it should be everyone's responsibility.
This doesn't mean that each person on the team needs to know everything. Rather, if the goal is having a highly effective team, that team should be capable of handling all of its needs. Some teams may decide to have a dedicated QA member, while others may choose to rely heavily on automated testing. Having a Product Owner being available to the team at all times also reduces this waste. Taking it further, Product Ownership can simply be a responsibility that the team has, and is something it manages itself. (This assumes that the team demonstrates the ability to handle this responsibility.)
There is no single "correct" way, and ultimately what will work best will vary team by team. However, the goal of eliminating the wastes will lead to better results. It can be hard to make a generalized statement, without data from your specific team, but from my own experience it can often reduce the time needed in half, if not more. I also encourage teams, or their managers, to use value stream mapping to help come to their own conclusions.
Having a fully autonomous cross-functional team will certainly help with flow, and eliminate waste. There are also a few other things that can be done to help. Even if the team is 100% autonomous, there will still be handoffs between the team members. Teams often break down a feature into tasks, and have various members work on these items separately. While this practice is fine, I've also seen it cause delays due to misunderstandings on how the different pieces will fit together. If there's a bug, it's not uncommon to see different team members defend their work, and insist that the other developer didn't do their piece correctly.
If a team uses practices such as pair programming, it can help eliminate these issues. Not only that, often code reviews become unnecessary if the team lead was pairing on the code. Code reviews tend to be a form of "QA for the code", and just like regular QA normally come at the end. The more that the team can work together, and have better communication, the better the overall output. I'm a big fan of having the entire team whiteboard a solution, prior to writing any code. The goal is to get a shared understanding, and also through collaboration come up with a better solution than what a single developer might come up with on their own. Taking it to a logical extreme, mob programming, is also a great tool and eliminates all handoffs within the team.
Ultimately the specifics of how a team should function so come down to trying different practices, and seeing which ones work best. One team might be best while mobbing, while another might function best using a combination of pairing and individual work. It's best to try things out, constantly do retrospectives, and consider collecting the data so that it can be measured and represented via value stream mapping.
One last note, I've drawn a lot of inspiration from Woody Zuill, Chris Lucian, and the team at Hunter Industries. Many of these ideas originated from their efforts, and a lot can be learned from studying their practices. However, you'd be missing the point if you simply copy their successful practices. Instead draw inspiration from them, and try one small change at a time and see what works best for your team. There's no single right way to do things; it comes down to what works for you.
Your feedback and comments are always welcome. Until next time!
One concept in agile is to have cross-functional teams. What it means is that, ideally, the team is capable of taking care of a desired feature, from start to finish. If the work requires back end work, the team should have that capability. If a feature requires UX work, the team should have the capability. Taking it a step further, it can encompass DevOps, QA, UX, Product Ownership, etc. After-all those are all roles, not just titles. A developer is capable of learning DevOps. A front-end developer can also focus on UX. Some developers are full stack, and can handle everything from databases to UI code. Quality is something that everyone on the team should focused on, and not just one person. The same is true for adding business value; to some extent it should be everyone's responsibility.
This doesn't mean that each person on the team needs to know everything. Rather, if the goal is having a highly effective team, that team should be capable of handling all of its needs. Some teams may decide to have a dedicated QA member, while others may choose to rely heavily on automated testing. Having a Product Owner being available to the team at all times also reduces this waste. Taking it further, Product Ownership can simply be a responsibility that the team has, and is something it manages itself. (This assumes that the team demonstrates the ability to handle this responsibility.)
There is no single "correct" way, and ultimately what will work best will vary team by team. However, the goal of eliminating the wastes will lead to better results. It can be hard to make a generalized statement, without data from your specific team, but from my own experience it can often reduce the time needed in half, if not more. I also encourage teams, or their managers, to use value stream mapping to help come to their own conclusions.
Having a fully autonomous cross-functional team will certainly help with flow, and eliminate waste. There are also a few other things that can be done to help. Even if the team is 100% autonomous, there will still be handoffs between the team members. Teams often break down a feature into tasks, and have various members work on these items separately. While this practice is fine, I've also seen it cause delays due to misunderstandings on how the different pieces will fit together. If there's a bug, it's not uncommon to see different team members defend their work, and insist that the other developer didn't do their piece correctly.
If a team uses practices such as pair programming, it can help eliminate these issues. Not only that, often code reviews become unnecessary if the team lead was pairing on the code. Code reviews tend to be a form of "QA for the code", and just like regular QA normally come at the end. The more that the team can work together, and have better communication, the better the overall output. I'm a big fan of having the entire team whiteboard a solution, prior to writing any code. The goal is to get a shared understanding, and also through collaboration come up with a better solution than what a single developer might come up with on their own. Taking it to a logical extreme, mob programming, is also a great tool and eliminates all handoffs within the team.
Ultimately the specifics of how a team should function so come down to trying different practices, and seeing which ones work best. One team might be best while mobbing, while another might function best using a combination of pairing and individual work. It's best to try things out, constantly do retrospectives, and consider collecting the data so that it can be measured and represented via value stream mapping.
One last note, I've drawn a lot of inspiration from Woody Zuill, Chris Lucian, and the team at Hunter Industries. Many of these ideas originated from their efforts, and a lot can be learned from studying their practices. However, you'd be missing the point if you simply copy their successful practices. Instead draw inspiration from them, and try one small change at a time and see what works best for your team. There's no single right way to do things; it comes down to what works for you.
Your feedback and comments are always welcome. Until next time!
Comments