Datavault : Kanban in a Datavault project (part III)

Introduction

I've finished my Lean Six Sigma Orange Belt certification a couple of months ago. For this certification I needed a case study that would justify a certification. I decided to use my project as a base for my certification. In my current project we are developing a analytic platform for analysts with Datavault. We already used a kanbanboard but I thought that some improvements was possible.

We encountered some throughput problems of the implmentations and I decided to investigate our development proces and thought about what could aid speeding up the process. The teammembers discussed our method and we tried to adopt the various techniques of Lean Six Sigma.

One of the subject areas of Lean Six Sigma is Kanban and Kanban can be very useful for making your processes visible and identifying possible bottlenecks in the process. Read more about Kanban on Wikipedia and this free book about Kanban and Scrum. These are very learnful.

This is the approach I have taken (with the development team) in order to develop a (new) Kanban board:

• Identifying the steps we take in the development process?
• What do we do when we build Datavault implementations (the objects) ?
• Who are the customers and who are the suppliers in the process?
• Supplier, Input, Process, output and Customer  (SIPOC).
• What are the criteria for moving a card from one phase to another?

This blogpost is one in a series of blogposts about datavault:

• Datavault : The basics (Part I)
• Datavault : Adaptability of the Datavault model (Part II)

Task analysis

At first We decided to take a look at our activities in the project. What are the activities in the project? Well, We came up with this list:

• Analysis (gaining knowledge)
• Deskresearch
• Data-analysis
• interviews

• Design
• Datamodeling (Conceptual, logical, SourceVault and  BusinessVault)
• ETL
• Development (DDL + ETL Packages)
• StagingIn
• Tables
• SourceVault
• Hubs
• Links
• Sats
• EndSats (Effectivity)
• Refs
• Other DV Tables
• Build (DDL + ETL packages)
• BusinessVault
• Hubs
• Links
• Sats
• EndSats
• Refs
• Other DV Tables
• BusinessAccessLayer
• Development (ETL packages)
• Entities
• ProcessFlows
• MasterProcess flows (PCF and MPCF)
• Input file processing (IFP)
• StagingIn
• SourceVault
• BusinessVault
• Initial loads (This is for going back in time and resample (historize) the data).
• ProcessManagement
• Configuration
• Test
• Systemtest
• Acceptancetest
• Documentation
• (Conceptual Datamodel)
• SourceVault Datamodel
• BusinessVault Datamodel
• Functional and Technical descriptions
• SSIS packages
• Additional
• Supply contracts with the datasuppliers

SIPOC

The next step was investigating our working process. What are our phases we actually executing during development of a deliverable? And what were the criteria for moving from one phase to another?

The next step was studying the SIPOC (supplier, Input, Process, Output and Customer). With SIPOC you have a tool that help you to improve a process. This is mostly used during the Define phase int he DMAIC process.

I noticed that there are two kinds of output in a process: Work and Criteria. The criteria says something about go/no go decisions and work is about delivering value to the valuestream, for instance a Datavault model.

The Kanban board

The next step we took was designing a new Kanban board, based on the taskanalysis and the SIPOC schema. I made some designs of the board and We had quite some discussions about the board. The discussion was about finding a balance between not too simple but also not too complicated. If it was too simple it will not help us understanding the process and if it was too difficult people wouldn't accept the board. We finally made this board:

Phases
We have defined the columns as identified (more or less) in the SIPOC schema during the Define process : Analysis/design, Develop, build, test, QA, Ready for production and Production.

Lanes
We introduced two kinds of lanes: Projectlanes and fastlanes. Fast lanes were intended for high priority issues that had a higher priority than the projects that we were running.

Definition of Done (DoD)
And the last part that we added to the board was a Definition of Done row. This DoD were the criteria in the SIPOC schema. These criteria helped us describing the DoD. This helped us agreeing about when a card should be moved from one column to the other, as a group.

The result

Finally, we created a new kanban board. This is shown below.

Conclusion

Kanban can be very useful in a project with a number of teammembers. Developers have to tell something about what they are doing, the impediments they have and what they are planning to do. A Kanbanboard can be very effective when all members of team are working with one goal: deliver value within a certain period of time. I think it's less effective when all members are working on their own deliverable and with their own deadline. When teammembers are working on a collaborative goal more co-operation  and more synergy effects will happen

Greetz,
Hennie