Home » Posts tagged 'kanban'
Tag Archives: kanban
This is part 2 of a series of posts that show how we can model virtual kanban systems on TFS 201x.
If you didn’t read part 1, I would recommend that you start there.
Big gotcha with regard to this blog post
You cannot access the TFS data warehouse (which we will need to do) using Visual Studio Online and as far as I know, there is no way to access the data stored there in any way yet. As such, this post will make the assumption that you are using TFS 201x on-premise and can access the TFS Data Warehouse.
Same assumptions from part 1 apply and I’ll re-iterate them here along with a few other assumptions.
- You are a TFS user and will understand the features that I’m using.
- You have a basic understanding of TFS Process Templates
- You have a basic understanding of the Iteration Path hierarchical work item field that is present in the various Process Templates
- A basic understanding of virtual kanban systems as they pertain to software development
- NEW – You have a basic understand of how TFS Work Item States work
- NEW – You have a working knowledge of Excel 2010+
- We’ll be connecting to databases and programming in VBA
Just as a quick review, here is the current state of our virtual kanban system implementation.
Remember that we are using iteration paths to represent the backlog (uncommitted work) and the kanban system and the only work item state we will be (really) interested in is “Done”.
Calculating Basic Lead Time Metrics
Using the movement of a work item into the kanban system iteration path, until it gets to a “Done” state, we can now calculate the lead time for that item. The easiest way I’ve seen to do these analysis, after your kanban system has been setup and running for a while, is to use Excel to consume and analyze TFS data warehouse data about work item changes.
Developer Ribbon in Excel
The first thing we need to do is turn on the Developer Ribbon in Excel. After you’ve started Excel (I’m using 2013), right click on the ribbon and select the Customize the Ribbon option.
Turn on the Developer tab by checking the box and pressing OK.
Prepping the Spreadsheet
For this exercise, I like to create three sheets in my Excel workbook.
We will refer to the names of these sheets in our Excel VBA code.
Getting Data From TFS
Excel has the functionality to connect to easily connect to SQL Server databases and that is exactly where TFS stores all of it’s data. TFS stores the data that we are interested in in a database that is called Tfs_Warehouse.
Navigate to the Data tab on your spreadsheet and put the caret on cell A1.
Now create a connection to Tfs_Warehouse by visiting the Data tab, clicking the From Other Sources button and selecting From SQL Server.
Enter the name of the database server that is the backend for your TFS installation and use the appropriate credentials (SSO or SQL Server account) in the connection dialog and click Next.
Note – You will need to able to access the server with either your domain account permissions or a SQL Server account that has permissions to access Tfs_Warehouse database.
Select the Tfs_Warehouse database on the server and the DimWorkItem table and click Next.
Change the name of the connection to something more friendly like LeadTimeConnection.odc and set the friendly name to something more descriptive and click Finish.
An Import Dialog will pop open once you have hit Finish. Select the Properties button on this dialog.
On the Properties dialog, click the Definition tab and then change the Command Type to SQL and enter the SQL statement below in the Command Text textbox and press OK.
Now press OK on the Import dialog and you should now see the Data sheet fill up with data from your TFS database.
VBA Magic to the Rescue
Now that we have our work item data coming, we need to do a couple things:
- Narrow it down to the time period under review
- Determine what started and finished within that time period
- Calculate the Lead Time for the items that completed during this period
Caveat – I’m not a VBA Script writer by trade! I’m fairly certain there could be better ways to write this code, but since writing elegant VBA code is not my objective, I’ll just get you to the lead times. If you have any suggestions on how to better code this out, I’d love to hear from you.
Create a VBA Module
On the Developer tab, click the Visual Basic button to get to the VBA IDE.
Once you are in the Visual Basic editor, create a new module for holding your code by right-clicking on the Module node of the tree and inserting a new Module.
Now we can just start entering all of the code from below.
Declare String Constants in the Module
These strings (global) allow us to do set our sheet names and change the iteration paths that we use to model our kanban system.
Determine Vertical Range of Data
This code needs to discover the length of the data set that we’re processing. This function does that.
Create Lead Time Generation Function
This code is pretty messy but isn’t actually very complicated. What happens in this function is that we go through each row of the source data set and look for the work item entering the kanban system iteration path. We then look for the work item getting to the done state.
If a Start Date and and End Date are discovered for the work item, we make an entry in the LeadTimeReport sheet with the calculated Lead Time. If we do not find those dates, no entry is made.
You can step through the code in the IDE using F8 to step through each line of the function.
Create Public Access and Initialization Function
This code is the function that is going to be invoked by the button we put on our parameters sheet. It sets all of the global values for the module, acquires the start and end date of the period under observation, modifies the command text of the SQL query to use the dates in the query,
Now that the module has been created that does all of the data transformation work, we need a simple UI that allows us to pick a Start Date and an End Date for the period under observation and a button to kick the whole thing off.
After you have selected the Parameters worksheet, in cell A4 type out “Start Date”. In cell A6 type out “End Date”. And finally on B3 put “Period under Observation”. These are labels for our UI.
Now on the Developer tab, click the Design Mode icon on the ribbon. Now we can Insert 2 Date Picker controls onto the worksheet. Click the Insert icon on the ribbon and then click the the very last icon on the bottom right.
In the More Controls dialog that comes up, select the Microsoft Date and Time Picker Control 6.0 (SP4) and then click OK. You will now be able to “draw” out the new control on the worksheet. Draw out the first control roughly on cell B4. In the Excel Name Box, name the control startDatePicker.
Repeat the process for the second date time control and draw the second control roughly out on B6. In the Excel Name Box, name the control endDatePicker. These names are used in the script to find the range parameters.
Now we need to add a button. Click the Insert icon again and select the first icon on the top left and draw out a button roughly on cell Here is what it should look like when complete.
Generating Lead Time Data
We should have completed all of the steps required to generate lead time data for the kanban system that we’ve model in Part 1 of this series of blog posts!
If you press the buttons and everything has been typed in correctly, you should see data populate the LeadTimeReport worksheet. This will look roughly like this.
You can format the first row of the LeadTimeReport sheet however you see fit. If you want to add more rows of labels, you will need to edit the scripts as they start adding lead time entries on row 2.
I’d like to point out that in this case, I’m using the Brian Keller ALM VM for Visual Studio 2013.4 and the Fabrikam Team Project inside of that VM for data. You will need to change the script to reflect the iteration paths that you are using your kanban system in TFS.
This has been a fairly long and detailed post and I hope that you’ve been able to follow it and get the lead time data generation working in your environment.
There are more sophisticated ways of generating this lead time data (programmatically more advanced applications). The reason I wanted to use Excel and Visual Basic was to allow anyone to generate lead time data with the basic tools that are available in a normal IT shop that uses TFS. If you’d like to expand on this approach and develop an application that does this (which I have already done elsewhere), I hope that you can use this example as a guide to what you’ll need to do to write your application.
Thanks and I hope to hear from you in the comments soon. Let me know if this worked for you or how I can make this example better.
Microsoft has been making some great strides in adding features to Team Foundation Server (TFS) that allow for the modeling of the virtual kanban system that your teams might be using to manage their work. The web access kanban boards and the ability to manage WIP limits on the boards are two such features.
Kanban tooling is still relatively new to Microsoft and they are trying to adapt a product/approach that has historically been very well suited to Scrum and Traditional work management techniques, and so it isn’t much of a surprise that we need to tweak the way that we use TFS 201x to help us correctly model our virtual kanban systems. To that end, we need to take advantage of a few of the features in TFS to allow our teams to be more effective when using kanban.
This is the first in a series of blog posts detailing how we can model kanban systems on TFS.
I have several TFS related assumptions that I’m making as you read this post:
- You are a TFS user and will understand the features that I’m using.
- You have a basic understanding of TFS Process Templates
- You have a basic understanding of the Iteration Path hierarchical work item field that is present in the various Process Templates
- A basic understanding of virtual kanban systems as they pertain to software development
Iterations vs. Iteration-less Planning
The first challenge that we’ll encounter when using TFS is that there is no specific kanban process template, which is actually the right approach in my opinion. It would be tremendously difficult to create a one-size-fits-all kanban process template and I think we need to get into the habit of customizing our process templates if we’re going to be using kanban work management techniques. That said, we still need to be able to have an ability to plan in an iteration-less environment.
This is where we get a bit confusing with the features we use in TFS vs. our intent, but it will work for us.
TFS uses the Iteration Path structure to determine what is on the Product Backlog board in web access. The Product Backlog board is the current feature in TFS to visualize our kanban system so we would like it to represent things in a more traditional kanban way. In order to do this, we need to modify the Iteration Path structure and communicate with our team how it is intended to be used. This means that we need to communicate that we are using the TFS feature named Iteration Path for something other than an iteration as it would be commonly understood if we were using a Scrum work management approach.
Here we find a model of a simple kanban system.
We have an uncommitted backlog of options or ideas that we may or may not eventually work on. We have a Ready Queue which is the work we have committed to doing next, we have a Doing column that represents the actual development work and a Done column that represents that we have finished some piece of work.
Understanding Lead Time
One of the primary reasons that we need to doing all of this is so that we can calculate a lead time for our work items, which TFS 201x currently does not do for us and the way that the kanban boards are currently implemented, we cannot access the data that is captured by the kanban boards. (Product Group call out here: We want access to that data!) Lead-time is a basic and fundamental metric for measuring the performance of work through a kanban system and so we kind of need to be able to generate that information.
When you want to capture lead time data for work items, we need to identify the start and finish line for the work. Done is fairly universally recognized as the finish line, but the start line is a little harder to define sometimes. In this kanban system example, we are going to state that Uncommitted work is not a part of the lead time calculation but when we move work into the Ready Queue for the team to pull from next, the lead time period has been determined to have started.
One of the current challenges with TFS is that lead-time is perceived to have started when a card appears on the board and the cards appear on the board as soon as it is placed into the Product Backlog iteration.
Another challenge is that all work items (uncommitted or committed) may appear on the kanban boards if the work item is placed in the Iteration Path that has been identified as the Product Backlog in TFS.
To this end, with this simple workflow, we are going to use the Iteration Path feature and create an Uncommitted backlog and a Kanban System ‘backlog’.
Creating an Iteration Path that is our Uncommitted Backlog
One of the great aspects of TFS is the ease with which you can create or modify Iteration Paths. I’m going to be using Visual Studio Online for demonstration purposes. The Visual Studio Online web interface is the same as the on-premise Team Foundation Server web access interface, so if you have TFS on-premise, you can follow along just the same.
First, we need to go configure our Iteration Path structure. Once you have arrived at your Team Project page on Web Access, you can find the link to make those modifications on the right-hand side of the page.
For simplicity sake, I’ve hidden a couple iteration paths in the Released branch. For now, let’s look at the root node of our Iteration Path structure. Remember that the Iteration Path work item field is a hierarchical data type.
Let’s create an Uncommitted iteration path. Go a head and select the root node in your environment and create a path called “Uncommitted Backlog”. Make sure you are on the root node of your Iteration Path.
In our situation, the dates don’t mean anything to us, but TFS 2013 presents the iterations in this screen ordered by Start Date so we’ll use the dates to “order” our Iteration Paths visually.
Note – In drop-downs on the work items and in Excel, the Iteration Path values will be ordered alphabetically.
Now let’s create our Kanban System Iteration Path. It should also be a child of the root node and the start date should be 1/2/2012 or one day after the uncommitted backlog’s start date if you chose a different date than I did.
You’re Iteration Path structure should now look like the image above.
There is one more Iteration Path node that we need to create in order for the Web Access Task board to work correctly as well.
On the Kanban System node, create a new child called “Committed”.
Awesome! We have now created an Iteration Path structure that models our virtual kanban system.
Hooking up the Web Access Boards
Now there are two more things that we need to do on the Iterations management screen and that is hook up the two boards we’ll be using in web access to the correct Iteration Path nodes.
First, you need to right-click on the Kanban System node and select the Set as team’s backlog iteration option.
This connects the Kanban System node to the Backlog Kanban board.
Next, click the check-box on the Committed node.
This connects the Committed node to the Task Board in web access.
You might be asking yourself why we have to have the Committed node under the Kanban System node. Well, give it a try if you’d like, but currently, the team’s backlog iteration cannot be the checked iteration that will be shown as the task board.
Reviewing What We’ve Done
Now that we have our kanban system model and a Iteration Path structure that represents that system, we can show how they are intended to map together.
Because the current crop of TFS process templates don’t naturally support modeling virtual kanban systems, we are able to use process template agnostic features of TFS to model our kanban system.
So why are we doing all of this you ask? There are several advantages to this particular approach that I like.
- Process Template Agnostic
You can use this technique with any process template that uses the TFS Iteration Path work item field.
- Iteration Path based Lead Time boundaries
Currently, most teams will try (want) to use the kanban board columns but because the data is not accessible, we can’t. Other teams will model their kanban system with Work Item States, but this tends to become a mess as Work Item Template modifications need to be done on a lot of work items and frequently. This is just a PITA, especially if you don’t have TFS administration skills in-house and rely on consultants to help with process template modifications.By using membership in an Iteration Path as the means to determine when something has entered (and/or left) a lead time boundary, we free ourselves from having to use work item states as a means of creating these lead time boundaries.
- Clean Up Our Queues
One of the things we want is concise, useful queues (and queue visualizations) in any tool, including Excel, Visual Studio or the web access. Currently, web access will limit the # of work items it presents in the queues, but users of Excel or Team Explorer will get potentially long and confusing lists of things to review. While our Uncommitted queue may be (and usually is) quite long, the daily working queues and the kanban system can be made smaller and more concise. This aids planning and decision making about what to prioritize and pull daily.
- Works on TFS 2010
This technique will work on TFS 2010. We won’t get the nice web access boards, but as we’ll see in follow-up posts in this series, there is still value in using this technique to capture lead time for work items.
There are a couple disadvantages. They include:
- Can’t determine cycle time easily
Cycle time is the time between two arbitrary states in your kanban system. Using our example kanban system, I would say that cycle time of the Doing column might be 2 days, but the lead time of the entire system is 4 days. I don’t think that I would encourage my teams to use this Iteration Path technique to model individual columns.
I don’t think that this technique is natural to the VS community at large. I think it works and is a novel way of modeling kanban on TFS, but there needs to be education about how the team (and upstream and downstream partners) are using TFS.
Hopefully this have given you some ideas on how to better model virtual kanban systems in TFS. Virtual kanban systems are a tremendously valuable means to manage work, and even though TFS doesn’t currently support them in a intuitive manner, we can still use many of the features in TFS to achieve our goals. You could also use these techniques in similar fashion in non-kanban environments, if you simply want to clean up or better manager your queues.
In the next part of this series, I will show how we take advantage of this technique to calculate lead-times from your work item data.
As always, I would love to hear your thoughts or answer your questions.
Just wanted to point out that the Lean Kanban United Kingdom videos are all up! Check out my talk on Myths and Misconceptions about the Kanban Method in addition to all the other great talks from this conference.
You can find a lot more information on the LeanKanban Conference series here.
I hope you all have Happy Holidays and a Prosperous 2014!!
I should start this post with some qualifications. I’m an consultant for a company called Imaginet. We’re a full service IT consultancy. Imaginet is a LeanKanban University (LKU) Founding Member organization. I am Imaginet’s Accredited Kanban Training Program Advisory Board representative and I also sit on the LKU Management Board. I’m an Accredited Kanban Trainer (AKT) and a Kanban Coaching Professional (KCP) with LKU. That said, I’m going to try and be as unbiased in my responses as possible, but please bear with me if I rant a bit. 😀
This week seems to have been a particularly interesting week in the volume of rhetoric and misinformation that is being spread about The Kanban Method. I’m not even sure where to start, but I’m compelled to say SOMETHING!
What is Kanban
I saw a tweet from Alan Shalloway (@alshalloway) talking about a great blog post from Joseph Hurtado (@josephhurtado) discussing What is Kanban? In this article, Joseph describes the current state of confusion in the industry around the word kanban and tries to start a movement to provide some clarity.
I’m the first to agree that there is a lot of confusion around the word kanban. In all of my webinars and presentations, I take a moment to provide some clarity on this issue. I think it’s very important that we all do this.
Joseph goes on to add some definitions, which is great.
This is where I start to take exception to his blog post because he then goes on to start actually misinforming his readers. He states:
The problem is that David Anderson, LKU and some other Kanban Consultants have decided that there can be only one valid Kanban method for business or even IT, theirs. In their view if you do not follow exactly The Kanban Method, dare to call Kanban Agile or add any Lean or Agile practices to it you are wrong.
This is so blatantly wrong that I hope it is unbelievable to his readers, but I feel compelled to respond because Imaginet and I belong in the group “LKU and some other Kanban Consultants”.
Our understanding of The Kanban Method (as per wikipedia) is:
I’ve heard David (@djaa_dja) speak many times defending this definition of The Kanban Method because as far as I know, he is the originator of the name and the definition attributed to it. That seems reasonable to me. And in those conversations and in David’s classes, I have often heard him embrace specific improvement tactics from other industry-specific methodologies like Scrum or XP. Many of the LKU Kanban practitioners that I have personally spoken with embrace many of these same improvement tactics. David even goes ones step farther than many “Agile” evangelists and embraces improvement tactics from traditional project management methodologies like PMI when they make sense in a context.
What I think Joseph (and others) are doing is trying to define the meaning of the word kanban in a manner that suits them and at the same time belittle David, LKU and it’s members, for trying to protect the definition of “The Kanban Method” which we also sometimes just shorten to Kanban. Joseph and Alan also seems disturbed that we often shorten The Kanban Method to simply Kanban.
There was a time when I thought somewhat like Joseph but in a Scrum context. I often thought that people, who said “You are not doing Scrum” when a team was doing some of the tactics that the Scrum Guide but not all of them, where wrong and mean. Of course we were doing Scrum, just not all of it. I then had a conversation with Ken Schwaber and he put it very simply and it made sense and my thinking change. Ken used the game of Chess as an analogy and said to me (paraphrased) “If you use the rules of chess, you can say you are playing chess. But if you change the rules, are you still playing chess? No. The same goes with Scrum. If you follow the rules provided in the Scrum Guide, you are doing Scrum. If you deviate from the rules, you aren’t doing Scrum.” It seems to me that this is the same issue that Joseph is having an issue with, except we’re going one step further and using an abstract word (in this case) like kanban.
Joseph then goes on to create a new ‘thing’ which is great. Open Kanban. Sounds good until he describes it. And it starts to re-describe things that The Kanban Method has described. It describes some things that LKU Kanban practitioners have described. Which is honestly really flattering. As the saying goes, imitation is the sincerest form of flattery. The problem though is that now there is a competition. The Kanban Method vs. Open Kanban. And we’re back to rhetoric and bickering because honestly, we are all here to make money and grow our businesses.
To wrap up this portion, here are a bunch of thoughts that I hope counter some of the misinformation in Joseph’s article.
- The Kanban Method has a definition. I don’t think we should really argue about that.
- The Kanban Method has a singular purpose. Catalyze (encourage?) incremental and evolutionary process changes for organizations.
- David freely gives credit to all of the people who have influenced his journey and his continuing growth in this space.
- David strives to stimulate continuous improvement of The Kanban Method, especially by reaching out to the community of practitioners.
- Whatever your process is or the process that emerges to help your organization create value, that is NOT The Kanban Method, but simply what The Kanban Method helped you create.
- You’re process will likely evolve towards being flavoured by Agile or Lean thinking. They are both #reallygoodthings
- The Kanban Method is not Scrum. It does not compete with Scrum.
- The virtual kanban system that may be used to help your organization evolve WILL compete with Scrum. The Kanban Method does suggest the use of virtual kanban systems to better manage work. This doesn’t have to be viewed as a bad thing unless you are a Scrum evangelist who isn’t interested in new ideas. Scrum and Kanban both have noble goals.
- Scrum has a virtual kanban system at the heart of its work management system. It just uses larger batches than most kanban practitioners like and couples cadences unnecessarily.
- The virtual kanban system that may be used to help improve your organization will probably use some sort of kanban (visual signals, signboards)
- The Kanban Method does not advocate the exclusion of any kind of improvement tactic for the process or the organization. It just doesn’t necessarily provide specific guidance, which is fine. You are MORE than welcome to pull in unit testing, team formation, automated builds, continuous integration, iterations, tooling improvments, etc. if the specific tactic is anticipated to improve the system.
- The Kanban Method, as a methodology, won’t give you advice on a specific improvement tactic. It does not understand the context and it would be deemed “tampering” (and perhaps arrogant) to suggest improvements without information.
- The Kanban Method does provide guidance on several high-level improvements tactics that will help you create an environment for your organization to improve.
- These high-level tactics usually lack specific implementation details. Let’s call them meta-tactics that will allow for the creation of context-specific tactics.
- Don’t let myths and misconceptions cloud your assessment and the opportunity to learn about The Kanban Method, or any of these other methodologies. Please go out, learn and make your own decisions.
I’d love to talk to you about this. I’ll be at Agile 2013 in Nashville next week. If you’re going to be there and you’d like to discuss any of this, I’d love to catch up with you. Please message/mention me at @agileramblings on twitter and we’ll figure out a way to get together over a pint or two.
Part 2 of my Exploration of Estimation
In part 1, I posed the question of Why are you estimating! I hope that you thought about it and may have found an answer or two.
The next question I’d love for you to think about is What are you estimating?
I was just in a meeting that was discussing a RFP for a client. This is pretty common in the consulting industry where we see a Request For Proposal and in that, we need to define the scope of work that we can address, align our skills and services to deliver that scope of work and then provide an estimated cost for that service. Seems kind of normal. But then we are also sometimes required to provide an estimated calendar duration for the project. So in essence, we are being asked to provide 2 estimates. We then present our guess (educated) at how much work needs to be done, and here is our guess (educated) about how long it will take the team to execute on that vision.
So when the developers were being asked to provide estimates to the work in the RFP, what do you think were they estimating?
I haven’t had a chance to ask them yet, but based on my experience (as both a developer and a person being asked to provide project duration estimate), the development team is probably estimating effort and not duration.
So who estimates duration then? How do we get duration from effort? And if we stacking a guess (how fast we deliver) on top of a guess (effort), are we getting a meaningful expected duration value?
If you go back to my rant on estimation (which I will reference often in this exploration series) you will see how most organizations, in my experience, do mental and mathematic gymnastics to come up with an expected duration value.
My belief is that we are not getting a useful duration value. But everyone treats it as useful, starts building elaborate project plans and organizational activities around this duration value, and then we are all shocked when we have to change request the project, drop scope, or scramble like crazy (and usually with questionable quality) in the latter half of the project when it becomes painfully obvious that we’re not going to make our original duration estimate. Either way, the initial setting of expectations based on the layer of several guesses seems to be a Bad Thing™.
So I’ll leave you with this final question, what are you estimating?
p.s. I will explore better ways soon! Just bear with me for a bit longer!
Part 1 of my Estimation Series
A while I go, I wrote up a bit of a rant on a crazy estimation scenario that was presented to me by a colleague. If you didn’t get a chance to read it, you can find it here. We’ll call that rant Part .5 of this series of blog posts on estimation.
Since then, I’ve seen a bit of a swell on twitter of the #noestimates hashtag and a lot of discussion on topic. I was recently saw a tweet from Allan Shalloway that prompted a bit of a conversation:
(click imagine to see original tweet and conversation)
As you might have guessed, my thinking is more aligned with the #noestimates crowd and I’ll elaborate that over the coming months here, but this tweet started a conversation that I’ve had before.
Why do you estimate?
If I’m going to encourage you to stop estimating, it’s really important that we understand what I’m encouraging you to stop vs. what you might actually be doing.
As the conversation continued, Allan stated:
…which made wonder if we’re confusing prioritization with sizing, which is actually quite common.
So I won’t re-post the entire twitter conversation here, but I’ll start to share my thoughts on the why of estimate.
When I engage in an “estimating” exercise with a team, I very often try and restate the activity as a sizing exercise. For me, this starts us down the road of using the language that more accurately describes the end goal of our exercise. We want, to the best of our ability, describe how “big” we think this work item is. I’d like the team to use their past experience and compare the current work item (requirement, user story, etc.) against similar work items they’ve worked on before. This is a relative sizing technique that is used all the time by other agile methodologies such as Scrum or XP. You’ll often here the term “yesterday’s weather” in the same conversation about agile estimation techniques. The best predictor of today’s weather is yesterday’s. The team’s recent experience is the best predictor of its near-term current capabilities.
To me, the really important point of this exercise is sizing! Not scheduling. Not prioritizing. Those are completely different activities! The product owner/business representative on the team will tell you, perhaps with size as a decision input, what is next and when they might hope for it to be done. I generally expect them to help the team constrain the story, but the delivery team are the ones that are responsible for determine the size of the story.
So in my mind, the intent of the “estimation” exercise is to allow the whole delivery team to determine the relative size of the story compared to work items they have done in the past.
So why are we asking delivery teams (Development, Ops, anyone who is creating value) to size their work items? This is where I think all of the estimation craziness and problems start.
We need to provide some sort of indication of the anticipated financial impact to the organization making the request of this work item. We also need to provide information that would allow us to set a delivery timeframe expectation. And the next level of this problem is to take 100s (or 1000s) of these work items and provide the same financial and delivery timeframe expectations. This is, for most teams, really really hard.
And I will state that it is my belief that size is not the primary factor in determining cost or delivery timeframe. Will a bigger story cost more? Usually, yes, but not always. Will a bigger story take longer? Usually, yes, but not always. What if to delivery a story, a team has no external dependencies? What if it does? What if the story is big, but a really well known problem? Unknown problem? What if the team is missing a team member when it finally pulls the story from the backlog? What if the team composition has improved? There are so many things that can change the cost and expected delivery timeframe in addition to the size of the story that are very difficult to predict.
So in my mind, we are trying to size our work so that we can help business decision makers make the best decision for the organizations economic well being.
I’ll leave you with a couple homework questions. What is the intent of your team’s estimation exercises? Why is your team performing those exercises?
Part 2 will explore my approach to providing business decision makers with better information so that a team (business and delivery groups) can make better decisions on behalf of our organizations.
I was recently delivering some Kanban training at Yahoo! to a great group of people who were all struggling with many of the same problems we all deal with. Overburdening, long lead times for features and quality challenges, all of which exacerbate each other! Almost all of these people described having been on previous process improvement initiatives. Actually, in some cases, they described being in a non-stop process change initiative. And almost all of them were fatigued by all of the process change initiatives and were very weary of this new “Kanban Method” thing that they were doing.
This seems to be a very common problem that I experience. None of the prescriptive methodologies are solving the underlying problems, organizations are jumping from one prescriptive approach to another and employees are getting tired of it.
The fact that the Kanban Method really isn’t like this is one of the things that has drawn me to it. Let’s revisit the first of the 4 Kanban Method values.
Start with what you do now
Straight from Wikipedia – The Kanban method does not prescribe a specific set of roles or process steps. There is no such thing as the Kanban software development process or the Kanban project management method. The Kanban method starts with the roles and processes you have and stimulates continuous, incremental and evolutionary changes to your system.
This is a central tenant of any LKU Kanban professionals approach to teaching or coaching an organization with The Kanban Method. How can you suggest changes if you don’t know what the problems are? How can you expect a change to succeed without understanding the capabilities of the people within the organization?
When the people are Yahoo! were presented with this first value, they were able to almost immediately relax. We started to hear things like
You mean we don’t have do do anything different?
We can use some of these concepts and ideas within our current process.
Both of which are absolutely true and it is important that people understand this when it comes to starting a Kanban Method implementation.
We then present people with the remainder of the values, which are:
- Agree to pursue incremental, evolutionary change
- The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. Sweeping changes may seem more effective but more often than not fail due to resistance and fear in the organization. The Kanban Method encourages continuous small incremental and evolutionary changes to your current system.
- Respect the current process, roles, responsibilities & titles
- It is likely that the organization currently has some elements that work acceptably and are worth preserving. We must also seek to drive out fear in order to facilitate future change. By agreeing to respect current roles, responsibilities and job titles we eliminate initial fears. This should enable us to gain broader support for our Kanban Method initiative. Perhaps presenting the Kanban Method against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities and perhaps the wholesale removal of certain positions will help individuals to realize the benefits.
- Leadership at all levels
- Acts of leadership at all levels in the organization from individual contributors to senior management should be encouraged.
All of which suggest that we do nothing but create an environment that will be supportive of the people who will be finding opportunities to change their processes. That’s it! You’ve now started a Kanban Method implementation, which has often been described as an intent more than a prescriptive, concrete set of things that you have to do.
At Yahoo!, after we had presented everyone with a new approach to thinking about how to approach their problems, we did start to give them some high-level tactics which they could apply when they were ready.
Over the course of the next couple days, we then showed them examples of how they could get more information about how they worked (Core Practices in the Kanban Method). And at no time did we tell them that they had to do any of them, but we described the benefits and limitations of these tactics and by the end of the 2 days of training, most everyone had discovered something valuable and told us they’d be trying to use some of these things in their teams right away. We didn’t know which of the tactics that these people would be trying, but we were encouraged that they felt empowered to start trying to use them at their own pace.
In a landscape of teams and organizations getting tired of process change initiatives, it was very rewarding and encouraging to find a group that when presented with The Kanban Method, were excited at the new way of thinking and that they weren’t going to be forced to do something. They were very excited that they would discover what their problems really were and then they would plan out their own changes to the process.
A question that I often get while speaking with people is:
What is the difference between Kanban and Scrum?
I know this topic has been explored at length in many places on the internet and also with a variety of different answers, but I’m going to put my thoughts down and share them with you because:
- I still feel there is a lot of misunderstanding on this topic and I think I have something to add to the conversation
- People still ask. The more of us who can blog and promote conversation on the topic, the better.
- Getting my thoughts out and in a more concrete form that I can reference (and send people to reference) should promote better conversations as well.
So. Here it is. Kanban Method. Scrum. I imagine I’m about to step on some toes but I hope we can have some good debates and not conversations filled up with rhetoric.
At their hearts, both methodologies are attempting to do the same thing. They are attempting to advance the state of the art in work management predominately (but not only) in the area of knowledge work.
Both are heavily influenced by value-systems. Scrum is primarily influenced by the Agile Manifesto which describes the “Agile” value system. The Kanban Method pulls a great deal of its values from a Lean value system. There isn’t really a “Lean Manifesto” but the works of Taiichi Ono and W. Edward Deming contribute to a common understanding of what it means to be a lean thinker. They are not the only contributors but have made the most significant impressions on the Lean/Kanban community. The Kanban Method is also influenced by the Agile Manifesto and the values inherent within it.
Both methodologies believe in delivering software incrementally to maximize the opportunity to get feedback and capture ROI. Incremental delivery of software also mitigates risk and maximizes the opportunity to learn from a business, process, and technical perspective.
Both methodologies are striving to make people a central aspect of the system, which they should be. 😀 Scrum strives to “protect” the development team from the influences of “traditional” project management tactics. Kanban suggests that we need to allow solutions to problems emerge from the people in the system. Kanban also believes that changes should not be forced on people, but that people need to own the changes and be supported throughout the transition. Both systems try to give people the time and space required to improve.
Similarities with Significant Differences
Both approaches promote an intent to learn and improve. In Scrum this is primarily achieved through the retrospective tactic which is an Inspect and Adapt-based tactic. The team will get together (frequently) to discuss processes and tactics that have been going well and should be continued, things that haven’t gone well and should be changed for the next sprint. I do not believe that Scrum teams put sufficient emphasis on this aspect of Scrum and that the common understanding of Scrum doesn’t promote this aspect strongly enough. I also believe that the scope of the area under review primarily focused on the team. Again, this may not be the intent but it is, in my experience, the way it is implemented.
The Kanban Method has learning at the core of the methodology. There are several reasons for this, but the primary reasons for this are:
- Do nothing without understanding the current situation
- The current situation is always changing
- New challenges (technical and business) are always arising
- People, who are at the heart of the system, need to be learning constantly in order to be improving themselves and the system continuously
- Without a learning approach to improvement, you can’t use experiments to test improvements
The Kanban Method uses more of a Plan – Do – Study – Adapt (PDSA) approach to learning and this is different from a Inspect and Adapt approach.
Scrum prescribes a cadence and that all activities happen within that timebox. If you didn’t guess, this cadence is called the sprint duration. Sprint is just another name for the resulting timebox.
The typical Scrum cadence now a days seems to be 14 days (2 weeks) and follows the following sequence of:
Sprint Planning -> Execution (daily Scrum meetings) -> Iteration Review -> Retrospective -> repeat cycle
Scrum’s Sprint duration is a great innovation over the traditional approach to managing work. Because the guidance on duration has never been longer than 30 days, Scrum teams have always been guided to strive for shorter feedback cycles than traditional projects. Scrum teams have also been guided to produce increments of software at the same rate. In order for Scrum teams to do this, work has to be decomposed and understood by the development teams. Work gets prioritized more frequently and this prioritization allows these teams to be agile from a business perspective. Risk can also be explored and mitigated within the sprint and that knowledge feeds back into the prioritization loops of the team.
In the Kanban Method, cadences are just as important as they are in Scrum. Many Kanban teams have a Queue replenishment cadences. This is effectively the same as the Sprint Planning activity in Scrum. Many (most?) Kanban teams have a daily stand-up meeting where the team discusses the current state of the kanban system, looking to remove impediments and manage work at risk of taking longer to deliver than expected. Many Kanban teams will have product demos (iteration review) that coincide with an opportunity to deliver or deploy the product being built. And many Kanban teams will have Operations Reviews which are an opportunity to discuss the Kanban teams progress and improvements with the rest of the organization.
The significant difference between the two systems is Kanban does not typically use timeboxes and all of the cadences in a kanban system can happen when it is best for the organization to do them.
Timeboxes are a mechanic that Scrum uses to minimize disruption to the development team. In Scrum, changes to the Sprint plan are strongly discouraged. Plan the two weeks, then let the team work uninterrupted. This has allowed for great improvements in productivity in software development, but what if we could apply that protective attitude to a single piece of work. So while a team was working on an item, they were not disrupted but they could be counted on to pull the next highest priority item on the queue as soon as they were ready to pull some work. The business could prioritize as much as needed while the team had work in progress.
Timeboxes are also used to provide a consistent interval that external parties can interact with the Scrum team. Business can plan around a 2 week cadence to injecting new requirements into the system, and downstream partners (IT, Sales) can count on getting new work or increments of software every 2 weeks as well.
In Kanban, the cadences that are most appropriate for the external partners can be allowed to emerge and do not need to be enforced (or tied together) by the development team. There are advantages for shorter cadences, but what if we could get all the way down to Just In Time and we no longer had cadences on replenishment and delivery? We can still have cadences on Ops Reviews or any other ritual that benefits from these cadences. What if replenishment happened every week, or daily, and delivery happened every 4 weeks? Or on the 25th day of each month? That is an advantage that many organizations benefit from when adopting a kanban system as a way to manage work.
Pull-based , WIP Limiting Systems
Both Scrum and Kanban ARE Pull-based, WIP Limiting systems. Scrum uses, in many senses, a kanban system at the heart of how they manage work. The Scrum team PULLS only the work they can manage into the iteration. The iteration planned work is the maximum amount of Work In Progress (WIP) that the Scrum team will be expected to deal with. The limit of the amount of work in the iteration is set by the team’s previous velocity measurements. But then we will start to encounter the limitations of the Scrum work management system. Scrum teams can still start a lot of work and suffer from the inefficiencies of multi-tasking. Having a lot of work in progress (started) but not finished is a significant source of waste in our industry. Humans cannot multi-task, we context switch and we all know that context-switching is expensive. Scrum does not have specific guidance to limit multi-tasking within a team. (Note: Please correct me if I’m wrong here. Haven’t read the Scrum Guide recently)
In a Kanban Method implementation, the focus is to limit WIP at a more granular level. Preferably at the work item level but we can also let the most appropriate granularity emerge by leveraging the learning aspects of the method. We use WIP limits to guide our intent to finish work before we start more work. We also use WIP limits to reduce overburdening. WIP limits are a great way to fine-tune your Kanban system and how and what to set them to would require a lot of explanation. Suffice to say that Kanban’s WIP limiting tactics allow for significantly more tuning that Scrum’s Sprint Planning tactic.
Scrum teams tend to categorize work into two types, User Stories and Bugs. Both can be decomposed into tasks. Scrum actually provides guidance that there are “product backlog items” and that User Stories and Bugs may be types within that backlog. Additionally, Scrum allows work items to be of the same type but vary in size. This size is often described in Story Points. So one User Story may be 3 points, another may be 13 points. And there is no common interpretation of a point between different Scrum teams. What a story point actually means is specific to a Scrum team.
Kanban Method teams tend to have numerous types of work. Requirements, User Stories, Use Cases, Bugs, Defects, Improvement Activities are all examples of work items I’ve seen on Kanban boards. Whatever makes the most sense for the organization. Kanban differs from Scrum in that it generally does not try to categorize work by a size. The size of the work items in a Kanban system don’t really matter from a management and monitoring perspective. Once the item has been committed to by the Kanban team, they should finish it within the expected timeframe given how big they think it is when starting. It is when it starts to exceed expectations that the Kanban team should start to pay closer attention to it and take corrective actions if possible. But other than setting an expectation when the work is committed to, sizing isn’t important from a work management point of view. It should be noted though that smaller work items are usually easy to manage from a development point of view because the larger a work item is, the more likely that item is to contain significant unknowns and lots of uncertainty.
Both Scrum and Kanban use metrics to help drive behaviour and decision making.
There is really only one metric in Scrum. Velocity. Teams will assign a estimated value to a work item that is used to indicated how “big” it is. The team will work as many items as they can in a sprint. Once the sprint is completed, the values of all completed work items will be summed up and that was the teams velocity for the sprint. This velocity will be used to determine how much work is pulled into the next sprint during sprint planning. You can create burn-down or burn-up charts based on the velocity metric as well. Typically, this is as scientific as a Scrum team will get. The summing of a subjective measure of size on a work item.
In The Kanban Method, all measurements are intended to be quantitative. Something that is measured and the value is (usually) not really debatable. In Kanban, we tend to measure time (lead/cycle) and quantities of things (work items) at various points in the workflow. These are all concrete, measurable attributes of work in the system. All that is needed is start and end-points and you can now start the clock when work gets into a state and then leaves the state. This can be as simple as started and finished or much more complicated with numerous states and parallel activities steams within a workflow. We also measure how many of something are in a particular state as well at a time as well. Ultimately in Kanban, we measure how long it took something to get somewhere. With these measures, we can determine rates, quantities, and speeds of work items and establish a deeper and more meaningful understanding of the system.
Generally speaking, Scrum prescribes a set of activities that are performed within a Sprint. There is not any guidance on particular daily development activities but generally you should be analyzing, developing, testing, user acceptance testing throughout each day as applicable. But most Scrum teams will always do Sprint Planning, Development for the rest of the sprint, Iteration Review and Retrospective.
The Kanban Method does not prescribe any workflow. The workflow that you model in your Kanban system should be YOUR WORKFLOW, and it should evolve as required based on things that are observed and needed by the organization. A kanban system is expected to evolve and change over time as the organization (and it’s needs) change over time.
This also includes cadences. Scrum generally prescribes that the workflow happens within a cadence. Kanban does not prescribe cadences. It does appreciate the value of cadences but feels they should emerge where needed and the interval should be as long as needed, but Just-In-Time as much as possible.
Kanban does not prescribe any roles. Roles and responsibilities (and changes in them) should emerge based on the organizational maturity and understanding of the development process.
Scrum generally prescribes three roles, Scrum Master, Product Owner, and Team Member. If you’re on a Scrum team, you’re normally categorized as one of these things. I think that this can be a good thing, but it can also backfire as people try to find their place on the team. The individual esteem system of a person is influenced by what they think their place in the world is. Changing that place in the world can shake a person’s esteem and confidence, which tends to diminish their acceptance of a system or change.
Most people’s interpretation of Scrum is team-centric. This isn’t a necessarily a bad thing, but at some point it may become a limiting way of thinking when trying to scale Scrum or work with upstream and downstream partners of the Scrum team.
The Kanban Method takes a system thinking approach to process problems and expects the impact of changes to ripple throughout the entire workflow of the organization as business need/idea goes from inception (idea) to realization (software). Generally speaking, the kanban system is intended to protect the “work” (and therefore the team) from being disrupted so we don’t have to have a team-centric view of things. We can take a system thinking view of things and understand that every interface to our “team” system is actually an interface with a larger system that could benefit from The Kanban Method implementation.
This post has been much longer than I expected and I’m not sure I’m even done, but I think I’ve covered off what I think are the similarities and difference between Scrum and Kanban.
What I want to leave you with though is that neither approach is wrong, nor do they need to be exclusive of each other. There are teams that have started with Scrum and arrived at a Kanban Method implementation, and there are Kanban Method teams that have arrived at a very Scrum like (or Scrum exactly) implementation because that set of tactics and tools were the best way to manage work for that organization. It should never be a Scrum vs. Kanban conversation, but rather a question of what is the best from both methodologies that I could use.
I believe there are aspects of The Kanban Method that Scrum doesn’t adequately address in our quest to better manage knowledge work workflows, so I do think that while you can always have a system with “No Scrum”, you should never have a system with “No Kanban Method” in it.
Thanks for following along on this rather epic article. I hope to hear from you, both positive and negative comments are welcomed.
I recently had the privilege to speak that the Calgary .NET User Group’s new lunchtime series. This series is an opportunity for people to come and hear about exciting new topics with a minimal time commitment. And in this case, CNUG President Dave Paquette felt is was about time that we have a talk about Kanban.
Here is a link to the video of my 50+ minute presentation. It’s the first time they’ve video taped one of these, so please don’t be to critical of the quality. 😀
You can find the slides on Slideshare here.
The one thing I’d like to pull out specifically from this presentation was the exercise we went through (11:24 in the video) in understanding what it was we were actually talking about. In my slide deck, I indicated there are three common definitions of kanban out there and that we really needed to understand which one we were talking about in any conversation around the topic. And in an informal little survey of what participants though kanban was, we got the all three definitions from different people in the audience. The three commonly confused definitions are:
- kanban – signboard, visual signal, card
- kanban system – pull-based work(flow) management system, normally at the heart of a kanban method implementation
- Kanban method – An approach to incremental, evolutionary process change for organizations
Very often when I am discussing the Kanban Method with people who are new to any of these ideas, they are often getting them confused and it is really important that we clarify which we are talking about.
Do you know what Kanban you’re talking about? 😀
I received a great question from one of my webinar attendees and this question has also received a bunch of attention from the Kanban community since this visualization first surfaced in the summer of 2012 ago at the Kanban Leadership Retreat in Austria.
How do we measure our maturity using the Kanban method?
I have used the technique that came out of Mayrhofen at #KLRAT as the basis for how I work with teams to monitor Kanban maturity. There isn’t a “standard” set of questions that the Kanban community uses in the creation of the kiveat chart. In general, it is being suggested that each team/coach comes up with a context-specific way of measuring and ranking maturity within the 6 practice groups that applies to “that team”. That visualization can then be used to monitor the anticipated growth for that team over the course of time. One thing that the Kanban community is cautious about though is “comparisons” between kiveat charts and assessments. Since each assessment is relatively subjective, comparisons should be avoided as it would be hard to compare and may potentially be misleading to the team.
That said, here is how I use the chart.
I have a set of questions I ask per category. On a scale of 1 to 5, 1 being “We do not do that”, 3 being “We do that”, 5 being “We could teach someone to do that”, I look for activities that would allow me to select one of those values for one of my questions. As an example:
Question: Identifying types of work
Observation: Does the team identify different types of work? Do they have User Stories, Bugs, Improvement Tasks, etc. described within their process? If they do not, they would be a 1. If they do, they would be a 3. I’d then look for evidence that they are capable of teaching work item type defining to another team, or that they could do so if required. If they could, they would be a 5.
I go through all of my questions for an axis of the chart and give them these rankings. I then take the average value of all of the answers and that is my data point on the kiveat chart. My visualization category currently has 10 questions in it, so if I get 35 total points/10 questions, I get a 3.5 visualization score on the kiveat chart.
My Limit WIP category currently has 5 questions, so 15 points/5 questions would give me a 3 Limit WIP ranking on the chart.
Following this pattern, I eventually end up with 6 axis on the kiveat chart, all ranked from 1 to 5 and this “coverage” can be used to describe the team’s Kanban maturity from my perspective.
David Anderson, in some of the slides I’ve seen him use and in talking to him, describes a progression of novice to experienced tactics within each category and each of his axis has different scales to represent the increasing maturity on that scale. He does arrive at the same kind of coverage visual and describes that coverage as an indicator of maturity from his perspective. My kiveat chart and David’s would not be comparable though and this is completely OK and encouraged. As I mentioned above, the current thoughts within the Kanban community are to discourage direct comparisons between these kiveat charts.
What kinds of questions would you use to measure you’re companies Kanban maturity?