That'll never work!
The current process steps are there for a reason. You can't just get rid of them!
- You can't get rid of business cases - management needs oversight of what is being built
- Teams still have to report what they are doing. But instead of asking permission, they are signalling their intent. Management can intervene if necessary - but if they have to it highlights that there hasn't been good communication on strategy, objectives and business context. Try fixing that first.
- You can't get rid of business cases - management needs to ensure that funds are spent in the right areas
- Teams don't just appear. They have to be created. So instead of funding projects, we are funding teams based on our product strategy. We then set them objectives to hit and monitor their progress towards those objectives.
- This is just a way to get around putting in the due diligence of putting a business case together
- Stream Teams are accountable for product metrics. If they are not delivering then they will be disbanded. They need to put in a lot of due diligence in the Discovery and Design phases to ensure that the product they build will deliver the expected results.
- You can't get rid of business cases - just because!
- Why not? If it is not working we need to change it. "Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. You stop looking at outcomes and just make sure you’re doing the process right.", Jeff Bezos.
- What stops teams from building crazy features?
- Stream Teams report to Product Teams. They have to signal their intent for what they will build, the opportunity that they believe this will address and the results of prototype evaluation. We can trust Stream Teams to build the right thing but that doesn't absolve us of our responsibility to verify that they are.
- You need multiple Stream Teams to build a Product. If they are autonomous you won't be able to coordinate them to deliver on the product strategy
- The Product Team is responsible for defining the Product Vision and Strategy as well as setting the short term objectives for the Stream Teams. If the Product Team shares the context behind the strategy and objectives then the Stream Teams can come up with innovative ways to achieve the goals.
- That's great for separate Stream initiatives but sometimes Product changes require more than just one Stream Team. How do you coordinate them?
- Projects won't disappear completely - there will just be less of them. There are multiple different strategies that Product Teams can use to coordinate multiple Stream Teams that we cover in the courses.
- Teams don't have the skills to do Discovery. They are skilled in Delivery
- The separation of the planners and the doers is what has led to the poor outcomes. If people don't have the skills then we need to augment teams with the people who have these skills and upskill everyone else.
- How can we be sure this is working?
- A good measure of this being better is how many ideas are being killed in the Design phase or how many iterations it takes to agree on a solution. These are examples of things that would have been built and then failed to deliver the expected benefits.
- This assumes that Stream Teams are separate at a code level so they can work autonomously. That's not realistic
- Using Domain-Driven Design techniques and Event Storming workshops we can identify the logical boundaries between Streams. This will allow us to create Stream Teams that are separate at a code level. There will be a need to do some code duplication but the benefits of autonomy outweigh the costs of duplication.
- If you break apart the code then you'll have to collaborate more
- Streams will need to create APIs to share information between each other without needing to introduce a Blocker into the process.
- We can't create a separate, long lived team for each part of our product. That would be prohibitively expensive!
- You don't need a 1-1 mapping between the Value Streams that you identify and the Stream Teams. One Stream Team can own multiple Value Streams. Your product strategy will determine the number of Stream Teams and their size.
- You will still have handovers between the different specialists in the Stream Team so it isn't really ZeroBlockers
- People in the Stream do not work separately. There is a very low Work In Progress limit so everyone works on the same item at the same time. Everyone is learning from customers in discovery, everyone is contributing ideas in Design, everyone is watching customers evaluate solutions to learn what works and what does not, and everyone is involved in coding to learn the challenges and options available.
- Having everyone work together is a waste of time. It is much more efficient to work separately
- That is true when you know exactly what you need to build - unfortunately that isn't true with software. Every study indicates that "teaming" (everyone working together) is no slower than people working separately and it results in fewer bugs. The context that people gain far outweighs the time that they spend together.
- Measuring outcomes is a nice fairy tale but it isn't feasible in the real world
- Indeed, business metrics are too far removed from the scope of most Stream Teams. So that is why Product Teams act as a translation layer between the business metrics and product metrics that the Stream Teams can impact. Once the Stream Teams are autonomous then they can be held accountable for product metrics.
- Stream teams will never be really autonomous - our code base is too tangled. There will always be a need to share code / release together
- Amazon had a similar problem. Some of their Stream Teams spent up to 9 months untangling themselves before they started delivering value. The teams that invested this time wisely achieved much better results. The teams that tried to deliver results while still entangled failed.
- If people are isolated on cross-functional teams how do they learn and improve their craft?
- Enabling teams are responsible for the skills of the people in the Stream Teams. They will need to identify the skills that are needed and then upskill the people in the Stream Teams. This will involve a combination of training, coaching and creating best practice templates and tools for teams to use.
- I still disagree
- Ok - there are alternative approaches. This framework has been shown to work in leading companies around the world but it is not the only way to deliver software. You don't have to use it! But if you want to learn more you can click on the link below.