I’m happy to announce that the collection of business transformation essays called LESS!, that I co-authored, is now published.
It is free and you can get it here.
When you have read it, please write a review at GoodReads.
This is a book of twelve essays written by me and my co-authors who all work in the trenches, building business, coaching leaders and shaping the future. This book contains the following main topics:
- Beyond Budgeting–Changing the way the organization is managed from command and control to an empowered, adaptive and agile model
- Radical Management–Rethink the fundamental assumptions about management
- Strategic Navigation–Use OODA Loops and the ancient Chinese 36 Stratagems to outthink the competition
- Lean–Do more with LESS! resources
- Agile–working software, no pain
- Systems Thinking–An easier, better way to think about organizations
- Complexity Thinking–Radical insights about organizations and management coming from the complexity sciences
- The title of my essay is “Standard work in Software development”. In this essay I explore the application of the Lean tool called Standard work in software development. You can find my blog posts on the subject here.
- I want to give a special thank you to Henrik Mårtensson for his tireless efforts of editing and making the book ready for publishing. Thank you!
A cornerstone for continuous improvement in Lean is standard work. Standard work is a description of how a process should operate. Without standard work it is much harder to know if process changes are improvements or not. 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 where there is basically no repletion of tasks? In this Lightning Talk you will be shown an example of how standard work was used in a software technology migration project. The intended audience is managers, team leaders and coaches working with process improvements.
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.