Alexander Vanwynsberghe

"There is nothing impossible to him who will try"

Implementing Kanban with TFS: Under the hood

In a previous post, I talked about the Kanban 1.0 process template made by the ALM Rangers. It gives you some basic information, and it also describes how to install the process template and how to create a new Team Project based on this process template. In this post, I will talk a little bit more in detail about how this process template works. Let’s see how it looks like under the hood.

Work Item Types

Let’s start with the work item types you have when using the Kanban process template. The process template provides the following Work Item Types:

  1. Card: This is the unit of work that is tracked through your software development process. A Card represents value demand or failure demand on your team. You can specify a type of Card. By default the following Card types are provided, although you can customize the card types by changing the Kanban Card Types global list:
    • Work Task: This represents demand on your team for work that has value for your customer (value demand).
    • Team Task: This represents demand on your team for work that has intangible value. Typically these includes work such as setting test environments, re-factoring some code etc.
    • Problem: This represents demand on your team to rectify a problem (failure demand).
  2. Process Step: This Work Item Type is used to define information about the steps in your process. In particular this is where the WIP limits are defined for each step of your process.
  3. Blocker: Used to represent a problem that is blocking the progress of a Card. The Card work item has a tab where blockers can be listed.
  4. Bug: Used to track bugs.
  5. Shared Step: Used to define a reusable set of test steps.
  6. Test Case: Defines a test case.

Process

One thing which is really important when using Kanban is the easiness of changing your process. Your process will change over time! One of the requirements of the Kanban Process Template is that it has to be possible to easily change the steps of your process. Let’s take a look at the following image:

In general, you have 3 big states (in blue). A planned (backlog), In Progress and Complete (closed) state. The planned and complete states are the start and end states, and they have no queue associated with them. When you create a new ‘card’ work item, the starting state will always be the backlog. When the card moves to ‘In Progress’, you will have the option to select in which working state it’s in. And those states are customizable.

When you create a new Team Project based on the Kanban Process template, you have 4 ‘working states’. Analyze, Implement, Test and Review. Those states are defined by the ‘Process Step‘ work item. So by default, there are 4 process step work items. To manage the order of the steps in the flow (from left to right), you can use the ‘order‘ field from the work item type. The lower the number, the more left on the flow. By default, analyze is 10, implement is 20, test is 30,… On each process step work item, it’s also possible to provide the Work In Progress (WIP) limit. This number will be used for visualization on the Kanban Board. You can also provide some exit criteria (also known as -the definition of done-). For example:

Global List Synchronizer

When you add a process step to your Team Project, it has to become available to your cards. Meaning that it has to be possible to select the correct state on the card work item. The list of possible states that can be used on a card are stored in a global list on TFS. To synchronize this list whenever you change or add a process step, there is a background process called the Global List Synchronizer, who will synchronize the list of process steps used in the Card Work Item Type with the current list of Process Steps. As you add, change or remove Process Step work items, the list of valid process steps in the Card work items changes accordingly. It modifies the Card work item type definition so that each Team Project uses its own Global List to provide the list of process steps. In fact, you get something like this:

The Global List Synchronizer is something that has to be installed. Installation is really simple, just download the bits from CodePlex. Open the downloaded item, and unzip the file ‘Global List Updater Source Code.zip‘. Open the correct (TFS 2010 or TFS 2012) GlobalListUpdater solution (with either Visual Studio 2010 or 2012). Change the build configuration to ‘Release’ and build the application. In the output folder, you should now see the following files:

Next step is to install it on your Team Foundation Server. The installation process is quite simple.

  1. Log in to the Application Tier server.
  2. For Team Foundation Sever 2010: Copy the compiled assemblies (including the .config file) to <System Drive>:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\bin\Plugins.
  3. For Team Foundation Server 2012: Copy the compiled assemblies  (including the .config file) to <System Drive>:\Program Files\Microsoft Team Foundation Server 11.0\Application Tier\Web Services\bin\Plugins.
  4. If you have multiple Application Tiers, repeat step 1-3 for each of them.

After you copied the files to the plugin folder, TFS will detect this and will restart the application tier. This way, the plugin will be hooked to TFS and will be able to interact with TFS events (like work item changes). You can see this in the event log:

To test if the plugin is doing its work, open a process step work item (using Visual Studio, or the Web Access) and change the title of the item. Save the work item. Now create a new ‘card’ work item, save it in the ‘backlog state’, change it to ‘In Progress’ and see if you can select the modified process step. In my case, I changed the process step ‘ Implement’ to ‘Implement(test)’. You also can look at the event log on the TFS server, and you will see all output of the plugin listed there:

Ok great, so now you have an overview of how the process template is constructed, which work item types you have and how the Global List Synchronizer works. In a next post, I will show you a little bit more about how you can use the process template, how you can use the work item queries and how you can use reporting to view all information about your Kanban process.

Thanks for reading!

Implementing Kanban with TFS: Introduction

In this blogpost, I want to talk a little bit about how Team Foundation Server can help you to support your Kanban Process. We will use the Practical Kanban Guidance from the ALM Rangers, where I am also a part of the team. I will talk about the the process template requirements and how to get started.

First of all, really short: what is Kanban? Well, Kanban is a method to visualize the development work flow and the work in progress. Kanban has 5 principles:

    • Visualize the workflow
    • Limit WIP
    • Manage the flow of work
    • Make process policies explicit
    • Improve collaboratively

Using these aspects, you can highlight any bottlenecks in the development process. You have a visual overview of the things which are happening in your team, so you can guide it. Perhaps change the process, change the WIP limits, ..

Requirements

As you know, the way TFS supports your development process is defined by a process template. This is a collection of files that together define various process elements of a team project. There are a number of requirements that need to be satisfied to allow teams to get the most out of a Kanban-enabled process template for Team Foundation Server.

1. The process template should make it easy to modify the states in the process flow: Kanban is about continuous improvement. During the life of a project a team may wish to modify their flow, adding or removing states. Therefore the process template should make it easy to add and remove states in the process flow.

 2. The process template should allow Work In Progress limits to be represented and reported on: One of the few fundamental concepts in Kanban is to limit the amount of work in progress (WIP). This means that the process template should allow us to specify a WIP limit for each state in the lifecycle of a card.

3. The process template should allow each state in the process flow to have an In Progress and Done sub-state: The process template should allow for In Progress and Done sub-states and report on WIP limits across the two sub-states.

4. The process template should support arbitrary state transitions: Kanban is not a software development method and does not dictate anything about how a team should implement its process. Therefore a card should be allowed to be moved into any Kanban state from any other Kanban state.

5. The process template should support hosted Team Foundation Server instances: To give teams maximum flexibility, a Kanban-enabled process template should not require project collection administration rights to make changes such as the states in the process flow and WIP limits.

6. The process template should include a Cumulative Flow Diagram Report and a Kanban Board: It has to be easy to see when bottlenecks are occurring, in which state the cards are, what’s the cycle time,..

Microsoft Kanban 1.0

Based on those requirements, the ALM Rangers came up with a brand new process template called: Microsoft Kanban 1.0. This is a flexible process template allowing you to easily adapt your Kanban process on Team Foundation Server. You can download the process template here, including all documentation and guidance you need.

In a next  post, I will explain how the process template actually works and how you can use it.  But first, let’s take a look how you can install this process template. Once you have downloaded the bits (both Team Foundation Server 2010 and 2012 are supported), you need to upload it to Team Foundation Server, so that you can create a new Team Project based on that template.

1. Open Visual Studio (we will use 2012, but it’s quite similar on 2010), go to ‘Team Explorer’, click ‘Settings – Process Template Manager’, there you click ‘Upload’ and locate the folder with the process template. I will use ‘Microsoft Kanban 1.0 – dev11’, because I’m using TFS 2012.

2. After the upload is complete, you should now see ‘Microsoft Kanban 1.0’ in the list of process templates.

3. Now create a new Team Project using this process template. In Team Explorer, go to ‘Projects and My Teams -> New Team Project‘. Complete the wizard and select the Kanban process template:

4. That’s it. You have a Team Project based on the Microsoft Kanban 1.0 process template. If you open your Team Explorer, go to Work Items and you can start creating cards (based on the Card Work Item Type) and model your process (based on the Process Step Work Item Type).

More in-depth information about how to use the process template will follow in a next post. I will also talk about ‘the Global List Synchronizer’, who will be responsible for the synchronization of process steps.

If you have any valuable feedback, just leave a message or start a discussion on the codePlex forum.

Thanks!

ALM Rangers Practical Kanban Guidance RC

Yesterday, together with the Visual Studio and Team Foundation Server 2012 RC release, the ALM Rangers have also SIMultaneously SHIPped their guidance as RC. As I’m really proud to have been involved in the ALM Rangers team, I can tell you that we also shipped the RC version of the Practical Kanban Guidance.

The Practical Kanban Guidance offers teams that are new to Kanban and teams that are using a manual, paper or whiteboard-based Kanban board, guidance and tool support for Kanban in Team Foundation Server 2010 and Team Foundation Server 2012. The guidance also describes how Team Foundation Server can capture metrics and other information that can be used to track and continuously improve a team’s software delivery process.

You can check it on the CodePlex project. If you have any suggestions for improvements, remarks, bugs,… just let us know! Your feedback is really valuable.

Enjoy the release!

How we use Kanban with small tasks

A while ago, I asked a question on Stack Exchange Project Management about how to use the Kanban board for very small tasks. Let me explain what I mean about small tasks:

We do development of some products (web-applications) which are used by our clients. Some clients use our generic products, and some others have a customized version. Mostly in the -week before release- we get several test-run remarks from our client. Those are (mostly) some small things like some CSS tweaks, some formatting, changes in the list-orders and so on.. Nothing big..

I was struggeling about how to translate those issues to our Kanban board. Do I have to create a ‘post-it’ for every issue? If yes, I suppose it will take longer to create a post-it, attach it to the right column, let the dev fix the issue and then let him move it to the testing/done column. Another thing is the board overload.. Ok, you have the WIP limit some columns, but in the end all the done items are there, and the board will look very overcrowded. Also the WIP of the ‘selected’ column is less than the number of items to fix.

So, how to handle situations like this? As I really want to visualize the issues and have a reference to the Kanban board.

I found the answer on Joakim Sunden’s blog. (Thanks to Pawel Brodzinski for the link). The concept he explains is to have a dedicated log for such tasks. The only thing in this log is an issue ID (wich can be the TFS workitem number, or a task-management/bug tracking tool ID). The ID is crossed out once the issue is fixed. If you keep this log close to your Kanban board, you have a clear overview of the open and fixed issues. The other nice thing is that you can easily move items to the Kanban board which do need more work than initially thought.

Personally, we did choose for a project approach to group our issues. Each project has a column, and this colum does only contain a list of issue ID’s. You could also create columns for each individual person in the team. It’s up to you to decide. If someone is working on one of the issues, you can add a sticky to the correct column on your Kanban board with some information about issue fixing of product X/Y/Z

Issues

We can also analyze the issues list. A lot of the issues are created because the product did fail to deliver the actual value the customer was waiting for. By collecting the data, we can get to the root cause of the issues, and we can find a way to reduce the number of such items. This gives us more resources to focus on delivering a good product.

We are using this approach for a while now and it seems to be working well! I’ll keep you posted about the evolutions we make with our Kanban board and the issue list! Thanks for reading!

Measuring Kanban Lead & Cycle Time

Now that we are using our Kanban board for a while, it’s time to do some analytics with the visualized information on the whiteboard. Kanban is not only about visualizing your process with a bunch of post-it’s, you can actually do a lot with those “post-it’s”. What I will try to explain in this post is how you can define the lead & cycle time of your items on the board. That way, we can provide some time-related information to our customers about how long it will take to make a particular feature and how long it will take from ‘request’ till ‘delivery’. 

When you use the Scrum methodology to deliver new features to your client, it’s clear that your feature will be ready by the end of a sprint (in normal circumstances). That’s because it uses a time-boxed approach. Using Kanban however, you don’t have any time-boxed iteration. That way it’s quite hard to tell the client when the request will be accomplished.

First of all, what’s the defintion of a lead time and a cycle time? And also, what’s difference anyway?

Lead time

This is the time needed to get your feature ready. In Kanban, this is the time from when your item is added to the backlog till your item is live. So the clock starts when the request is made and ends at delivery.

Lead_time

Cycle time

This is the time needed to ‘make’ a feature or ‘complete’ a task. In Kanban, this is the time when your item is in a ‘in process’ state and there is someone working on that particular item. So the clock starts when work begins on the request and ends when the item is live.

Cycle_time

The difference?

The lead time is the time and not the effort spent on the item. You may have a lead time of 20 days, but there were only 2 hours work on the item. The Lead Time and Cycle Time do not have the same unit although. Lead Time is measured by elapsed time (minutes, hours, etc.). Cycle Time is measured by the effort spent on the item defined by time per unit (minutes/task, hours/part).

 

Conclusion

Now you know the difference between the two, it is obvious that the lead time is more relevant from the business perspective than the cycle time. Actually the cycle time is what the team can influence by changing the work process. Sharper WIP limits for example can reduce the cycle time, but also the determination of the bottleneck in the flow can help you to improve the cycle time.

What I will do now is track 4 things n the Kanban board:
  1. The date as when an item/feature is added to the backlog = the request date
  2. The date as when an item enters the ‘todo’ column
  3. The time each person spends on anthe item
  4. The date as when anitem is ready/live

Using these 4 measurements, I will be able to determine the lead and cycle time of our board.

Note: I’m not quite sure about the time as when the item is ready. Is it really ready when the feature has passed the acceptance phase? Or is it really ready when the feature is ‘live’? Any feedback is really appreciated!

In a next post, I will try to explain how you can improve the lead and cycle time using my personal experiences. Thanks for reading!

How we use Kanban in our development team

A while ago I wrote a blogpost about why scrum didn’t work for us. Some of you did suggest me to use the Kanban methodology instead. This would be a much better suit for our team. I did a lot of research of what Kanban really is, what the best practices are and how to implement this in our team. I will tell you in a few steps how we did this..

First of all, what is Kanban? Well, Kanban is a method to visualize the development work flow and the work in progress. Kanban has 5 principles:

  • Visualize the workflow
  • Limit WIP
  • Manage the flow of work
  • Make process policies explicit
  • Improve collaboration 

Using these aspects, you can highlight any bottlenecks in the development process. You have a visual overview of the things which are happening in your team, so you can guide it. Perhaps change the process, change the WIP limits, ..  

Kanban is an approach to change management. It isn’t a software development or project management lifecycle or process.

A kanban system is often designed on a big white-board used to reflect the workflow. Different color cards are used to show different types of work. This could be a task, a user story, a bug. There is a more detailed description of the task written on each card.

The first thing I had to do is reflect the development cycle to columns on the whiteboard. Pawel Brodzinski made a very interesting blogpost about that. Using his guide, I created my first-ever Kanban bord. This is how our ‘version 1’ board looks like:

2011-09-21_14

Note that the columns seem to reflect some kind of waterfall style process mapping. Well it isn’t. The Kanban board reflects all phases an item must go through in the development cycle. It encourages small independent user stories to be developed in little pieces. The columns on the Kanban board don’t represent hand-offs between team members but more or less the state of what’s the feature in during that time in its development lifecycle.

As you can see, we also use some Kanban queues. Those are a small inventories between two processes to create the appearance of instant availability. 

 

Some notes on our board

  • How did we define the WIP limits? Trial and error.. There is no science which will tell you what’s the best WIP limit number. It depends on your process, your team capacity, ..
  • We will not continiously deploy. We keep a list of features/bugfixes in the ‘ready’ column, and the PO decides when there is enough ‘buzz’ to make a commercial feature release/bugfix release.
  • High priority is a special ‘swimlane’. If there is an item there, mostly a bug, the developer is obliged to pull that item when he is ready for some new work.
  • There will be a montly retrospective meeting. In this meeting we will discuss the board, check if the colums are still good and if there are other remarks.
  • The queue will (mostly) be fed by our weekly prioritization meeting.

 

Why is Kanban better than Scrum (for us)

  • First of all, they are both process tools. They both help us to work more effectively.
  • The biggest difference is that Scrum is iterative based and Kanban not. This was a problem for us as with Scrum, we never released what was planned in our sprint.
  • We went from PO driven development to a combination of PO driven and sales/client driven development.
  • We handle critical issues much faster that we used Scrum, where you have to wait till the start of the new sprint.
  • We can prioritize our items so important things go first.
  • Developers have more motivation (maybe because Kanban is less prescriptive?)
  • It’s easier to work on multiple products. If we want, we can even use a different swimlane for each product.

 

What will change?

  • Other (bigger) post-it’s with more information to visualize. The current post-it’s only have a brief description of the ‘todo’, but I want more information on it. 
  • I also want the start/end date and the time spent on the task visualized. I would like to make some stats to define average lead time (starts when the request is made and ends at delivery) and cycle time (clock starts when work begins on the request and ends when the item is ready for delivery)
  • Investigate the possibility of using swimlanes for user stories and the linked user story tasks.
  • Kanban cards are now colored by type. Like: a feature, a bug, a task, .. Perhaps we can use the colors tho define which type of work. Like: core development, configuration, design, marketing, .. ? (any suggestions on that are welcome!)
  • The outline of the sub-columns needs to be smaller, or maybe dot-lined. Now it’s hard to see the general ‘flow’.

 

Some interesting links

 

Thanks for reading and I’ll keep you posted when something changes in our Kanban story!

Why scrum doesn’t work for us

In this blog post I’ll try to explain why using Scrum didn’t fit our needs. I’ll talk about the main reasons, my personal opinion and what the alternatives are for our team.

First of all, let me explain the team situation, the products we make and how we used to work.

As mentioned in my first blog post, I work as a development team manager at a software company. We develop a collaborative framework which is the base of some main products. The team working on the applications consists out of some developers, configurators and designers. They all work on our framework and the various products.

You get something like this:

Team_products

 

We did already work on an agile way of software development, but we needed a better way to manage the process, to create structure and overview. All this using a time-boxed iterative approach. So we did some research on Scrum. From what we’ve read and learned about it, this was the way to go. 

Scrum its use has focused on the management of software development projects, and it can be used to run software maintenance teams or as a general project/program management approach.

Scrum

On the exact moment that we wanted to implement Scrum, Visual Studio 2010 (our development software) released a Scrum process template, perfect! This process template is a great way to define a product backlog, create sprints, work-items, test cases, a burn down chart ..

So we had a decent tool, we had a great product backlog with lots of amazing new features to be implemented, we had a good team, we did standup-meetings in the morning, sprints were defined.. Off we were…  

 

But after a while, things did not work out as planned. That’s why:

  1. There are too many projects and custom client-solutions
  2. Our team is too small to focus on the sprint for each project
  3. Sprints take much more time to complete than planned.
  4. Every team member is working on all projects at random, it’s hard to ‘focus’ on the defined sprints.
  5. Sprints are influenced by clients. Client requests have a higher priority than the sprints
  6. There was not enough discipline for the daily standup-meetings
  7. In general, time boxed iterations do not work for our -type- of work
  8. Our sprints are mostly event driven, instead of time driven

My personal opinions:

  1. It’s definitely not the fault of the tool, which is awesome
  2. We have to combine big feature development with custom client-development, support and maintenance
  3. There are too many Work In Progress items at a time
  4. The best solution is to stop using Scrum

 

We’re currently looking into another solution which will suit us better. I’m talking about Kanban, but more about that in a later blogpost.

Any suggestions and experiences are welcome, just post a comment!