Product Development Mechanisms

As leaders of digital product delivery teams we are always seeking ways to improve the throughput and quality of new product features.  We’re also always seeking ways to decrease the amount of waste in the process and empower teams to make the best decisions on their own without requiring a lot of useless management overhead (UMO) in the form of micro-management and status-taking so we can focus on more value-added activities.  In this article, I will discuss two simple, yet powerful mechanisms that can be used to improve throughput and quality while decreasing muda in the development process.

Mechanisms

Mapping your value stream onto a kanban board is a foundational step to help a team to move to a self-empowered pull system.  Adding WIP limits is a good next step to even out the flow of work and maximize throughput.  So what else can be done to further drive out waste in the delivery process? 

“Good intentions never work, you need good mechanisms to make anything happen"
- Jeff Bezos

I have used two very simple, yet effective mechanisms to improve team discipline and help empower teams to make better decisions related to delivering software products.  The first mechanism is tenets, which are basic principles that we all agree just make sense and should guide our actions.  Tenets can be used within multiple contexts for a program.  For example, we may have some tenets that help guide what work we do such as the product management decisions we make about whether to undertake an initiative or feature.  Other tenets may be used to guide how we deliver software, such as constraints or guiding principles for the development process.

The second mechanism is exit criteria, which specify conditions that must be met before moving on to the next activity in a value stream.  Exit criteria serve as checklists to keep the team honest about ensuring activities have been performed with sufficient rigor so as to avoid re-work or other undesirable phenomena later in the value stream. 

Both tenets and exit criteria should, in some way, help to keep the team focused delivering on the team’s mission. 

It is the responsibility of the team leader to initiate the discussion and ensure that tenets and exit criteria get defined.  However, the team doing the work needs to own the responsibility for defining the tenets and exit criteria and agreeing to hold each other accountable to them.  To get the discussion rolling, the leader may suggest some samples and candidates and then step back to let the team work through it on their own and facilitate as needed.  The leader may also challenge the team if any of the mechanisms seem questionable or unclear in their effectiveness or value. 

Once the team has defined an initial set of tenets and exit criteria, they agree to put them into effect, hold each other accountable to them, and continuously reconvene the discussion to evaluate their effectiveness and make changes as needed.  Iteration retrospectives are a good forum for the latter activity, but it’s not a requirement to wait until a retrospective if the team feels immediate changes are needed.

Case Study

I recently helped a digital product development team adopt kanban to improve their delivery throughput and quality.  The team worked stories from the backlog to production using the kanban board below.  We used an acceptance-test-driven (ATDD) model wherein a continuous delivery pipeline (CDP) automated the activities of building the software, deploying the build to test environments, running the tests, and promoting the build to a staging environment for visual inspection prior to production deployment.

(Click on the image to enlarge it)

The following tenets and exit criteria were decided on and posted in the team room so everyone could refer to them.

Tenets

The tenets that the team used to govern the board were:

• The product owner is responsible for ensuring the backlog is always in descending priority order;
• Every activity in the value stream must be performed for every story that gets developed. We don’t skip steps;
• We don’t work ahead on downstream activities in the value stream.  Doing work out of sequence only results in confusion and partially complete work, which results in incomplete value;
• Ready states indicate to the team that the next activity in the value stream is ready to be performed;
• A team member who has the skill set and capacity to perform the next activity in the value stream for a story in a ready state pulls the story from the ready state to the next active state and puts their name on the card;
• When deciding which story to pull from a ready state to an active state, we prefer the one that was pulled onto the board first to ensure the highest priority stories get delivered first;
• When the exit criteria for an activity are satisfied, the team member performing the work pulls the story into the next ready state;
• We never violate the WIP limits;
• A team member may only actively work on one story at a time because focus increases throughput and quality;
• Each team member is responsible for updating cards to reflect work they have started or completed.  Managers will not do this for the team members;
• Once a story is in progress, it may not be interrupted.  We finish what we start;
• Stories are not done until the corresponding software is deployed to production and accessible by users.  We don’t claim credit for undelivered value.

Note that in most cases, we also included a brief explanation of why we follow the tenet.  This is helpful for new team members, and also to remind the team why they made the decision in the first place. 

Exit Criteria

In addition to the tenets, the team established the following exit criteria for the active states on the kanban board:

Observations

Tenets and exit criteria are powerful tools to influence the behaviors of teams to achieve the desired results.

When we first started the effort, team members routinely moved stories into states on the board that were not truly reflective of their actual state.  For example, stories were moved into Ready to Develop before the acceptance test specifications had been adequately reviewed and approved by the product owner.  This caused the board to be unreliable because team members would be working on unfinished acceptance test definition while development was underway.  There was no way to know who was really working on what activities at any given time, which defeated the transparency goal of the kanban board. 

After we enacted the above tenets and exit criteria, the state of the board became much more reliable.  The delivery manager for the team ended up spending much less time micro-managing team members to determine the completeness of their work because the individual team members starting holding each other more accountable.  One impact of this was that the stories flowed from left-to-right across the board with fewer cases of stories moving back to prior states for re-work, thus eliminating a key source of waste.  We also observed a better working relationship between the folks that shared the responsibility for meeting the exit criteria.  For example, the PO, BA, QA troika got to the point where they could get agreement on the acceptance test specifications in a quick 10-15 minute low-ceremony discussion.  

When the product development effort started, team members tended to have their name on more than one story in active state at a time.  This meant that these individuals were attempting to multi-task, and we noticed they tended to become bottlenecks on the process.  We we implemented the tenet stating that each team member could only actively work on one story at a time to keep team members focused on one thing at a time.  This was initially very painful because these people were used to context-switching a lot under the illusion that being busy was the same as being productive.  As it turned out, the exit criteria for the active states actually decreased the tendency for team members to put their name on multiple tasks because they had to put in more focused effort for each story in active state to ensure it was truly complete and wouldn’t move backwards on the board. 

Similarly, sticking to the WIP limits in conjunction with the exit criteria for moving stories out of the In Development state proved to be very painful for the team at first.  Just pulling in another story and working “my part” was a hard habit to break.  At one point the VP of Engineering had to come in and tell the team that in the event of a potential WIP limit constraint they needed to help their teammates working on blocking stories to complete their work.  If that couldn’t be done then they should see if there was anything else they could do to improve the team’s working conditions, even if it meant just getting coffee for everyone.  Once he made it clear that he’d rather have them sitting idle than disrupting the flow of work with WIP violations, they started to understand it was okay to not be “looking busy” constantly. 

Initially, the team also spent way too much effort on validating functionality with automated UI tests when faster, cheaper service tests would have sufficed.  After we added the 80% service to 20% UI testing tenet, tests were developed and executed much faster, and the team figured out how to develop UI tests that focused on specialized UI functionality.  The functional test suite ended up running much faster as well. 

For the first few demos with the product owner, developers were demoing the software from their developer workstations or the test environment.  This resulted in some painful sessions because the software was in a less stable state than was required.  Excuses like “it worked at my desk” were common, the product owner started to lose patience, and the team was embarrassed about the poor showings.  After we added the exit criteria that the product owner inspects the software in the Staging environment, which was just one level removed from production and hence more reliable and stable, demos were much more productive and focused on value added topics. 

The team continued to refine these tenets as they learned more about how to work together as a unit.  As the team adds more automation to the CDP more of the exit criteria will be assessed by the automation tooling.  For example, when the team trusts the CDP sufficiently, the need for manual inspection may go away and the associated exit criteria will either be eliminated or moved to the automated part of the value stream as appropriate. 

Overall, the tenet and exit criteria mechanisms helped the team to establish basic “rules of the road” that served as guard rails to keep their work on track.  It was a small investment to define them, but they continue to prevent a lot of wasted effort and quality issues.   They also played an important role in helping the team to norm as a unit and hold each other accountable.  Using these techniques, in addition to automation, in a 2-3 month timeframe we were able to completely transform the development operations for a team that was used to doing 6-9 month releases to continuously deliver small increments of software to production.

About the Author

Steve Andrews has been leading the development of software systems for over 20 years as a developer, architect, manager, and consultant. He is always exploring new ways to deliver solutions that matter to users in ways that also improve the lives of delivery teams. He is currently helping companies attain product delivery flow and establish tight feedback loops with users using lean product management techniques and  continuous delivery automation.