Standard work in software development–part 2
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.