Them’s Fighting Word!
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:
The Kanban method as formulated by David J. Anderson[1] [2] is an approach to incremental, evolutionary process and systems change for organizations.
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.
Who is Estimating?
Part 3 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.
Part 2 explored What are we estimating. Usually we are asked to estimate effort (cost) which is then turned into a schedule (duration) which are two very different things.
The next question I’d to explore is Who is doing the estimating?
In my experience, normally it is the technical people who will be doing the actually work (coding, sql, ux, etc) that are asked to provide an estimate. Developers are the best and most familiar example. And while at first glance this seems reasonable, when you start to dig into the entire workflow required to move an idea to reality in software, it begins to look a bit inadequate.
As we can see in the workflow, there are several phases of life that a feature/user story/use case goes from to be brought to life, only one of which is development. Often, there are many tasks across elaboration/analysis, development, quality assurance, user acceptance and IT/Ops just to name a few common phases. Are developers performing all of these tasks? Do they take into account the effort required in all of the other disciplines when they do their estimates?
So why is it that developers are usually the only ones estimating effort?
Surely developers aren’t the only one working on your projects!! (Don’t get me wrong. I was a developer growing up, so I’ve definitely thought that the software development workflow revolved around me!) But this is a team sport, and without the business analysts, QA professionals, IT professionals and what ever other role is in your delivery workflow, we may have a difficult if not impossible time getting our software out the door!
So as a part of your estimation process, how do you understand the effort and/or time required to get work through the entire delivery process? Do you take into account all of the phases of life, and hand-offs, and interactions in your delivery process? Do you get all of the people involved in the estimation process? In fact, I’ve seen (not often) teams involve a tester in the estimation efforts, but very infrequently do I see analysts, DBAs or IT/Ops folks involved in the process, even when they’re role is critical to the delivery of the product!
So who is involved in YOUR estimation process? Do you have all the people you should have involved?
And are you asking yourself this question in conjunction with the other two questions I’ve already asked you about? Hmmm….. I hope you’re all thinking about all of these questions! I hope to present a couple more questions in the next week and then start to tell you how I think we can start make some real changes in the way that we do all of this estimation stuff!!
What Are You Estimating
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! 
Why Are You Estimating
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.
Intent
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.
Why?
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.
Final Thoughts
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.
Visual Studio 2012 Update 2 – Great update but not a great updater for Build Controllers/Agents
This is just a short post this week, as I’m preparing for a very exciting 2 weeks. The first week has a lot of Kanban training (50+ people) in California and then I’m off to Chicago for LeanKanban North America 2013 where Imaginet will have a booth showcasing the Kanban/Agile/Process consulting side of our ALM Practice.
To kick this off, I have to repeat what is hopefully very common knowledge out there in internetland – Microsoft has released Visual Studio/TFS 2012 Update 2 and this is a very exciting release for me. Included in this release are the new Kanban boards along with the new board editor to go with the WIP limits that were put in for Update 1! If you are trying to do Kanban on TFS, you need to to check out Update 2. If you haven’t been introduced to it yet, check out the Imaginet webinar I did talking about Kanban on TFS 2012.2.
One of the other things that Microsoft spent a lot of time on for Team Foundation Server 2012 Update 2 was the actual update process. You can check out Brian Harry’s blog for a many more details, but it does talk about the improved update experience.
One thing that is conspicuously absent though is any talk of an update for the build controllers and/or agents. That is because there were no improvements to the update process for them. This wasn’t obvious from anything I could find on the web, and as I struggled using the updater to update a client’s build agents from 2012 RTM to Update 2, it eventually came out on our internal Imaginet ALM mailing list.
Now, as unfortunate as this may seem, the TFS team did give us a great new feature in TFS 2012.2 that makes this installer issue a non-event. I’m taking this quote from the Brian Harry blog referenced above:
TFS 2010 Build controller/agent compat – We’ve received feedback that simultaneously updating all TFS build machines along with the TFS server is not practical – particularly in large organization where there can be hundreds of build machines, many of which aren’t even known to the TFS administrators. Because of this, in update 2, we have added support for TFS 2010 build controllers and agents – so you can update your TFS 2010 server without updating your build infrastructure and your builds will just keep working. In general, we expect to continue this pattern from here forward – a new TFS server will support build machines from one major version back. This adds the additional benefit this version that you can use the TFS 2010 build servers on Windows XP (in the event you need to do that) while the TFS 2012 build machines don’t support XP. Based on the feedback we’ve gotten from our MVPs, this change is very popular and makes people’s lives much easier.
It was my desire to have all machines in the TFS ecosystem updated and running on the same version but this is no longer required where build agents are concerned, and there were no significant updates to the build controller/agents that I know of, so I decided “Let’s see how this compatibility feature works!” and left the build controller and agents alone. That was on Friday though, so I don’t have an update on how they are actually working though! 
I will post an update when I hear from the client how things are going! <crossing fingers>
So my advice to you is if you want a completely up-to-date TFS ecosystem, uninstall then re-install TFS on build server (recreating what was there) or if you don’t care that much about keeping everything up to date, just do nothing and leave your build servers at 2012 RTM. I’m sure by Update 3 or 4, Microsoft will get the update working nice and smooth for everything! It is something that is important to them.
The Kanban Method – Change Catalyst with No Changes Planned
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.
Final Thoughts
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.
ALM Adoption Success Story – Success Factor 3 – Co-location
I don’t think I can fully communicate the value of co-location.
Any time I have been asked to help a company in recent years, the engagements have started out with an assessment. I don’t believe that I can provide sound advice unless I understand what the problems are and what the organization’s capabilities are.
One problem that EVERYONE has had so far is the absence of an effective place for their teams to work. Software development is a highly creative endeavor that requires (usually) a significant amount of collaboration between teammates and it constantly surprises me how organizations build terrible places for teams to try and achieve this!
When we started out with the client whom all of these Success Factor posts are about, the development team was spread out across ½ of a floor in an office tower and there were 2 members in a different city. Check out my hand-scribbled floor map with the initial, planned layout of the team members.
This is actually not bad compared to many companies I have observed, but this is far from optimal. The deficiencies that aren’t obvious from this floor map include:
- No team-specific collaboration space. Had to book meeting rooms and hope one was available.
- The Devs and PM have no whiteboard space. They are in cubicles.
- The BA, TW (Technical Writer) and CSM (ScrumMaster) were packed into a large office with minimal whiteboard space.
- PO (Product Owner) and HW (Hardware guy) were alone in their offices.
- There was no place to have daily stand-up meetings or to have our card wall up where everyone could see it.
- The sponsor was on the opposite side of the building.
For a team that is intending to collaborate frequently and intensely, this is a very poor setup. Our sponsor was spending in excess of $100k/month on the team in that room and he wanted to make sure we had every advantage to maximize that cost. So before we even kicked off the project, we made a rather bold request to have a board room near the sponsor converted into a team room. And our request was granted!! The facilities people were a little scared that we’d damage the boardroom table that was in there, so they had that taken out quickly, but the resulting floor plan looked like this:
Now we were excited! We had a room that could hold everyone. There was room for everyone but the PM and HW guy, due to the nature of their roles, didn’t need to participate as intensely as the rest of us, so they maintained their offices. And since our PO was also maintaining some business workload, she maintained her office as well. But all three team members attended all the meetings that we had in the team room and would often drop in to see how things were going. Let’s take a look at the team room.
I have to say, this is the best team room I’ve ever had the pleasure of working in. We had wall-to-wall whiteboards on the West and South walls, and the North and East walls where covered with large PostIt notes. The SE corner of the room had a projector screen and the projector sat on the SE corner of the team table. The computer on the East wall ran Skype and TeamPulse, the Agile Project Management Tool that we used on a daily basis (from Telerik). The room had a Skype account that was always logged in and you could call up that account and it would always auto-answer with video and put the caller on the projector. There were two microphones in the middle of the big table that would allow everyone to talk from where they were sitting with whomever called in.
I can’t say enough about the sheer wall space in this room. It was fantastic. On the wall-to-wall whiteboards, we had everything from architectural diagrams, to class diagrams, server layouts to retrospective results. We had everything on those whiteboards and they would be able to stay up for as long as needed for the team. We would write our retrospective notes up there, and leave them for the entire next sprint. Then the that sprint’s retrospective notes we be put up, and compared, and discussed. Then the former sprint’s notes would be erased. We had a constant rolling reminder of how important continuous improvement was to us.
The PostIt notes were used to keep less volatile things like our value statements right up in front of us. Also, team policies like our Definitions of Done, or our Prioritization logic where up there for everyone to see. There was never any doubt about how we wanted to work when you were in the team room.
We were creating a mobile system that included on-board tablets in trucks and we had our QA station right there behind our QA professional team mate, our PO and our BA! They could check specs, and then turn around and try it out right there in the QA environment. And if there was ever a problem, the developers could (and usually would) hear about it right away. That was one great aspect of our room that allowed our quality process become pervasive of everything that we did in that room.
I can tell you about a time that our QA lead was working on a test script in Microsoft Test Manager. Then he turned and tried the test step on the tablet and discovered a bug for a feature that was in the iteration. He called the developer over, who saw the defect right away. The QA lead logged the bug and the developer, whom had luckily just finished up a task, was able to pick up the bug and fix it right away. Our QA process was such that we could fix a bug, submit the code, all the automated quality checking mechanisms would run and then we could push the passed build up to the QA tablet where the bug had been fixed. In this particular case, the whole process took less than 1 hr. Discovered, Logged, Fixed, Built, Deployed, Re-tested, Passed. It is very rare for me to see a team perform this well.
But I totally believe that a big contributor is the team room that we’ve built for this team. Every team member feels the others pain when something doesn’t go right. This causes us to behave differently. Less selfishly and with a much more holistic approach to building the software solution.
And that was a known feature. The benefits of having the Product Owner, Business Analyst and Sponsor all within 20 feet of the developers is unbelievable. When anyone has a question about a feature or an idea that we’re trying to make real, the entire stack of business-focused people are right there, immediately available to answer the question. The only time that this team ever builds the wrong thing is when we are building something for someone who isn’t in the room. And you can bet that we escalate that immediately to our sponsor. Because he is 15 feet away. 
And he just drops in all the time!! If he has a problem, he tells us. If he is curious how we are doing, it pokes his head in. He will see us working on a problem with our process and lend a hand if he can. And you can bet that this closeness has made the team much more aware of his concerns and challenges. It never feels like Big Brother is watching because there is so much transparency on the team that it is always about trust and helping to get the job done.
I could probably go on and on about all the benefits of this team room but I’ll wrap it up for the moment and leave the rest to your imagination so that you can think about what the benefits of this team room would do for your team.
The Difference Between The Kanban Method and Scrum
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.
Similarities
Goals
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.
Value-system Influences
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.
Increments
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.
People-centric
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
Learning
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.
Cadences
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.
Work Items
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.
Metrics
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.
Differences
Workflow
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.
Roles
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.
System Thinking
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.
Final Thoughts
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.
A Rant about Estimation – When Will We Stop Being Crazy
Warning: This is a bit of a rant. If at any point in this post, I seem like the crazy one, please tell me somehow. Comments, Twitter, LinkedIn. It would be really valuable to hear your thoughts. But I also encourage you to think about the situation, context and information I provided and decide for yourself whether the way we are acting is crazy. There are craziness checkpoints along the way! And if you think any of this is crazy as well, try to do something about it!
I had a work colleague recently ask a question on our internal mailing list. A summary of the question would be:
A company that is using ‘agile’ wants to know if their formula for converting story points into hours is sound because executives are doing short term (< 6 months) planning.
This is an example of how they break down their work. Seems reasonable and just like many other companies.
They also provided a formula. This is where the craziness starts which is startlingly common in our industry.
… and a sample of how the formula works.
Ok. At this point, all that is going through my head is “OMG”. Now comes the process by which they populate the formula.
- PMs provide the Epic Point estimate
- Developers decompose epics and provide point estimates for the user stories.
- Teams points (epic points or user story points?) per resource per sprint are tracked.
This is COMMON in my experience working with many organizations in our industry.
In all fairness to my colleague, he knows this is crazy. The developers in this organization know this is crazy. This is a typical scenario when executives and senior managers are trying to get information but using techniques that we have proven don’t work in our industry.
The good thing is, the way that they decompose work is fine and the formula will work as long as we don’t have have 0 velocity or 0 team members. 
The existence of the formula and the process by which we find numbers to put into it are where the craziness begins. First, a bit of information on “story points”.
Dave’s Craziness Meter
Story points are an abstraction agile teams use to REDUCE the perception of accuracy. 1 story point will require “some small” bit of effort to complete. 2 story points should require about twice as much effort as 1 story point. So that would be 2 times “some small bit of effort”. 5 story points require about 5 times “some small bit of effort”. I hope I’m clear about how we are purposefully reducing the perception of accuracy. Why? Because it incredibly difficult (usually impossible) and time consuming to create accurate estimates for the effort required to do knowledge work using the time units desired by decision makers!
I don’t even advocate using story points to my teams anymore. As numbers, it is too easy for people to plug them into a formula to convert them into something they are not intended to be converted into. I now generally only advocate sorting work by sizes like Small, Medium and Large.
Now let’s discuss the numbers that go into the formula from the example.
To start, a PM will make an point estimate in story points. In the example, it is 200 story points. I don’t know why a PM is doing an estimate on technical work.
Point estimates are bad. They imply accuracy where it normally does not exist. We have a point estimate of an abstraction that is trying to reduce the perception of accuracy. At least it is a single point estimate using an abstraction, so it could be OK except humans are optimistic estimators. Our interpretation of an estimate usually means that we expect the epic to fall in the middle of a normal distribution of epics and we have a 50/50 chance of falling under either side of the curve.
The problem with this is that the magnitude and likelihood of doing better than our estimate is the same as the likelihood and magnitude of doing worse than our estimate. And the other problem with this approach is it’s wrong. Using information from industry observations, we see that plotting the actual effort of our epics will form a log-normal distribution .
On a log normal distribution, the chance of doing better than our estimate is smaller than the chance of doing worse than our estimate. This means our epics usually fall behind the mode which means that they took more effort to complete than we expected. Simply put, when humans provide point estimates, we are usually wrong.
Let me state that again. When we estimate in knowledge work, we are usually wrong! And the formula above actually understands that!! The historical team buffer is a built-in admission that we need to add 20% to our estimates to make the numbers get closer to the actual values we observe!!! And I’ll bet that most epic actual values exceed the padded estimate!
Dave’s Craziness Meter
Ok, so point estimates are bad. And humans are bad estimators. That all came from the first point of the PM creating an epic point estimate. The rest should go more quickly. We’ve covered a lot of ground in that first exploration of the situation.
Next we have the developers decomposing the epics into stories and providing point estimates on those stories. All of the problems that we encountered in estimating above apply at this level as well.
The problem now is that it doesn’t work to simply sum up the points for the stories to get the points for the epic. If we look at the problems with point estimates, imagine doing that 20-100 times and adding the value together. We know that our our estimates are wrong (by at least 20% and probably more) and the impact of how wrong you are has a significant impact on effort. The only way to potentially add up the stories to see how much the epic will be is to estimate stories with an expected value that is the mean on a log-normal distribution and run a Monte Carlo simulation using all the stories in the epic. (That is an whole other blog post!)
I’m betting that a Monte Carlo simulation isn’t being used to turn the developer’s stories estimates into a meaningful epic estimate. Never mind the observed expansion (dark matter as David Anderson refers to it) of requirements that we see as we build the software and discover what we’ve missed. It’s always there, we just needed to build the system so that we could find it.
So our estimate is probably wrong. Significantly wrong. Period. Let’s move forward.
The next part of the formula is:
and the data in our example looks like this:
10 points is the average points per resource (I hate that word) per sprint. I’m assuming that they have standardized sprints for all teams in the organization. 2 is the number of team members (much better description) that will be working on this epic.
Do all developers produce 10 points per sprint, regardless of the task? Regardless of the skill level? Are we talking senior or junior developers? Is the business problem something they’ve done before, or something novel? Technology is know or new? Stat holidays? What if a developer is sick?
That 10pts could also be interpreted as developer velocity, and as we know, velocity can be highly variable for a team and is even more variable for individuals. In Scrum, we always talk about team velocity because it hides the variability of individual velocities that we know exists by averaging out the effort expenditure across multiple people over time. And we also know that velocity cannot be compared between teams! One team might have a velocity of 10 while another may have a velocity of 20, but the former team is more effective. The velocity number itself should not be interpreted as a standardized representation of effort that can be applied to any large scale planning activity (multiple project, multiple teams). It only works when you know the project and you know the team and it’s capabilities and past delivery history in specific contexts.
Dave’s Craziness Meter
So we have an epic estimate (crazy) divided by a developer velocity # multiplied by the number of team members (crazy). The next step is to multiply by the Historical Team Buffer otherwise known as padding the whole estimate.
The number from the formula is 1.2 in order to make the whole estimate 20% larger or 120% of the original estimate.
As I mentioned above, this buffer is a built-in indication that our estimates are wrong! We know we can’t deliver the epics as expected given our estimations, so we pad the estimate to make it closer to what we actually expect to do.
Dave’s Craziness Meter
So after all of that, we’ve arrived at a value of 12 sprints required to deliver this epic.
Phew!! Now we need to turn this into an expectation of effort expenditure or schedule.
Oddly enough, based on the question from our internal mailing list, we were not able to determine what the executives wanted. They either want to know how long it will take or how much it will cost. Unfortunately, I’d guess that they expect to get both from that number. They expect that the project will be done in 960 hours of developer effort which will occur in 12 weeks of calendar time.
That is 12 sprints and 80 hours of effort per sprint. That seems to be 2 developers for 40 hours per week or 80 hours per week.
So, I can with a fair bit of confidence tell you that the work week is 40 hours, 2 man weeks is 80 hours, and if a sprint is 1 week long with 2 people, the project will spend 960 hours of effort in 12 weeks.
What I can’t tell you is if both developers will work 40 effective hours per week. You almost certainly will pay them 40 hours per week, but whether all of that effort is applied to the story is another question. Emails, meetings, slow days, coffee cooler conversations, code reviews, design sessions, non-project related tasks are just some of the kinds of things that eat into that 40 hour work week. Never mind sickness or other work absences. Most people I speak with use 6 hours as a number for planning how much time a developer can effectively spend on a story. I’ve seen organizations where a team member regularly, for a variety of necessary reasons, spends less than 2 hours per day on a project they are supposed to be full time on.
So that does two things to our calculation. We’ve determined that the story is now about 960 hours in effort. If the developer can’t work on it 80 hours per week, the number of iterations has to go up! If the developers are only effective 4 hours per day, that means we have to spend 24 iterations on the project to get it done. Or potentially, the developers can deliver it in 12 weeks, but have to work 40 hours of overtime per week, which means the costs go WAY up for the project as the organization has to pay overtime. Let’s not even try to incorporate the diminishing returns on overtime hours, especially in an environment where that overburdening is chronic.
So as an executive, I wanted a fairly certain number for how much effort a specific epic is going to take so that I can do appropriate planning for the next 6 months. And 960 hours and 12 weeks calendar time is something I’m going to hang my hat on. I mean, 960 is a pretty precise number, and the “confidence” that the process has given the organization in that number must be pretty good.
Dave’s Craziness Meter
And since we’re doing organizational planning and planning multiple epics for multiple teams in the six month period, I’m also making the assumption that all epics that are 200 points are the same. And I’m assuming that all story points are the same effort. I’d have to deduce that that any epic of 100 points would take exactly half as much effort or half as much time as any 200 point epic. Any 200 point epic is exactly the same as any other 200 point epic. There is a lot of confidence in our formula and approach.
Dave’s Craziness Meter
Ok. I’ve maxed out my craziness at this whole endeavor. My hope is that you think this is all a little crazy as well because if we start to accept that we’re acting a little crazy we can start to do something about it.
Final Thoughts
I’d like to clarify that this post is not intended to be critical of people who are using Agile estimation techniques and trying to fit inside of an organizational traditional project planning methodology. We are all trying to do the best that we can. But sometimes we get stuck in a way of thinking. I’m hoping that this blog post might just jolt some of you into thinking about these problems and deciding to try and do something about them.
The formula used is as an example in this post is just that. A formula. And a very common kind of formula as well. The values you input into the formula will work as long as you don’t have 0 velocity or 0 team members. (No one likes division by 0.) In Kanban we use a lot of formulas and a scientific approach to understanding our work and workflows.
It’s the drivers underlying how we want to use formulas that we really need to be critical of. The formulas and the data that we feed into them has to make sense and drive us towards creating valuable data points on which meaningful decisions can be made. If we use complicated formulas and suspect or fictitious data as parameters, that makes the output worse than garbage because it provides some sort of sense of accuracy and a false sense of confidence because we think “this must be right. Our formula is sound.”
As long as we, as an industry, support this behavior, we’re are contributing to the continuation of this problem.
There are solutions to this problem, but exploring those options will be explored in another blog post.
But in the mean time, I’d love to hear your feedback! Do you think I’m crazy or do you think our industry is crazy?
Intro to Kanban at the Calgary .NET User Group’s Lunch Series
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? 😀
Latest Posts
-
Getting Docker running on Windows 10
Just a quick post about a couple things I’ve learned yesterday and today. Docker is now available to run on Windows 10. I’m not going…
-
Using PowerShell to Set Your Azure SQL firewall rule
If you’ve read a couple of my recent blog posts, you’ll see that I’ve been working in PowerShell a lot lately. I’ve also been working…
-
Building a TFS 2015 PowerShell Module using Nuget
Update: Unwittingly, I hadn’t tested my Nuget approach on a server with no Visual Studio or TFS installations on it and I’ve missed a couple assemblies…
-
Using IE Automation in PowerShell to Simplify Browser Based Tasks
As a consultant, one of the things that I need to do regularly is log into my client’s WiFi networks. Sometimes this is a once…
Agile Ramblings 