Dawn over Lake Erie

Focusing on process improvement is cyclic. During economic contractions, the need to become more efficient and effective at the same time becomes more important because process improvement can have an impact on jobs, budgets, and strategies. That said, process improvement is almost always focused on teams rather than value chains or organizations. In times of economic stress, that team-specific focus usually leave improvements on the table. The three common focuses for process improvement initiatives are:

Team Level:  Teams are the basic unit of agile organizations. Mature teams hold retrospectives on both an ad-hoc and a periodic basis. The act of reviewing how they are working together allows teams to make incremental changes while work is ongoing so that they do not have to make dramatic changes later. While this process is incredibly useful, it does have drawbacks. The most serious is the scope of impact. Teams can really only change how they are working. Those changes may only reflect a local optimization of work that may not impact the overall flow of value or organizational bottom line. 

Value Chain Level: Value chain, a term coined by Michael Porter in 1985, takes a high-level view of how value is delivered by an organization beginning with ideas and raw materials entering the organization to the delivery of the product or service to a customer. A value chain plots a departmental view of transformation and shows the supporting groups that enable the transformation. Agile Release Trains (ARTs) should be (often are not — that is an efficiency problem) mapped to Value Chains. The pro for focusing on change at the value chain level is that optimization is at a larger scale.  The downside is that trying to coordinate and negotiate change across multiple departmental boundaries is more difficult. 

Organization Level: Process improvement initiatives at this level rarely spawn single large scale changes; rather, they provide strategy, vision, and coordination. Having a high-level focus on process improvement delivers support, money, people, and more support (political clout).

I was recently involved in helping implement software testing process improvement in an organization that delivers services. A small part of the organization writes, maintains, configures, and supports software to enable the majority of the firm to deliver services. When we started the discussion there were seven coders and one part-time tester. Coders only coded and testers only tested. The issue was that the coders were creating software faster than testers could test and approve changes for production. The mismatch between the coders and testers was substantial. Over time the answer to the code piling up was to “ship” untested software — ouch! I was called in to facilitate a discussion when the billing software was compromised. The team’s fix was to try to improve efficiency (the term work smarter was actually used). The problem boiled down to a classic work entry issue. The tester was being pressured to continually say yes to everything the coders turned over. Just telling the team to find a way of working faster and better did not fit. 

We shifted to evaluating how the software team was supporting the organization’s value chains (they were new to value chains). The change of focus allowed the software team to better prioritize their backlog to work on items that helped the business deliver more value (revenue and cost reductions). The shift to maximizing the impact of the output of the value chains spawned a number of changes beginning with a shift to two crossfunctional teams (mix of coders and testers) using scrum monitoring throughput and productivity. As the teams were spun up they began using retrospectives to tune their own process which linked the two levels of process improvement. 

In the example, the organization had to make a decision that job titles and department boundaries were not as important as staying in business. The executives provided the vision and push to ensure that change would happen. The vision required focusing on what the organization delivered rather than only thinking about the output of a specific team.