In part 1 of Standard work in software development I described what Standard work is and how it is the cornerstone of continuous improvement in Lean. In the post I will describe how a software development team I have been coaching have been using Standard work for a few months.
Context
This is a team that are doing a technology conversion from VB6 to .Net. They are in the process of converting a large number of batch programs with very different properties and implementations. Some are small, some are large, some are quite easy and some are very hard.
The process and visualization
To do the work we have identified some common process states that are used more or less for every batch. We use a Kanban board to visualize how work goes through the process. Below is our board with the process states we currently use.
The process states are written on the stickies at the top of the board and are:
- Prio
- Business analysis
- Business analysis done
- Technical analysis/design, development and functional testing
- Ready for deployment to test
- Ready for System test
- System test
- Done
The Standard work cards
About one third from the bottom of the Kanban board above you can see some white A5 cards hanging from hocks. Below are is a detailed photo of two the A5 cards.
These cards are our Standard work cards and here is an example translated to English:
From Technical analysis/design, development and functional testing
- Code checked in to source control
Should follow defined coding standard and architecture- Code review done
- Database project updated
Changes documented- Test cases should have been executed
All functional tests are green
All automated tests are green
For bugs
Run tests in DST together with the tester- Update requirements document with dependencies
- Update Team Foundation Server
Document all significant changes
Set State/Reason to Awaiting deployment/Fixed
Set Label
Set tester as Assigned to- Notify CM and testers that work is now Ready for deployment to test
How we use the cards
When a team member is getting close to finishing the work in a process state they take one of the card for that process state off the board.
They go thru the checklist ticking the items off.
If there is something on the checklist that is not applicable, it will be stricken.
If there is something on the checklist that is not correct, it will be stricken and a correction will be written on the card.
If there is something missing on the checklist, it will be added by writing the new item on the card.
When the checklist cards are completed they will be collected by the team manager.
If changes are made on the cards the team manager has an opportunity to discuss the changes. If the checklist has to be updated the team manager will update the checklist and print the new version and replace the cards on the wall.
We are making changes to the checklists on a continuous basis. The changes are often initiated by turned in checklists, suggestions made by team members, discussions at the daily standup and at retrospectives.
The evolution
We evolved our Standard work cards from the more common Definition of Done used in Kanban and Scrum. Instead of printing the Definition of Done on the board it self we are printing our Standard work on paper and cut them up to the A5 size.
The benefit of doing this is that every team member can get a copy of the Standard work and have it on their desk as they do the work and checking off the items on the checklist. The other benefit is that we can collect all the changes and corrections made to the cards. These changes are triggers for potential process improvements.
Future improvements
Possible future improvements I’m considering for the Standard work cards are:
- Adding start and stop time for tracking purposes.
- Adding work item reference number for tracking purposes.
- Adding the name of the person performing the Standard work
- Adding Takt time for every process state. This would be the normal time interval that this process state should take. If the time spent in the process state is outside the specified time interval a root cause discussion will be triggered to discover possible process problems or improvements.
Conclusion
You can implement Standard work in something as variable as software development. It is all about how abstract or concrete you get in defining your Standard work. You start out abstract and make it more and more concrete as you learn how your process really works. The most important part is to change the Standard work as you change how you do the work.
Standard work should continuously change!
Standard work is the cornerstone of continuous process improvement, even in software development.
Hakan Forss's Blog 
Hi Hakan,
I understand what you are doing, and yes it is a good idea, but I wouldn’t call it standard work. Here is why:
In the 90s we did something very similar, under the banner of TQM. Teams could create their own local work instructions along the lines of your A5 cards. Having this flexibility was great, until we tried to take things to the next stage.
Standard work is a meant to be a baseline for continuous improvement. It is the best way we know how to do the work today. Best practice. To improve the standard work we would initiate a QIT (Quality Improvement Team) who would perform a 5 step PDCA.
This is where we hit problems. We needed to devise an experiment that proved that our planned improvement to our standard work, was actually an improvement. The variable nature of the work meant that this proved very difficult.
So the next step was to remove the variation in the work. This eventually lead us to PSP/TCP, an invention of Watts Humphreys and the SEI.
Basically for software there is no “best practice”. There is appropriate practice given the problem at hand. I agree there is good practices that one should know, but one also needs to hold on to the beginners mind, approaching each story with fresh eyes, and remembering to think out the box, and introducing novel practice when appropriate.
Your A5 cards can become a thinking trap, with people blindly following what’s on the card, when if they stood back and thought about the story at hand a truly novel approach may come to mind.
We are continuously trying to put software development in a box. I think this is a natural tendency for left brained people. Right brain creative people suffer from this tendency much less. Agile was meant to legitimise right brained pattern matching, where we try to match the problem at hand to our back catalogue of approaches, mixing and matching, and synthesising a new practice taylored to the story at hand.
What I do today is keep track of “the way we do things”either on a wiki or perhaps on an information radiator. I also capture “alternatives” such as concurrent design, more usually on a wiki.
I never refer to any of this as standard work though, because the term just has the wrong connotation for me. Instead I encourage brain storming and thinking out the box. Continuos experimentation and synthesis on the fly, by applying realtime feedback. The out comes of this “making it up as we go along” becomes part of the tacit knowledge of the team. “Do you remember when we tried X, perhaps that would be a good fit now”.
Yes, sometimes it makes sense to make some of this tacit knowledge explicit, but only as a reminder for those who already share a tacit understanding because they were there. Most of the time though we just leave it as tacit, part of the folklore of the team, built up through shared experience.
Thank you for your comment Paul.
I fully agree that there is no such thing as best practice in software development. Standard work is supposed to be your current practice for a team and/or a workflow, not a fixed thing that supposed to be the “best way” for everyone. When you change your work you change the standard work.
In my experience the A5 cards had the opposite effect to being a thinking trap. The physical cards brought the discussions to the surface and we could discuss different options how to do things. The A5 cards had similar effect to the introduction of workflow visualization, like a kanban board. When it is visual, always visible and physical you can start relating to how work works and really discussing it. Also making the A5 cards something you can bring to your desk and use as you do the work really made it work so much better. On the other hand putting your tacit knowledge in a digital system like a wiki, even if it is easy to change, is “hiding” your knowledge. This is my experience.
The improvements experiments that we have run we used end to end metrics to measure the potential improvements. As these metrics by its nature takes longer to change the experiments takes longer to validate. The feedback loop is in days or weeks, not in minutes or hours as it would be in manufacturing. For me the standard work helps the team keep the process more stable and reduces failure demand during the experiments.
I do understand why people can get wrong connotation of the wording standard work. I usually don’t refer to it as standard work when talking to the teams. I usually refer to it as definition of done, process policies or whatever language the team is used to. But when discussing it with fellow process wonks interested in Lean I use it as it is known tool in that context.
/ Håkan
Hi Hakan,
I’m glad you don’t refer to it as standard work. The way you describe it, these are check lists, reminders of “how we do things around here”. Standard work has a more formal meaning. It is best practice. The best we know today, in this context, with the goal of continuous optimisation (improvement) through experimentation.
In a factory this makes sense. Standard work leading to standard results. In a factory, quality is synonymous with a low standard deviation, a standard result. Not so with software. Here we are often looking for continuous adaptation. The difference is between optimising towards the best approach, suitable for repeatable work, and adapting our approach in response unforseable events, suitable for a complex adaptive system, adaptive, creative work.
Beyond the theory, what really matters is what people actually do. I would be interested to hear more about your experiments, and how you improve your standard work. A concrete example would be great.
My guess is that you don’t use a formal PDCA process, with quantitative experiments, but that you mostly use intuition. Another reason why the term “standard work” is a poor fit.
Hi Paul,
You misunderstood me. This is standard work, TPS style, for me. But I don’t use the wording standard work with the teams I coach as it tend to give wrong connotation for them. “How we do things around here” is standard work to me as. This is this team’s current best known way of doing the work in their context. This is what they are actually doing.
In a recent client engagement we did use a PDCA style improvement approach. The process produced quite a bit of rework and failure demand when we moved features to testing. We had a few ideas why but were not sure what would really make the process better. We formulated a hypothesis of what would reduce the rework and failure demand. We then tried the simplest possible process improvement and run that for a few days. We could observe that the amount of rework more or less disappeared and the failure demand reduced as well. We only had a few data points but the results looked promising. We decided to change are standard work and keep monitoring the amount of rework and failure demand. We then formulated a new hypothesis of what would be the next process improvement. We tried it and it did not work as intended and created more work than before without any real benefits to the overall process.
The metrics we used was mainly end to end lead time for this process, the amount of rework (count of rework tickets) and the failure demand (count of failure demand tickets). We also did a very informal assessment of team motivation. The measures are not as exact as it would be for a manufacturing process but we could see the trends and they were moving in the right direction and that is what matters.
/ Håkan
Terminology can be a barrier to communication. Especially when terms gain different meanings over time. I should describe what I mean by PDCA.
When we did PDCA, the problem we had was in the planning stage. Here we had to discover a “signal” that pointed to improvement. Ideally this signal came from quantitative measurements of the system. Lead time, velocity etc. From the signal you then had to come up with an hypothesis, that was supported by the data. An example is “running all units test prior to check in should reduce defect injection rates by X%”. You then would have to devise an experiment to prove your hypothesis. This is the step that killed. How do you prove that?
Once you had devised your experiment, you could then perform it (Do), then measure the results (Check), before acting on the outcomes (Act), which normally meant updating your standard work. “run all unit tests on all check-ins”.
This is somewhat different from a retrospective, where you discuss why things haven’t gone so well, and decide to try things out based on anecdote and intuition. “we had a lot of defects this sprint, I’ve noticed that our check-in discipline is’t what it could be. Let’s run all the unit tests on all check-ins and see how we get on”
These two approaches may sound similar, but in practice they are worlds apart.
In my context, we actually call it “Standard Practice”, because it seems to imply the current state of the practice, rather than the single definitive way of doing something.. However, we’ve run into problems of churn, due to changing things all the time. More here ->
http://controlledagility.wordpress.com/2012/05/14/standard-work-in-software-dry/
Hi Denis,
Standard work is just that, the current state of practice. It is not something written in stone it will change as you do process improvements. Process improvements are something that should be an ongoing activity on a daily bases. Therefor the standard work will also change very frequently.
For me it has been a balancing act of how detailed the standard work/standard practice/definition of done should be. Too detailed and you will get churn. Too little details and people may find it to abstract and no one understands and use it. You need to experiment and see what works in your context with our teams.
/Håkan
Hi D,
Thanks for joining the conversation. Standard work makes perfect sense in it’s native context of production. Standard work, standard practice, best practice, are all the same thing. The “one way” to do something. Even when that way is temporal, context specific and subject to change.
In simple and complicated work, the notion of “one way” of doing something makes perfect sense. In the face of complexity however the notion of “one way” becomes nonsensical.
Hence the churn that you’ve experienced. There is no one way, because each day the problem is different. This is the nature of the work, complex and unpredictable.
What may be useful for you to try is to collect examples of good practice. A sort of patterns catalogue; this practice worked for this problem.
With reference to the Dreyfus model of learning, this is what separates the competent from the novice/advance beginner. The ability to spot patterns and apply the appropriate practice to the problem at hand.
Software is very complex indeed, and what I find is that often you need more then mere competence. What is called for is expertise, where you not only recognise patterns, but you are able to combine practices and synthesis new novel practice on the fly in response to the specifics of the problem at hand.
Of course building skill is far more difficult that documenting standard practice 🙂 It takes time (10+ years of deliberate practice), and an investment in people.
Organisation are reluctant to make such an investment, and of course short-termism means that no one is willing to wait 10+ years to see results 🙂
With proficient/expert practitioners however, I have found that checklists are mostly redundant. They know the rules, and they also know when to break the rules 🙂 WIth novices/advance beginners, then I guess that checklists are more beneficial, but I wouldn’t leave novices to work unsupervised on production software. It is far too easy for a novice to create a mess.
What ever way we try to cut it, we always seem to come back to needing good people to do good work (people over process).
http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition
Paul.
I think standard work makes perfect sense in software development as well. The true intent of standard work is to create knowledge how work works. Standard work in discrete manufacturing will in details look and be used in one way and in other contexts like software development it will be used in a slightly different way. But they both share the same purpose, create knowledge.
What I have found is that the mere action of formulating the standard work creates learning even in experienced teams. You create a shared model that can be discussed and improved upon.
In teams that have worked together for a long time and are very experienced the need to be explicit is less important for that team. In less experienced teams or teams that have not work together as long the need to be explicit is much higher. Making it explicit helps the team share their knowledge outside the team and it can help accelerate the learning in less experienced teams.
Yes software development is often complex. But that does not mean that there are many things that are very similar. Everything is not black or white, on or off. Be explicit and use checklist where it makes sense. Use tacit knowledge where it makes sense. The goal is to learn and improve.
I highly recommend reading these two books that talk quite a bit of standard work and its true purpose.
The Toyota Way to Lean Leadership: Achieving and Sustaining Excellence through Leadership Development http://www.amazon.com/The-Toyota-Way-Lean-Leadership/dp/0071780785
Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results http://www.amazon.com/Toyota-Kata-Managing-Improvement-Adaptiveness/dp/0071635238
I also recommend this paper by Drew Locher:
http://www.cma4results.com/Creating%2520Standard%2520Work%2520in%2520the%2520Office.doc
/ Håkan
Hi Paul,
With discussions of Standard Work, I think it’s easy to focus on the 20% of software work that this can not apply to, and not look at the 80% where it can. Delivering software is a lot more than writing the lines of code, as I’m sure you know. There are many things we do that can be considered for “standardisation”.
I think check-lists are a great example of a standard work description style. As long as the check-list is engaged with and its ongoing applicability questioned, then we benefit from managing it as “standard work”. If the standard work becomes “cargo cult-ed”, then we just have template-zombies. It’s up to managers to cultivate a culture where that doesn’t happen.
Hid,
I agree. As demonstrated by Hakan, standard work can be a useful mechanism for continuous improvement, even for knowledge work. My real concern is the mindset it implies. Analytic reductionist thinking, where developers are seen as fungible cogs within a defined process which is owned by Management.
We’ve seen this with CMM(I) in the past. I agree management have a responsibility here. It comes down to risks and benefits I guess. What are the benefits associated with standard work versus the risks. I think I’ve outlined the risks. Hakan when he gets around to his case study will describe the benefits in his specific instance.
Context is key here I guess. If your work is mostly predictable stuff, with a low level of uncertainty then the standard work/PDCA approach to continuous improvement may offer benefits that out way the risks.
The last couple of points worth mentioning is that in the face of complexity and uncertainty, the 20% where standard work doesn’t apply is often the area that yields 80% of the outcome. In a complex adaptive system, the relationship between actions and outcomes is nonlinear. A small action can have a huge impact. Which brings me to the last point. Checklists focus on doing things right (efficiency). Given uncertainty, there will be times when doing the right thing is more important (effectiveness). It will come down to developers to decide what is the right thing.
If they don’t feel they own the checklists, then they don’t own the right to ignore them when it makes sense to do so… Remember in manufacturing, it is the responsibility of the supervisor to define the standard work.
In manufacturing the balance of risks versus rewards are overwhelmingly in favour of standard work. For knowledge work the situation is far less clear. Ohno’s much quoted statement that standard work is the basis to continuous improvement, was said in the context of manufacturing. What we do is not manufacturing, hence we need to be very careful when borrowing ideas from a very different discipline.
Hi Hakan,
I understand how you use the term. Different to the original intent I think. Standard work pre-dates Toyota and can be traced back to the TWI manuals from the department of labour in the US during WWII. These manuals found their way to Japan after the war and are the basis of Lean. It has been argued that the roots of Standard Work are even deeper and can be traced back to the work of 19th century industrialists in Britain.
But none of this matters. What’s important is what people actually do in practice. Hence my question on how you improve your standard work. A concrete example would be great.
Thanks,
Paul.
Hi Hakan,
Thanks for clarifying with a concrete example. This is standard work, I agree. I urge you to write this up in a case study. In my experience true concrete examples of standard work for software are few and far between.
Thanks for sharing.
Paul.
Hi Paul,
Thanks for great discussion and the suggestion. I will add the case study to my bloging backlog 🙂
/ Håkan
Hi Guys,
As if to make my point. I spent this afternoon in a meeting with a client, who is busilly pulling together an automated workflow using Jira, with a number of process gates and integrated tools, which they plan to use to of impose “best practice” on to outsourced suppliers in India.
Now I know this isnt what you guys mean when you talk about standard work, but everyone shares your mindset, and old habits die hard 🙂
Scientific management thinking is ingrained in our prevailing management culture. I mentioned trying to build a relationship with their suppliers and even investing in coaching and mentoring as an alternative way of ensuring quality.
Oh no they said. Code coverage and other code quality metrics will form part of the contract. If a supplier doesn’t meet the required standard they will be replaced with another.
I sat there thinking about Deming’s words on “management by numbers” 🙂
Oh well 🙂
Paul.