Building a Virtual Kanban System with Team Foundation Server - Part 1
Hey guys,
David Anderson is someone that I’ve had the privilege of working with for the past couple of years. One of the things that I’ve found really interesting about his work is that he often takes practices from other industries and applies them to managing software development.
One example of his is the idea of a Kanban System. Many Japanese manufacturing companies have used this process with great success. The basic idea is to control the amount of raw material in play. Wikipedia has a great explanation of the system in general.
“The Kanban system might be visualised as a "Three bin system" - one bin on the factory floor, one bin in the factory store and one bin at the Suppliers' store. The bins usually have a removeable card that contains the product details and other relevant information - the Kanban card. When the bin on the shop floor is empty, the Kanban card is removed and given to the store. The store then replaces the bin on the factory floor with a full bin which also contains a removeable Kanban card. The store then contacts the Supplier and indicates the need to replenish the Kanban card. The product also containing a Kanban card is delivered into the factory store completing the final step to the system. So it will never run out of product, providing of course, the cards are reliably collected from empty containers”
David Anderson has had a lot of success applying the principles of a Kanban System to software development. It remarkable how effective a relatively lightweight process like a Kanban System can be; his paper describes in detail the success of a Microsoft IT team.
I won’t do justice to the work so I’ll leave it to you to read the paper; what I wanted to explore was how one might implement a Kanban System with Team Foundation Server.
As I mentioned in one of my earlier posts, I think there might be some really interesting integration between BizTalk Server and Team Foundation Server. BizTalk becomes really useful when you have to make a bunch of things and people interact in a reasonable and consistent way; otherwise referred to as orchestration
I’m new to BizTalk Server so I wanted to experiment with how it can be used in conjunction with Team Foundation Server. I’m just scratching the surface of BizTalk so be warned, there might be easier/better ways to do things. The full solution can be downloaded here.
The Orchestration Designer integrates into Visual Studio 2005 and is a key part of BizTalk Server. First, I’ll show you the orchestration as a whole; then we’ll dive down into the details.
Let’s go through each step so we get a basic idea of what the orchestration looks like. The number items below match the numbers in the diagram above.
- The orchestration is activated when we get a message indicating that a work item is changed
- From a Kanban perspective, we only care about a work item that has changed if it is just been created, made active or closed. We don’t care about any intermediate changes. If this change matches that criteria, we are going to query Team Foundation Server to determine the number of active work items.
- If a new work item has been created, and our Kanban is full – i.e. there are more than a certain number of active work items – then we will have to put this work item in our back log.
- If a work item is being closed, and our Kanban has at least one open card – i.e. there are less than a certain number of active work items - then we will notify the customer that a free card is available.
That’s all there is to our Kanban System example.
But, you’ll notice that I left out a bunch of details – things like how do we determine the number of active work items, notify the customer, etc. One advantage of using BizTalk Server is that there is a separate between logical and physical ports.
A port in BizTalk Server is something you receive data from and/or send data to. The data being sent or received is in the form of XML. You have to define the structure of the XML immediately, but you can decide what the physical ports are later. You change them as well. So for now, we don’t have to worry about how we’ll get information about the number of work items in Team Foundation Server or how we notify our customer. We know we have to do it, we’ll figure out exactly how to do it later on.
Now let’s look into the details of the orchestration. First, let’s look at how the orchestration is activated.
1 – Port_WorkItemChanged Port
We haven’t done it yet, but we will register for WorkItemChanged events with Team Foundation Server. These event notifications will come into this port.
The designer unfortunately does not allow you to change the width of things, so the name of this port is somewhat obscured. The message we are waiting for is defined by an XML schema that we create. Actually, strictly speaking, we can create the schema from scratch or reference an existing one defined in XSD, as a .NET or as a web service.
The structure of the message we are waiting for is very simpe and looks like:
Ideally, I would have liked to use the WorkItemChangedEvent that is delivered directly from Team Foundation Server’s event notification system. But, the structure of that message makes it somewhat difficult to extract the information that I need from it. For now, I took the easy way out and defined my own message structure that I’ll hyrdate.
2 – Receiving the message
This is just a standard BizTalk Server thing – this receive is what activates our orchestration.
3 – Deciding if we are interested in this event
We’re not interested every time a work item changes; the Expression shape in BizTalk Server allows us to define an expression to find only the ones we’re interested. The expression behind this shape looks like:
The only changes we’re only interested in are the newly created work items, the ones that get closed, and the ones that are reactivated.
When we have a work item in any of those states, we’ll treat them differently based on the number of active work items that we have. The section of our orchestration below is what we use to count up our active work items.
1 – Counting Work Items
We have a web service that queries Team Foundation Server and returns the number of Work Items in the active state.
2 – Web Service Port
BizTalk Server setups up a request/response port for you automatically when you use a port from a web reference.
Once we have the number of active work items, we will combine that information along with the state of the work item.
If the work item is active (either because it is newly created, or because it’s state was set that way), and our Kanban is full, we will ‘punt’ the work item. A Kanban is full when there are no open slots or cards to represent the work. This enables us to control the amount of work the development team has to worry about.
We ‘punt’ a work item by calling another method on our web service port. What that web service does is change the state of our Work Item to ‘BackLog’. This is the end of the orchestration for this branch.
If the work item is closed and our Kanban has an empty slot, then we will notify our team of a free Kanban card.
This is the end of the orchestration for this branch as well.
So, what we have in our orchestration as a whole is the basic implementation of a Kanban system. To summarize, when a work item is created or re-activated, we check to see if we have any open kanban cards. If we do, that’s fine we don’t need to do anything. But if we don’t, then we will assign that work item to the backlog. Every time a work item is closed, we check to see if we have any open kanban cards. If we do, then we send a notification to our team to let them know that a card is open.
Those are the basics of the system – I’ll do a follow up post that delves into some of the details about how the ports are bound and show some examples of the orchestration actually executing.
Thanks!
Eric.
Comments
- Anonymous
September 12, 2006
Aaron Kowall on TFS Workspace Gotcha!Eric Jarvi on VSTS Tip: Tech Ed 06 Team System Sessions....