This week we are back to our read of Commitment – Novel about Managing Project Risk by Olav Maassen, Chris Matts and Chris Geary (2nd edition, 2016) . Chapter 4 introduces more agile techniques, including work visualization, staff liquidity and a focus on outcomes.
Chapter 4 begins with Rose and Gary building an initial visualization of the process they follow to develop functionality. As a practitioner, this step is often easier said than done. Even if each person in the process knows the part they play, it is often hard to see the big picture. The act of visualization often educates the entire team and identifies gaps in the process (something that occurs later in this chapter). After Roses uses the wall as a big kanban board, she had the team go through the process of adding all the tasks they are working on and the current state the tasks are in. Then they flagged the blocked items. The raw number of items in the process and blocked paints a startling picture. Rose recognizes that the team (at her insistence) had focused on starting tasks and features rather than getting them finished. This is a classic IT management problem. There is an emphasis on saying ‘yes’ and starting new work mid-stream, which causes a huge amount of switching between activities when they get blocked or someone asks for status. Both in Commitment and real life, a superior strategy is to change the focus to completing work before starting new items. The focus of working on one thing at a time until it is complete is a common theme in lean. Reducing the number of tasks a person is working on tends to reduce switching and waiting time which improves throughput. This is the same principle Goldratt identified in The Goal. In Commitment, Rose has the team move all items on the wall that are not being worked on back to the “ready to be worked on” column.
As the team gets comfortable with work visualization and being actively involved in controlling the flow their work, the board becomes the locus for conversations. The new level of conversations and collaboration disrupts the concentration of those in cubes close to the board. Rose fixes the noise issue by giving up her office and rearranging the workspace so that the team can meet and hold discussions in her “old” office. The new location of the team’s board allows people to congregate and interact with the board without disrupting the people trying to work. Rose giving up her office and moving into the common team space is a reference to how Agile and lean techniques lead to a flattening of the organizational hierarchy. Flattening is a natural outcome of moving decision-making to the team.
The type of visualization practiced in software development is a combination of process or value stream mapping and kanban. Kanban is a pull-based method popularized by Toyota. The form suggested in Commitment, uses a similar approach described in Personal Kanban by Ken Benson (described in an upcoming SPaMCAST interview). Commitment suggests that there are three states of work shown on the kanban board: waiting, work in progress and done. Team boards often add columns for each specialty in the workflow or different classes of service (different types of work). Kanban defines a blocked item as anything that is waiting on something or someone. Kanban focuses the team on minimizing both multitasking and constraints which maximize the flow of work to completion.
During an explanation of the new management techniques Rose is using on the project to management, Rose is confronted with a new problem. Even though development is delivering more work to the test group, the users are not seeing the software in production. As Goldratt predicted, solving one bottleneck often allows another to emerge to take its place. In this case testing (QA) is the new bottleneck. In order for the whole team, including QA, to understand the problem, Rose has the QA function add their work states and tasks to the kanban board. Visualization exposes the problem that development is delivering work to QA faster than they can test, creating a backup. Now that development is actually completing work, QA has a staffing problem. Discussions of the QA problem leads to the introduction of the concept of staff liquidity. Staff liquidity means that people move between roles to address bottlenecks. People pick up tasks based on the team’s need, their capability and capacity. In order for people to be able to move between roles to solve problems, the project needs to recognize the problem and then have spare capacity to address the problem. Organizational theory has caused most IT teams to build hardened roles into team structures, which make staff liquidity difficult. Breaking those silos requires adopting an Agile mindset both at the team and management level. The discussion of staff liquidity foreshadows a later discussion of how planning 100% utilization of personnel reduces staff liquidity.
Using the concept of staff liquidity, two senior resources, Steve and Gary hand off their work and chip in to help the QA group try to catch up. Development’s participation in the testing process generates a realization that testers need to have more background on the software to test effectively. The testers need more information and support from business analysts (BA) to understand the specification they are receiving from the developers. Rose needs help getting her head around the BA issue. In order to find help in the BA space, Rose reaches out to Lily who connects her with a new mentor, Magnus. Magnus challenges Rose to consider idea that what stakeholders want is value, not a project or even specific features. Magnus uses Rose’s request for tea to point out that what people ask for is what they value not specifically what they want. In the book, Rose asks for tea, not a tea bag, a cup or even hot water. The drink is what Rose values not the components. Every team has to learn to continually ask is “where is the value?” The value does not come from inputs or outputs, but rather outcomes. Focusing the client on describing the outcomes they want allows the team a wide range of options for creating the outcome (back to real options). Commitment suggests that starting with the outcome, which is the end of the value chain, allows the team identify the assumptions they are making to deliver outcomes. For many years, one of the mantras in IT is that the user should define what the project should deliver while the developers provided the how. The conversation on focusing on the outcome is a refinement of what most developers have known and fought for years. When Stakeholders tell you how to deliver what they need, it reduces the options and value that development can deliver. Magnus culminates his conversation with Rose by adding that a team should never commit to a course of action early unless they know why they are making that decision. The team that only makes commitments when to know why is a team that makes commitments when they have the necessary information for making a good decision.
Chapter 4 ends with an entry from Lily’s blog. The blog is a discussion about value and hunting value. Hunting value requires thinking about your stakeholders and their needs (this is the concept of customer focus that Gene Hughson has discussed on the Software Process and Measurement Cast 365). Hunting value means measuring everything.