This chapter of the book talks about the people involved in the system development and the processes that guide their work:
- The value stream
- The key stakeholders
- The process of stakeholders engagement
- The network of stakeholders
As there is a lot to cover in this chapter, I will make several posts to cover it in small batches.
In this post, I will write about the value stream.
3.1 The value stream
The value stream is the end-to-end process, its people (the stakeholders) and the processes that guide their work.
Unlike Ford’s production organisation, where the production pipeline is composed of production steps specialised in only one part of the process, Lean organises around value streams where each value stream takes care of the whole end-to-end development of a specific piece of functionality.
Scrum reflects their Lean organisation with cross-functional teams that can handle all aspects of the product development and a Scrum Master that coordinates the process and has priority in removing impediments.
Stakeholders in the value stream
Both Lean and Agile use the engagement of stakeholders, but in different ways:
- Lean, tells us to only work in what brings value to the end-users, it helps us focus on bringing value to the end-users.
- Agile, tells us to continuously use stakeholders collaboration to make the product reflect what the stakeholders need, along the whole development process, especially the end-user stakes. This prevents rework, it’s eliminating waste, which in turn is an objective of Lean.
At this point it’s important to differentiate the end-user from the customers. A customer is the one who pays for the software being built, i.e.,. a company owner acquires a software, but his employees are the ones who will use the software, they are the end-users and it’s their mental model that we need to capture and reflect in the application.
Architecture in the value stream
Architecture delivers:
- Time: Shorter time between a feature request and its delivery. This is achieved by eliminating rework, which is achieved by creating a form that accurately reflects the end-user mental model of the system;
- Function: helps focus development in the functionality expected by the stakeholders;
- Cost: Using a Lean approach we develop features just-in-time, meaning that feature planning (gathering requirements, etc.) is done just before starting its development, as opposed to a long time before; otherwise the planning might be outdated, and the feature will need rework.
Architecture is about planning for change, and guiding the development process:
- Planning for change is mostly about not making decisions that are difficult to revert, keeping our options open, not adding clutter to the project that would slow it down;
- Guiding the development process is about establishing guidelines that remove repetitive and inconsistent decision making along the development process, as well as anticipating problems in software design.
Lean in the value stream
Lean focus on 3 objectives:
- Avoid waste by producing only what adds value to the stream;
- Reduce inconsistencies by making sure everyone is on the same page, working in the same way, with the same goals;
- Smooth the process by reducing inventory (like documentation and not needed tools or decisions) and “wait” states.
To reach these objectives it tells us to:
- Engage all stakeholders as a cross-functional team, to gather requirements accurately to avoid rework during development;
- Welcome new requirements (as opposed to bad requirements) as a great reason to do rework, because it adds new value;
- Only make decisions in the responsible moment: as late as possible, but not later than that. Planning is needed and good, but too much planning, too long before development, it’s a terrible sin;
- Develop in small batches of functionality, with short feedback loops.
In conclusion:
For Lean architecture and Agile production to work, we must engage the right stakeholders and ensure that the process keeps them on the same page, optimizing value to the end-user.
pg. 41
@hgraca 