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.
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:
- Business analysis
- Business analysis done
- Technical analysis/design, development and functional testing
- Ready for deployment to test
- Ready for System test
- System test
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
- Test cases should have been executed
All functional tests are green
All automated tests are green
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 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.
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.
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.
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.
Standard (or standardized) work is to establish how work is done, a description of how a process should operate. Standardization aims to remove variation in order to create consistency. It ensures that the process is done the same way every time, no matter who does it. The standard represents the best way of doing things.
This sounds quite reasonable in manufacturing process that repeat the same work over and over.
But when I heard about Standard work in a software context I was not to sure. It got me think of Waterfall, Rational Unified Process, lots of documents in dusty binders and bureaucracy. It brought me back to my pre agile days in the 1990s. I thought to my self, how can Standard work be applied to software development? Every project, every software I write is unique, one of a kind! Otherwise I would just reuse what I have previously done. Software development is a craft, an act of design and divine inspiration. Standard work can’t be applied to software development and at the same time be agile!
A few years back I got interested in Lean after reading Mary and Tom Poppendieck’s book Implementing Lean Software Development From Concept to Cash. I started to read Lean books, lots of books. In many of these books Standard work is described as the cornerstone for continuous improvement and continuous improvement is the driving force in Lean.
The counter intuitive and contradictive nature of Standard (or standardized) work in Lean is that:
Standard work will continuously change!
To continuously improve you need to know if a change is a real improvement or not. So how do you know if you improve or not? You need to know your current condition, something to compare against. In Lean this something is Standard work. Standard work describes how work is actually done today and not how it could be done(this comes later). Standard work is developed on the shop floor by the people doing the job(sometimes with some help). Then when you repeatedly do what you described you are performing the Standard work.
When you perform the work and the standard is not followed you have a learning opportunity. You have the opportunity to find out why you did not follow the Standard work.
- Was it something that was stopping you?
- Was it not as efficient as another way of doing it?
- Did the Standard work create any unanticipated problems for you or somewhere else in the process?
If these learning opportunities result in a suggestion to do the work differently you formulate a hypothesis of how the new Standard work, the target condition, should be. You then try it out for a while. If your hypothesis is validated you change your process to use the new Standard work.
Implementing Standard work in a manufacturing process with repetitive task sounds reasonable but how do you implement standard work in something as variable as software development?
It is all about how detailed you get in describing your Standard work. If you abstract up, every process can be described as Standard work. A very basic and abstract, and probably not very useful, way to describe Standard work could be:
- Keep a list of work to do
- Do work on the highest priority item on the to do list
- Keep records of done work
The more concrete you can describe the Standard work the more useful it can be. Standard work should be something that helps you perform the process over and over with consistency. If some part of your process has a high degree of variation of how the work is really done you can start by not detailing this part of the process. As you learn more about the process you can make it more detailed if you need.
In summary: Standard work should describe how the work is actually done. When you find a better way of working, then you change the Standard work to the new way of working and this will for now on be the new Standard work.
In part 2 of Standard work in software development I will show how a team I been working with have used Standard work.
I try to read a lot of books but I’m not a fast reader. I also spend some time more or less every day walking the dog, doing grocery shopping, commuting to and from work and so on. I have found that listening to audio books and podCast are a great way to learn. Here is a list of highly recommended audio books I have read.
James P. Womack
- Lean Thinking- Banish Waste and Create Wealth in Your Corporation, Revised and Updated
- Lean Solutions- How Companies and Customers Can Create Value and Wealth Together
Stephen A. Ruffa
- Predictably Irrational- The Hidden Forces That Shape Our Decisions
- The Upside of Irrationality- The Unexpected Benefits of Defying Logic at Work and at Home
Eliyahu M. Goldratt
- The Goal- A Process of Ongoing Improvement- Revised Third Edition
- Beyond the Goal- Theory of Constraints
Dan & Chip Heath
John P. Kotter
- A Sense of Urgency
- The Heart of Change- Real-Life Stories of How People Change Their Organizations
- Our Iceberg is Melting- Changing and Succeeding Under Any Conditions
- Buy-In- Saving Your Good Idea from Getting Shot
Daniel H. Pink
- A Whole New Mind- Why Right-Brainers Will Rule the Future
- Drive- The Surprising Truth about What Motivates Us
Emi Osono, Norihiko Shimizu, Hirotaka Takeuchi
Louis V. Gerstner
Peter M. Senge
Here is my slides from my presentation at DevSum11
Idag höll jag en presention på Valtech Days med följande beskrivning:
Korta releasecykeln med smart .NET arkitektur och Scrum
Med agila arbetssätt som automatiserade tester, kontinuerligt integration och en löst kopplad systemarkitektur så har SwebusExpress minskat sin release cykel från 8 till 2 veckor.Scrum var metoden, Lean värdegrunden och Visual Studio Team System systemstödet.
Som vanligt så har jag svårt att hålla mig kort så det blev lite ont om tid på slutet men det känndes ganska bra. Hade hoppats på att jag skulle hinna med att visa lite kod också samt automatiska byggen i Team Foundation Server men det han jag inte med.