As mentioned previously, the Product Owner (PO) is critical to the success of agile development, but even more so when working with offshore outsourced development teams, where communication is key in working up user stories.
Challenge of Distance. The reliance of Scrum daily standups for each team member communicate what:
- User stories are done
- User stories are currently being worked
- If any blockers exist
becomes challenged when the PO is many time zones away. Blocking issues can be a real issue if the PO is required to address them and has no easy way to identify them quickly.
Although many organizations could benefit from adopting Scrum, when working with agile teams spread over many time zones Silver Tree advocates taking the further step on the lean journey: put Kanban in place.
Kanban is a method to limit the amount of Work in Progress (WIP) in a work flow. It was instrumental in enabling Japanese automakers to develop Just in Time (JIT) inventories as Kanban is a signal that some component was consumed in the manufacturing.
Traditionally the signaling is done by a Kanban card which represents a single component. If a component is used then signal the consumption by placing a Kanban card in the stack which at a predetermined level requires a restocking. An alternative method is the Kanban board, which is the standard representation used for software development. Each user story is placed on a yellow sticky. The backlog is a collection of yellow stickie’s. Each stage in the work flow (or value stream) is represented as a column and the work is pulled from left to right.
The Kanban board depicted in the diagram shows that each stage of the SDLC is a column split into a working section and a done section. The WIP limit for each stage is the number in the circle. Each of the columns have a maximum number of working stories of three, except for Test which is set to two in this example.
Note that WIP limit for each stage is the sum of working and done combined. Kanban – in addition to enforcing WIP limits – has a clear definition of done for each stage. Making explicit the definition of done is shared with Scrum (although many devotees of scrum confine it to development).
The Kanban board makes explicit what is being worked on and can highlight whether any bottlenecks exist in the work flow. With strict definitions of done for every stage no user story progresses without the assurance that the work is ready for the next stage. The team members love the simplicity of the signaling provided by the physical board and unlike updating some electronic system are willing to spend a few seconds moving their own sticky as they finish the work. Kanban works like a charm when the team is collocated as everyone can see the real time picture of the work.
The logical question raised is how this translates when the team is offshore and outsourced. This is where the project manager (or if you will scrum master) fulfills the responsibility of providing accountability to management. After every daily standup, the scrum master records the changes on the physical Kanban board into some electronic Kanban board. Recall the three questions asked in a daily standup for Scrum:
- What did I finish yesterday?
- What will I work on today?
- What if any blockers am I experiencing?
The first two questions are explicit on the board. We know what everyone is doing as the yellow sticky identifies the worker. Consequently, the time saved in the daily standup (a well-executed Scrum stand up of 15 minutes typically goes down to 5 minutes) can be used to populate the electronic Kanban board.
In near real time any Product Owner or interested Stakeholder can view the electronic Kanban board regardless of their location. Even when their responsibilities requires them to travel they have visibility of the Kanban board online and see how things are progressing. The ability to drill down into any given sticky should provide them with the information to resolve most blocking issues.
Silver Tree recommends that most software development teams move to Kanban, particularly when the team is distributed. If a client is having great success with Scrum, we likely would defer such a transition and look to other aspects of the SDLC for improvement. Paraphrasing Eric Brechner in his Agile Project Management with Kanban, it’s not that we didn’t think Scrum was great we just found something better, Kanban. Many development teams mix elements of scrum (e.g. writing good user stories, planning poker) with the Kanban board achieving high velocity of code development.
Interested in exploring Kanban? Let Silver Tree guide you on this lean path.
Kurt P Schmidt, PhD, Practice Lead, Lean IT
Silver Tree Services, LLC