organization and approach
The role of product manager*is responsible for the overall vision, design,
delivery, return on investment (ROI), and strategic alignment of the soft- ware that is being developed. This individual rarely has direct authority over the entire team, in this matrix management role. The product man- ager guides the life cycle, owns the backlog, and balances customer require- ments and production capabilities, often managing several teams—each developing individual software components toward a consolidated prod- uct. He or she participates in daily standup team meetings and weekly synchronization meetings across multiple teams.
Collectively, product managers are the primary linkage with the enter- prise, synchronizing the pace of software development with changing business requirements and continuous improvement activities. Each product manager (and their delegates) should participate in enterprise- wide kaizen efforts, coordinating IT involvement for his or her particular software product with each business process owner.
Each development team should be assisted by a facilitator* skilled in Lean
software development techniques, and with an objective perspective of the
project. Teams should be kept as small as possible,10,† while representing a
balanced voice of all customers and stakeholders. These multidisciplinary teams should be composed of individuals with complementary skills, where every person on the team has something to share and something to learn from the others.
In the spirit of concurrent development, the entire team (representing all
stakeholders, including the customer) should operate in close proximity,‡
in a space designed to encourage team collaboration and workflow. This is the application of Lean work cell design, where teams are aligned with value streams and supported by pull signals and visual indicators. The organization should avoid shared resources across teams whenever practi- cal, for reasons we explored in Chapter 5. In the case of distributed teams where physical co-location is not practical, virtual collaborative workspaces may be used, but occasional face-to-face meetings are helpful to maintain cohesion and overcome communication blocks. In all cases, team mem- bers should make regular trips to where the customer work is performed (gemba) to reinforce their understanding of customer requirements.
Communications and measurements should be kept as immediate and
visual as possible.§ Visual displays of demand, customer stories, schedules,
project status, priorities, issues, and problems limit interruptions, keeping the team focused on the essentials with minimal communications over- head. Electronic dashboards may be necessary with distributed teams, but in our experience nothing beats the energy of a standup meeting in front of a wall filled with storyboards, butcher paper, and overflowing with colorful sticky notes, index cards, and discount pizza coupons.
requirements definition
The voice of the customer is an essential element in Lean software devel-
opment, as the customers’ definition of value guides all activity. In this
*Other titles include scrum master, coach, and project manager.
†For an insightful look at optimum team size, and why adding more people does not necessarily add value or reduce time and cost, see The Mythical Man-Month, 2nd ed., by Fred Brooks. ‡The venue for co-location is known by many names: project room, war room, bullpen, and Obeya
room.
§This approach is also known as the visual workplace, big visible charts, informative workspace, and information radiators.
case, customer requirements guide the actions of the software development
team. The term customer requirements might be interpreted to suggest
that the customer controls software design decisions, and that there is a separation between the problem, the design of the software, and its imple-
mentation. Consider instead the term design choices, which suggests that
the customer and software designers collaborate to understand the prob- lem and develop countermeasures, which may or may not involve software changes—this is problem solving versus solutions thinking.
First of all, who is the customer? This may be an internal customer,
someone within the enterprise who is processing transactions as part of
an internal workflow. In other cases, the application is used by external
customers, either to support their business relationship with the enterprise
(e.g., order processing or status inquiry) or as a commercially licensed software product. In all cases the software development organization must partner with internal customers, and/or representatives of external cus- tomers, ensuring all requirements are clearly understood and collabora- tively addressed.
The old adage “The customer is always right” doesn’t necessarily apply to Lean software development, at least not early in the life cycle. This is the essential reason for the discipline of A3 thinking, since the immediately apparent “solution” often addresses symptoms, but not the root causes.
The team should therefore respectfully assume that customers may not
initially know what they need, for several reasons:
• Customers may have strong opinions based on an incomplete under- standing of the situation. They often don’t see or understand the entire process, which includes the complexity hidden behind the user interface and buried deep in the database, and the interdependencies with other processes and systems. Comprehensive requirements are thus uncovered by cross-functional teams using tools such as value stream mapping, where the process is understood by everyone. Start
by asking not what the customer wants, but what the problem to be
solved is; this is A3 thinking.
• Despite their dislike for the old system that is being replaced, the customers’ mental model of how the job is done, and how the overall business process works, is based on their familiarity with the current
design. To many business users, the system is the process, and they