Allowing Things to Break
Last year, MasterControl hired some consultants to help us transition to the Scaled Agile Framework (SAFe). One thing they talked about has been on my mind recently. They taught us to allow the process to break. If something isn't done correctly, allow the error to occur and be highlighted in the system. This counsel isn't meant to shame anyone. The purpose behind it is to highlight the areas of the process that need some more work or focus. If we try to hide the errors or cover up things that aren't going well, we'll just end up creating more work for ourselves and slowing down the system instead of speeding it up.
For me, this is difficult to do. In certain situations this can be apparent and it can be easy to follow; however, in a lot more situations, it's not quite as apparent and I normally don't think about it like I should. Let me give an example.
There are a lot of times that the Product Owner will come to a team with an item to consider working on. Many times the team will not think twice about certain parts of it. They'll look it over, refine it, and work on it. However, there are many times when these stories aren't completely ready to be worked on. Instead of not picking the item up, the team either starts work on it regardless or spends the time to get it ready themselves instead of kicking it back to the appropriate group that needs to complete their work on the story. To be honest, the team's attitude is usually a positive one. They want to help. They want work to do. They want the company to win and will try their best to help with that. If that means taking stories like this, then they're happy to help.
This sort of thing seems to happen with relative frequency, but it's not without a few drawbacks. One drawback is that working on stories like this will often cause rework. Whether the requirements aren't clear enough or the impediments haven't all been removed yet or something else, working on a story in this state often necessitates additional work later to build it correctly or causes unnecessary delays to the item while other items are finished.
Another drawback is that it hides potential opportunities for improvement. As previously mentioned, by not allowing the system to break, the real problems and causes are hidden from view. This makes it difficult to make meaningful improvements to the process if the actual process in practice differs from the one chosen for the group. If the root causes aren't known, then any changes or improvements will only be addressing symptoms and not cutting to the core of the issue.
To be honest, this is something I struggle with. I usually don't think as much about the readiness of a story before refining it or accepting it into a sprint. I normally trust the PO to do his job well (and all our PO's are awesome!) but I forget that sometimes they're getting a lot of pressure from other groups to push items through. While I may not need to be particularly picky about every story, perhaps a little more discretion would go a long way in improving this for me. MasterControl has done a great job implementing SAFe but we still have a lot to learn and a to improve. It's been amazing and exciting to be a part of this transformation.
For me, this is difficult to do. In certain situations this can be apparent and it can be easy to follow; however, in a lot more situations, it's not quite as apparent and I normally don't think about it like I should. Let me give an example.
There are a lot of times that the Product Owner will come to a team with an item to consider working on. Many times the team will not think twice about certain parts of it. They'll look it over, refine it, and work on it. However, there are many times when these stories aren't completely ready to be worked on. Instead of not picking the item up, the team either starts work on it regardless or spends the time to get it ready themselves instead of kicking it back to the appropriate group that needs to complete their work on the story. To be honest, the team's attitude is usually a positive one. They want to help. They want work to do. They want the company to win and will try their best to help with that. If that means taking stories like this, then they're happy to help.
This sort of thing seems to happen with relative frequency, but it's not without a few drawbacks. One drawback is that working on stories like this will often cause rework. Whether the requirements aren't clear enough or the impediments haven't all been removed yet or something else, working on a story in this state often necessitates additional work later to build it correctly or causes unnecessary delays to the item while other items are finished.
Another drawback is that it hides potential opportunities for improvement. As previously mentioned, by not allowing the system to break, the real problems and causes are hidden from view. This makes it difficult to make meaningful improvements to the process if the actual process in practice differs from the one chosen for the group. If the root causes aren't known, then any changes or improvements will only be addressing symptoms and not cutting to the core of the issue.
To be honest, this is something I struggle with. I usually don't think as much about the readiness of a story before refining it or accepting it into a sprint. I normally trust the PO to do his job well (and all our PO's are awesome!) but I forget that sometimes they're getting a lot of pressure from other groups to push items through. While I may not need to be particularly picky about every story, perhaps a little more discretion would go a long way in improving this for me. MasterControl has done a great job implementing SAFe but we still have a lot to learn and a to improve. It's been amazing and exciting to be a part of this transformation.
Comments
Post a Comment