Considering whether Standard Work has a place in Agile Software Construction

While just a teenager, I learned from my father, that in a trade, you need to do your job as efficiently as possible. For some jobs, people have already figured this out and we can learn from their experiences rather than reinventing the same process over again. My father was a bricklayer, and he taught me this trade, so I also know these lessons from first-hand experience. Economy of movement is the single most important success factor in any of the building trades. The trade has collectively learned these tricks and they teach it to new craftsmen through apprenticeship. The bottom line is you have to produce to stay hired or in business. Your competitive advantage comes from your discipline to do quality work as efficiently as possible.

The software business different in that technology is constantly changing out from under us. It’s much harder for us to recognize the emerging patterns that allow us to do work in the way that has worked best for others who came before us. The patterns movement is an analog to the apprentice program that tradesmen have used. The key point about patterns is they are developed and shared using the scientific method. This means observing what works, hypothesizing why, testing the hypothesis in your work as well as others, making refinements based on experimental feedback, and sharing the knowledge with others. This sharing can be both within a company and within an industry.

Unit tests are a practice used by programmers that dramatically increases their economy of movement (which we call velocity). These are shared within the development team but they are poor at communicating outside the team. That’s okay because they serve a purpose only within the team itself. The customer of a building tradesman really only cares about the end result and the price. This shows a clear separation between the tricks of the trade and what the customer needs to know. Clearly, there are standard work rules that have been learned and followed on the team. In both cases, many of the practices are communicated “via word of mouth”. The difference is that the software industry operates in many different contexts and some practices learned in one shop won’t apply in the next.

The key is to learn principles on which the practices can be derived for a given context. One the practices for a given shop or a given job are learned, the job-specific practices should be documented in a way that will be understandable to a new worker taking on the same task. Often managers are the bridge to learning and transferring these practices from one worker to the next. Collectively, as agile practitioners, we have ignored this problem (because it affects the next person and not us). Management should step in and not allow this to happen. The bottom line is not having job-specific learned-practices documented results in a significant amount of waste. Self-organizing teams can usually come up with the right (efficient) practices, but they’re unlikely to communicate what they have learned.

I’ve begun reading about the concept of “standard work” in Lean Manufacturing. The idea is to distill what prior operators have learned about how to perform the work for a specific station into something easy and quick to understand by new operators. (Think of the instructions for how to put together IKEA furniture.) Keep in mind that new things are often learned and that these instructions should be considered changeable to reflect this. A good measure of what constitutes need for improvement is when a change in the procedure will result in value. This could be a faster way to work, a way to check the quality and prevent defects or scrap, or even a safer, or less fatiguing way to do the work. This particular knowledge does not come from the manager, but from the workers themselves.

I’ve seen examples of “standard work” practices when I worked as a member of a release engineering team. We developed checklists for releases to make sure all team members performed tasks completely and repeatably. Many of the checklist tasks were automated but there was still a human performing a sequence of tasks. We did the checklists out of necessity because not following an established procedure resulted in variability in the work output. We had the discipline to solve such problems and share our method with the rest of the team. I’m hoping that you will think about the work you do and find ways to share knowledge with your coworkers. This usually results in greater job satisfaction as well as improving the bottom-line for your company. If you are a manager: do the jobs performed by your team. Use this as an opportunity to share learned knowledge among the team. Be appreciative of what you have learned and find ways to show the team how sharing this knowledge benefits everyone. Once the team has bought in, consider producing pictures, mind maps, or checklists so that everyone can easily remember the current best way known to accomplish each job.

Bob Clancy

http://agiletester.net

Advertisement