“Kanban vs. Scrum: The Big Smackdown” — Video now on YouTube

A few weeks ago, I participated on a panel discussion at the January meeting of AgileDenver.  Be sure you click through to the link with the meeting description before you view the videos.

Part 1
http://youtu.be/nhfhU0hqyQ4

Part 2
http://youtu.be/sfBILgeUS2w

I hope no one will take this as me having a personal jihad on Kanban, because that is not true.  I do, however, hope to inspire people to stop, and think twice, before incorrectly applying Kanban as a software development approach.  In my earlier post, I talk about why I think that is a mistake.

I also hope no one will take this as me thinking Scrum is always better than Kanban or vice versa.  Context is everything, and I simply suggest that those approaches should be applied to the context for which they were designed.  I think people should also give great deference to the creators of the respective approaches in this regard, so as to avoid what Martin Fowler calls semantic diffusion.  While Fowler calls it semantic diffusion, I have always known it more simply as the telephone game.  Luckily, we have good shepherds around like Anderson, Schwaber, and Sutherland, to remind us of the original ideas.

I also want to reassure my blog followers that I don’t intend to spend a lot more time writing about Kanban vs. Scrum.  I have some new articles that are very Scrum specific coming soon.

Related Articles:

• Kanban vs. Scrum: Kanban is NOT for Software Development, but Scrum is!

• One way to handle Bugs and Production Support in Scrum

• One Way to Handle Mid Sprint Scope Changes in Scrum

Dealing with Hard to Find Bugs (Sprint Killers) in Scrum

This question was asked in an online forum(I’m paraphrasing):

> How do people here handle the impact of difficult errors/bugs (but not legacy bugs) on sprint progress?  Like ones that take weeks to solve?

In my professional opinion, the answer is: we make them transparent and try to improve upon them — at Daily Scrums, Sprint Reviews, and Sprint Retrospectives.

I tend to coach teams to handle bugs in Scrum using the Bradley Bug Chart.

One of the aspects of the Bradley Bug Chart is that bugs like the one mentioned (i.e. non legacy bugs) end up on the Sprint Backlog.  Because they end up on the sprint backlog, if one is using Story points and velocity, no story points are assigned and no velocity is gained from fixing bugs.  This, once again, helps provide transparency on to the lack of progress that the team might be making due to bug fixing.  The truth can be a hard pill to swallow, but the truth will also help set you free from these mistakes in the future.

The transparency should help all involved understand that there is something that needs improving, that is dragging down the team’s ability to produce new features and working software.  I would argue that this is not a sprint killer.  It is simply a fact of complex software development.

The real issue comes down to this:  Scrum transparency is trying to tell your team something.  What is it trying to tell your team?  What is your team going to do about it?

Related Articles

• The Tao of Scrum – Transparency

• One way to Handle Bugs and Production Support in Scrum

• One way to Handle mid-Sprint Scope Changes in Scrum

ScrumCrazy.com update:

• Looking for Agile/Scrum/Kanban Coaching or Training?  Contact us for more info.  We have some good specials going on right now, but they won’t last long!
• Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc.  Feb 28th in the Denver Tech Center.  More info and sign up here!

Kanban vs. Scrum: Kanban is NOT for Software Development, but Scrum is!

Last week I was a panelist at the Agile Denver meeting, where the title of the panel was Kanban vs. Scrum! The Big Smackdown!

If you click through the link, you’ll notice that the title was misleading, on purpose, as is the title of this article(“Kanban vs. Scrum…”).  However, I want to catch the attention of those who think that this is even a valid question or consideration.  The title also speaks to a common problem in the industry that has been around for several years, and won’t seem to go away.

There are a number of software teams and organizations that think they should choose between Kanban and Scrum as their software development process.  This is a GIANT and RISKY mistake, in my professional opinion.

It’s not an either/or proposition.  Scrum is about software development.  Kanban is about change management.

There are several reasons why choosing Kanban as your team’s software development process is a mistake.

1.  You are applying Kanban to the incorrect context.

Would you use a hammer to insert a screw in a wall?  You can, but you’ll probably damage your wall in the process, and the same is true of Kanban as a software development approach.  David Anderson, the creator of The Kanban Method, has apparently said this over and over again since 2005, but no one seems to listen.

Don’t take my word for it, listen to David:

“Kanban is NOT a software development life cycle or project management methodology! It is not a way of making software or running projects that make software!” — David Anderson

“There is no kanban process for software development. At least I am not aware of one. I have never published one.”  — David Anderson

“It is actually not possible to develop with only Kanban.  The Kanban Method by itself does not contain practices sufficient to do product development.” — David Anderson*

(*The first two came from the “over and over..” link above.  The last quote was sent to me via email from someone at David’s company.  I think they just pasted in something David had already written)

I should also mention that others have mentioned to me that David talks out of both sides of his mouth about Kanban, Agile, and software development, perhaps trying to capitalize on the fame and success of Agile software development.  That may be true, but it may also be true that David has been saying all of these things for years and no one is paying attention to what he says, which is unfortunate.

2.  Kanban is modeled more after the assembly line and manufacturing.  Scrum is modeled more after creative product design.

Which do you think more closely resembles software development?  Laverne and Shirley on the assembly line at the Shotz Brewery? Or the group of NASA engineers on the ground who saved the lives of the Apollo 13 astronauts by coming up with a creative solution to a problem within a time-box?  If you think software rolls off of an assembly line, then I think that it is unfortunate that you’ve never worked in a creative software development environment — it’s AWESOME!

Maybe my Laverne and Shirley reference is oversimplified.  The reason to use Scrum instead of Kanban for software development delves down into process control theory, and the difference between a “defined process” and an “empirical process.”  In short, a defined process works better when the inputs and outputs to the process are well known and repeatable (like a manufacturing line).  An empirical process works better when the inputs and outputs to the process are less known and very difficult to repeat.  No two software features are alike.  This is why it’s darned near impossible to measure software productivity directly, even though some naive “bean counters” still try to.  Like the stock market, no one metric will predict it accurately, but a range of indicators can help predict it more accurately.  So, in summary, Scrum is based on empirical processes like product design.

One of the very key parts of empirical processes is the characteristic of inspecting and adapting the product.  Think of yourself making a pot of soup from scratch, without a recipe.  Think about all of the “taste-tweak ingredients-taste” experiments(feedback loops) you would need to get a pot of soup that tastes good.

Scrum has the frequent feedback loops built in, for a variety of audiences(Dev Team, Product Owner, Stakeholders, Users) , and for a variety of topics(process-Sprint Retro, product-Ordered Product Backlog, product-Sprint Review, product-Valuable/Releasable Increments).  Kanban has no such built in loops, but again, that’s because it wasn’t designed for software development!

3.  From a Complexity Science view, Kanban is for ‘complicated’ work while Scrum is for “complex” work.

I know the Kanban folks don’t like hearing this, but I think Ken Schwaber was right when he said this, and I think history will prove him right about Kanban as it was described in David Anderson’s book.  In short, the Cynefin model defines 5 domains, of which 2 of them are “complicated” and “complex” work.

‘Complicated’ work is best solved via ‘good practice’ and ‘experts’ who can find ’cause and effect’ fairly easily. When I think of ‘complicated’ work, I think of an the IT support person who sets up your computer or trouble shoots it.  Yes, you need an expert to solve these problems, and the vast majority of the time, the steps to solve these kinds of problems are fairly consistent and repeatable.  They are not exactly repeatable, just mostly repeatable.   If the steps were exactly repeatable then they would fall into the ‘Simple’ domain of Cynefin.

‘Complex’ work is best solved via ‘safe to fail experiments’ and one can only ascertain cause and effect after the fact.  Each Sprint in Scrum is a ‘safe to fail’ experiment because, while the Sprint increment is always releasable, the business side of the house makes the decision on whether it is safe/valuable to release it or not.  In the case of an increment that is un-safe, the team course corrects and comes back with an increment the next sprint that is hopefully safe or more-safe.  These safe to fail experiments can be repeated over and over again until it’s time to release the increment.

Applying Kanban Correctly

Having said all of the above, there IS a time and place for Kanban — a correct context, if you will.  If you’ve been reading closely, that context is as a change management process, which is ‘complicated’ work, and requires that there be already existing processes in place.  So, if your software team is doing XP, Scrum, Crystal, Waterfall, RUP, DSDM, FDD, etc, then you can layer Kanban on top of it to help find bottlenecks and waste.  Also, for all of those teams out there that don’t use a software development process(framework, approach, etc) that is named in the industry, you’re probably doing cowboy coding, ad-hoc, or command and control project management — none of which is a software development process either.  So, layering Kanban on top of crap will still yield crap.

For those that want to apply Kanban at the enterprise level to monitor the flow of work through their Scrum teams (Or XP, Crystal, etc), or want to use it for IT support or Dev Ops, I say have at it and I hope it helps you.  I imagine just visualizing your workflow alone will help in those contexts.  I myself have recommended and coached Kanban for a couple of teams — but only because those teams exhibited the right context for Kanban to be successful.

Bottom Line

Having said all of this, just visualizing your workflow and the other Kanban principles is not enough for software development.  Software development has things like business value, technical complexity, and user experience/acceptance/adoption — all of which are not addressed directly by Kanban.  Scrum does address these areas, as I have shown above.  But hey, let’s not forget, the Kanban Method is “not a way of making software or running projects that make software.”  Would you criticize a hammer for not doing a good job of being able to insert a screw into a wall?

Related Articles

• The Tao of Scrum – Transparency

• Scrum For Lay People

• One way to handle Bugs and Production Support in Scrum

ScrumCrazy.com update:

• Looking for Agile/Scrum/Kanban Coaching or Training?  Contact us for more info.  We have some good specials going on right now, but they won’t last long!
• Finally, a Scrum certification course aimed at ALL members of the Scrum team! Developers, Testers, Business Analysts, Scrum Masters, Product Owners, etc.  Feb 28th in the Denver Tech Center.  More info and sign up here!

Agile and Scrum Hiring: Recruiters Mistakenly Looking for 12 Years of Agile Experience

We used to have the same exact challenge in the Java world.  Java came out somewhere in the neighborhood of 1995, and by 1998, recruiters were looking for people with 5 or 10 years of Java experience.  It happened to me often as a young budding Java programmer.

I’ve seen this happen with Agile as well.  I work with a lot of recruiters and partners on a lot of initiatives, and one of them is doing Agile and Scrum “phone screens.”  Before I do a phone screen for a client/recruiter, I ask for the job description so I know what they are looking for.  When I see job requirements that ask for something like “12 years of Agile”  or “7 years Scrum Master experience,” I have a talk with the recruiter.

I usually just politely say something like this to the recruiter:

“Agile really didn’t exist until about 2001, and didn’t really start taking off until about 2008 or later.  Even today, most organizations are relatively new to Agile.  The folks that were involved before 2008 are generally early pioneers that now charge about $200-1000/hr for their services.  So, if you’re looking to hire one of the pioneers, I can certainly refer you to them.  On the other hand, if your client is new to Agile and didn’t realize what they were asking for, I’d be happy to collaborate with you to tweak the job description to what it is they really *are* looking for.”

(Agilistas may want to to quibble with some of the facts or dates in that statement, but it’s fairly accurate, and it gets the point across.  The intended audience is recruiters, not Agilists.  Having said that, I welcome feedback and corrections!)

One other point of note is that there are a lot of people who claim they were doing “Agile” or “Agile Project Management” who are essentially “glossing over” or attempting to deceive about their “X years of experience in Agile.”  I have several ways of figuring this out in my phone screens, but I won’t mention my tactics here as they are trade secrets of ScrumCrazy.com .    Scrum Master and other Agile job descriptions that require numerous years of experience tend to draw out these fakers even more — and I’m sure that’s not what the clients really want.

So, if you as a job seeker run into this issue, feel free to refer to this article to help explain realistic expectations when looking for good Agile or Scrum people.

For you recruiters out there, feel free to contact me about my phone screen services, but also understand that the person who referred you here is trying very much to help you in your quest to make your clients happy, just as I am.

In the interest of transparency,  I (very mildly) financially benefit from the phone screens that I mentioned, but I don’t want this blog post to come off as a pitch for services.  Having said that, I feel like I’m providing a fairly low cost, high ROI service that helps the entire Agile community as a whole.

A Great Link for Patterns on How to Hold a Great Agile Standup Meeting

I never cease to be amazed by the great work that Martin Fowler has on his web site.  (In all fairness, though, this post seems to be mostly from Jason Yip).

Anyway, GREAT LINK!

“It’s Not Just Standing Up: Patterns for Daily Standup Meetings”

http://martinfowler.com/articles/itsNotJustStandingUp.html

Also, while you’re here, you might want to take a look at one of my older blog posts:

“Bad Smells of the Daily Scrum”

http://scrumcrazy.wordpress.com/2010/09/18/bad-smells-of-the-daily-scrum/

As usual, all feedback welcome.

P.S.  Have you noticed that I’ve been posting a lot more lately?  One reason is that I’ve had more time lately to write, and another reason is that I figured out that WordPress now has a feature that allows me to schedule when the posts are to be delivered, so I can just queue them up! Sweet!

.

One Way to Handle Bugs and Production Support in Scrum

Dear ScrumCrazy readers,

I need your help. I’m working on a Scrum strategy for handling bugs and production support on a Scrum team. This is the first draft of the chart below. I already have a couple of changes I would like to make, so I’d appreciate it if anyone could provide feedback on the chart below. Just hit the “comment” button below or email me directly with your advice. Thanks!

The Scrum Guide doesn’t directly address how to incorporate production support and bugs into your Scrum implementation. As such, it is left up to the implementers to decide how to handle it. The strategy(chart) below is one I’ve developed as a result of coaching teams that are new to Scrum.

I hope you don’t need the chart. I’ll say it again. I hope you don’t need the chart below. I hope that you have so few bugs and productions support issues arise, that you don’t even really need to worry about classifying bugs or coming up with a technique to handle production support. But, for the teams that need some guidance on how to incorporate these issues into their Scrum implementation, see below for one way to approach it. I also feel compelled to say that if you find yourself needing this strategy/chart often, you probably have some serious root cause analysis and retrospecting to do on these occurrences.

Why I include “Bradley” in the name.

Please be sure and read the “Preface” section on the chart below. There is an 8.5 X 11 PDF download below the image.

It’s a little difficult to see here on WordPress, so you might want to view it on my web site.

Download (8.5 X 11 PDF):  http://www.scrumcrazy.com/file/view/ScrumBug8x5x11.pdf

So, what did ya think?  Just hit the “comment” button(or “Leave a Reply” form) below or email me directly with your advice.

Steve Denning – Rattling the Cages of Command and Control Managers on Forbes.com

Are any of you following Denning’s recent articles on Forbes?  He is “killing it” for Agile.

I especially like the bottom link…

http://www.forbes.com/sites/stevedenning/2011/04/29/scrum-is-a-major-management-discovery/

http://www.forbes.com/sites/stevedenning/2012/04/09/the-best-kept-management-secret-on-the-planet-agile/

http://www.forbes.com/sites/stevedenning/2012/04/11/why-cant-the-c-suite-grasp-agile-management/

http://www.forbes.com/sites/stevedenning/2012/04/17/the-case-against-agile-ten-perennial-management-objections/

Anyone have opinions on Steve’s work?  I’m not familiar with it other than passing references to his book.

A User Story Checklist

Sometimes it’s difficult to determine if something is a User Story or not.  Not everything a software team does is a User Story.

In my other article, User Story Basics , I talk about the definition of a User Story.  I will use that definition to make a checklist of characteristics a User Story must have.

1. Does the story describe new or changed functionality in the system under development?
2. Is the functionality primarily of value to a stakeholder playing a role other than the role of “developer on the development team for the system under development”?  Said another way, is the functionality primarily of value to a Non Development Team stakeholder?
3. Is there a fairly unique written description of the story?  (This can be just a couple of words, like a title)
4. Have conversations about the story, that clarify story details, taken place?
5. Does the story have acceptance tests that convey and confirm when the functionality of the story is complete, correct, and present in the system under development?

If you cannot answer “Definitely, yes!” to all of the above 5 questions, then it is almost always… NOT a User Story.

With respect to Question #2, I tend to define ¨developer” fairly broadly, like Scrum does.  From the Scrum Guide: “[Development] Team members often have specialized skills, such as programming, quality control, business analysis, architecture, user interface design, or data base design…”.  On some development teams, people who play a role of developer also play a role of “product support member” for the system under development.  In this way, sometimes User Stories describe functionality that is important to someone doing production support.  Other than this one exception, though, functionality and features that are primarily of importance to developers are almost always not considered User Stories.  On the other hand, there is nothing wrong with a developer suggesting some functionality to a NDT Stakeholder, and/or convincing a NDT Stakeholder that some functionality will be primarily of value to that stakeholder.  If that stakeholder agrees, then you can re-classify that functionality as a User Story… so long as you can say “Yes” to all of the other questions above.

A question that often comes up is, “Should Fixing a bug be represented as a User Story?”  The answer is, it depends.  The only question we might have trouble answering “Yes” to is #2.  The first thing you should ask is this: What (already delivered) User Story Acceptance Test(or tests) fails due to this bug?  If you can’t point to one specific acceptance test, then it’s probably a missed acceptance test(meaning one was overlooked when the story was originally implemented) or a legacy bug(a bug introduced before you adopted User Stories), in which case, the bug should almost always be represented as a new User Story.

Best Practice – Minimize Manager input in Retrospectives

One of Scrum’s main tenants is about self organization. Self organization is difficult enough to achieve on its own, especially with a new Scrum team or a team who has members who are new to each other on it. In the context of this article, when I say “Manager”, I mean someone who has a large amount of input in determining the company advancement (performance reviews, raises, promotions, etc) of any individual on the Scrum Team. It could be someone a team member reports to, or it could even just be a supervisor or team lead. Sometimes a Manager plays a Scrum role like Product Owner or Scrum Master. I’m *especially* talking about those managers. Those managers should not attend the retro, or at the very worst case, should attend only a minor part of the retro(See “Strategies” below).

It should be obvious to Managers (though often it is not), that honest genuine feedback about how to work better as a team is very hard to get with a Manager in the room. Every time a person opens their mouth, they are taking a political risk if their manager is there, and that is not a safe environment for true collaboration and innovation. Managers, if you don’t believe me, try the strategies below for 3 sprints, and judge the results for yourself. You, as a manager, have every right to ask the team, one day after the retrospective is over, for their plan of action on improvements. I say one day after because I’d strongly prefer that you not come into the room where the retrospective is being held once it is over. Often times there are things on whiteboards that you may or may not understand, and again, that becomes unsafe.

Strategies

• Appoint a Facilitator
  • If a Manager does not fulfill a Scrum role, then the team should appoint a facilitator, preferably one totally independent of the team. Good candidates for this are Members of other teams with good facilitation skills and/or Scrum Masters from other teams. As a last resort, if that’s not possible, then appoint someone on the team who would be a good “neutral” facilitator. It’s ok if that team member also participates in the retro, but you can leave that decision up to them. Have the team prepare any specific feedback that they have that involves the Manager in their private retrospective, and present that feedback to the manager as a team. (Remember that they may have no specific feedback for the Manager, but often they will ask the Manager’s help in implementing Retrospective Action Items.)
• Part-Time Retrospecter
  • In the case where a Manager(or team lead) plays one of the Scrum roles (PO, SM, or developer), have the team, as part of their retro without the Manager, decide which topics will be discussed with the Manager. Any topic that is not chosen for discussion is not discussed with the Manager. In particular, any feedback the team has for the Manager in their Scrum role, have the team present that as a unified team rather than individuals. Also allow the Manager to raise their own independent topics, of course. If the Manager strays into one of the topics that the team has not chosen to discuss, then inform the manager of the outcome of the team discussion.

Excluding the Manager from the Retrospective is not an attempt to usurp the Manager’s authority or anything like that. It is to create the safety and experimentation that is required for great innovations to occur. The Manager still has a very important role to play — see The role of Managers in Scrum .

Related advice

• The role of Managers in Scrum
• Best Practice – Make Retro Action Items Highly Visible
• Best Practice – Review the Action Items from the Previous Retro in the Current Retro
• Best Practice – Change Up Your Retrospective Format

Related articles

• Best Practice – Look to the Scrum Guide *First*
• How I Classify Coaching Advice
• The Tao of Scrum – Transparency

I Mostly Hate Software for Managing Scrum Teams

Update February, 2012: I’m currently seeking my next engagement as a Scrum Coach or ScrumMaster, so please contact me (You can use the “About” tab above) if you know of an opportunity.

I often get asked to evaluate a particular Scrum tool or to compare the relatively value of one to another. To be honest, tool evaluation is not something I spend significant time on. Most teams I coach have little choice about which tool to use, so I usually just a) try to encourage them to use more manual techniques and b) help the team adapt the tool usage to their optimum performance/usage, which sometimes means no usage.

I hate the tools

Ok, hate is a strong word, but I’m generally anti-tool when it comes to managing Scrum artifacts and data. I strongly prefer more manual techniques (Scrum Boards, sticky notes, story cards, white boards, wikis, etc).

Reason 1: Tools often hurt more than they help. (Decreases Productivity)

The vast majority of the time I have seen Scrum teams extensively using a tool, it is wasteful or aids in creating poor habits. It’s pretty hard to justify spending money on a tool that decreases overall productivity. I’m amazed at how many companies do this. I also believe that most of these tools have a huge amount of bloat in them, and thus the bloated features either a) obscure the needed features or b) waste a lot of time with very little ROI in terms of value.

Reason 2: They usually encourage bad habits, or at least enable bad habits. (Decreases Transparency & Productivity)

• Bad Habit # 1: The worst habit they encourage is that they often obscure transparency by hiding data inside the tool that has to be …started up, logged into, and menu driven to the point of wanted info. Transparency in Scrum is VERY important, which is why I favor more manual techniques. This obscurity is extremely widespread as it affects the product backlog and/or stories, sprint backlog tasking, teamwork, optimizing with a burndown chart or other sprint progress monitor, etc. Transparency aids in inspection and adaptation, so the converse is also true: obscurity detracts from inspection and adaptation and thus, detracts from the empirical nature of Scrum.
• Bad Habit # 2: They discourage mis-use of good techniques. For instance, in many tools, there is no direct support for story tests/acceptance tests directly with the User Stories themselves. One tool at least allows some basic html formatting and tables so that you could put in some concrete examples like those that are encouraged by the “Specification By Example” technique. However, that tool’s HTML formatting is very clunky and far inferior to any decent wiki.
• Bad Habit #3: Having a tool encourages double entry. I’ve seen teams where, because they were forced to use a tool but also wanted a good Scrum Board, had to do double entry of the same information. Giant waste of time.
• Bad Habit #4: A tool encourages mis-use of metrics created by Scrum related data such as velocity. Many managers and executive types will try to do draw incorrect conclusions from data tracked in such a tool. Yet another giant waste of time. The managers and executive types should instead be focusing on whether the users of the system are getting value out of the features that are being provided. While some management has a responsibility to focus on productivity in software development, micro-analyzing the Scrum data is not a good way to do this.

Reason 3: The development team usually has the tool forced upon them, or usually has no choice but to use a particular tool. (Decreases Self Organization)

Besides the normal effects of top down mandates (poor adoption, minimal ROI, etc), the elephant in the room created by mandating tools is that it greatly harms self organization on a Scrum team. Mandating particular tools or tool usage is just another form of command and control management. To achieve Scrum’s benefits, self organization is absolutely vital, which means, when it comes to tools, the team should be able to make their own choices.  I want the team as a whole (and preferably not the ScrumMaster at all) to create, maintain, own, love, and care for their own artifacts.  Having said all of this, it’s perfectly acceptable for management types to try and organize company strategy around goals and timelines — I just don’t believe that Scrum software tools are a good way to do that.

In Conclusion…

There, I said it… I’m generally anti-tool for Scrum artifacts and data.

In a future blog post, I intend to talk a little about some special contexts in which I think tool usage is ok, and about my general views as to the kinds of tools that I like. Teams where multiple members are working mostly remote is one exception to my generally anti-tool stance. I’ll talk more about that in the future post.