This survey is different, and I took the time(about 10 minutes) to fill it out. I suggest you do as well.
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.
It’s not an either/or proposition. Scrum is about software development. Kanban is about change management.
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:
(*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.
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.
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.
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.
I’ve been thinking a lot lately about Scrum patterns. To that end, I’ve drafted a conceptual model, which is depicted in the below image. (You may want to click the image twice to see a bigger view of it)
“Sprint Progress Monitor” is my term for what used to be called the “Sprint Burndown.” In the 2011 Scrum Guide, Sprint Burndowns were no longer required but some way of monitoring sprint progress, via summing the remaining work, was still required. In the Scrum Guide, it is made clear that these practices can be implemented using several techniques, and “techniques may vary” from team to team. So, this is what inspired me to use the term “Scrum Technique Pattern.” A Scrum Technique Pattern(STP for short) implements the intentional gaps left by the Scrum Guide. Teams can inspect and adapt their technique patterns, while still fulfilling the Scrum framework. Said another way, there are intentional “variation points” in Scrum, and the STP’s are different ways of implementing those variation points.
“Optional Scrum Patterns” are patterns that can be used in conjunction with Scrum, but are not specific implementations of Scrum techniques as specified or required in the Scrum Guide. These can be just about anything, but they must follow and/or support Scrum principles in order to be considered as an Optional Scrum Pattern.
I also see the need for the ability to create a “mashup” of different Scrum patterns to create a set of practices and techniques for a particular team or context. For instance, we might start out with a Scrum Starter Kit that includes things like:
Any of the above patterns could be interchanged with other patterns, and the Scrum implementation would still conform to doing correct Scrum. Presumably the change to different patterns would be an attempt to improve a team’s ability to delight their customers and users.
Who writes these patterns? Where do they come from?
In a word, anywhere. I’ve seen dozens of them on the internet and in books. I’ve documented a few original ones myself(though many of mine are adapted from others, and I would make every reasonable attempt to give credit where credit is due). I would not be attempting to create all of these patterns, but to assemble them and label them so Scrum practitioners can easily understand which of them are optional, and which are fulfilling required practices of Scrum. Of course, it will also become helpful to understand where these patterns fit into the grand scheme of Scrum, and I have some ideas along those lines, too.
I will keep iterating on this concept, and I hope to get back to you with more on this topic in the future.
Filed under: Agile, Organizational Change, Release Planning, Scrum, Scrum Adoption, Scrum Strategies, ScrumMaster Tips, Story Points, The Daily Scrum, The Retrospective, The Sprint Review, User Stories | 5 Comments »
Hello ScrumCrazy followers,
I want to let you know that I am now a Professional Scrum Trainer with Scrum.org. I won’t be an employee of Scrum.org, but I am a trainer who is licensed to offer official Scrum.org courses, which lead to Scrum.org Scrum certifications.
What this means:
As more details emerge, I will pass them along, but I will work very hard to keep the “sales talk” to a minimum in my blog posts. While we’re on the topic, I will be available for coaching and consulting again starting in January 2013. Of course, I am always available to talk about providing training courses. (See, that wasn’t so painful!)
I am very much looking forward to collaborating with the Scrum community in general, as well as with my fellow trainers, where I’m sure I will learn a lot.
As I said in my post yesterday, this also means that I will begin publishing blog posts regularly again. I have quite a few queued up that just needing polishing and publishing. I look forward to blogging to you soon!
Founder and Scrum Coach-in-Chief, ScrumCrazy.com
Hello ScrumCrazy followers,
I know. It’s been quite a while since I’ve posted a blog post. I have been working very diligently behind the scenes on something quite exciting. I apologize that I haven’t been posting much lately.
Not to worry, as I will begin posting much more regularly starting just after my big announcement tomorrow.
Tune in tomorrow to see the big news!
Founder and Scrum Coach-in-Chief, ScrumCrazy.com
I had the good fortune of being in a Q&A Session at Agile2012 with Ron Jeffries and Chet Hendrickson, early pioneers of Extreme Programming(XP), and both now Certified Scrum Trainers. Ron and Chet were sitting on the “expert couch” taking questions from the audience. I decided to break the ice by going on stage (questioners had to sit in the “therapy” chair next to the couch, and were time-boxed to 10 minutes) and asking them the first question of the Q&A session.
Keep in mind that this is just my recollection of the event. I’ll encourage anyone present to correct or add to what was said from their recollection. I lobbed them a softball of sorts. It wasn’t a hard question, but I wanted to hear their answer as Agile Manifesto authors. A friend in the biz had recently asked this question of me:
How do you interpret this Agile Manifesto principle?
I asked Ron and Chet to give some background on what that principle was meant to convey. Ron spoke from a programming perspective mostly. He said that simplicity refers to Kent Beck’s 4 rules of simple design. Kent’s definition stresses:
“…In priority order, the code must:
The above is copied from Ron’s article on Emergent Design. Ron added that simpler is often simpler than you think, and simpler is often smaller than you think. He mentioned the phrase “the simplest thing that could possibly work” as a reminder to keep design and code simple.
Chet then chimed in on the topic of slicing stories smaller. By slicing them smaller, we can de-prioritize smaller stories in a more surgical way, thus avoiding work that is not needed right now, and may be never needed. There are also other huge benefits to smaller stories in that they are easily digestible, and thus less work to understand and implement. Chet stressed that smaller is probably smaller than you think. I then chimed in and mentioned a concept I had read in one of the XP books. If all of the details of your user story won’t fit on a card, then you should use a *smaller* card so that your stories are sized smaller because you’re clearly making stories too large and probably need practice at making them smaller. Chet finished by mentioning that, while simple is simpler and smaller than you think, you should be constantly inspecting and adapting your “simplicity” optimum.
If you’re printing this post, it can be found online at: http://www.scrumcrazy.com/My+Preferred+Agile%2C+Scrum%2C+and+XP+Resources
What would you recommend in terms of the best book(s) to learn about Agile (Scrum) with XP practices? That is, if you had a team of developers who were newbies to Agile, Scrum, and XP, what books/articles would you give them to bring them up to speed on what they should be doing and how they should be doing it?
This question from my friend is a very tricky one, in that it is very broad and generic, and my friend gave me no extra team or organizational context to go on, so about all I can do is give a generic answer, and that is what I’ve done below. If you’re looking to combine Scrum with XP practices, be sure and see Kniberg’s book under “Scrum” below.
Don’t have time to read all of these? Well then, read the first couple from each category, and then continue working your way down each list.
All are in order of my personal preference in each category.
Filed under: Organizational Change, Product Backlog, Product Backlog Grooming, Product Owner Tips, Release Planning, Scrum, Scrum Adoption, Scrum Strategies, ScrumMaster Tips, Sprint Backlog, Sprint Planning, Story Points, The Daily Scrum, The Retrospective, The Scrum Artifacts, The Sprint Review, The Sprint Time-boxes, User Stories | 6 Comments »
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.
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
Are any of you following Denning’s recent articles on Forbes? He is “killing it” for Agile.
I especially like the bottom link…
Anyone have opinions on Steve’s work? I’m not familiar with it other than passing references to his book.
You know the guy. He’s engaging, he’s deep, and when he talks to you — you feel like you’re the only one in the room. You feel like he “gets you.” Some have accused a certain former President of having this ability. You know this guy. He’s the one that every girl wants to “be” with, and the one that every guy wants to hang out and have a few beers with. I know that you know that guy. Everyone has someone in their life like that. You have your very own “Brad Pitt” in your life– I know that you do.
This is how I feel about Lee Henson’s ability to do Scrum training and presentations. I’ve had the great pleasure of attending some of his presentations over the years at the Mile High Agile conference here in Denver. I’m going to keep this short and sweet. Here’s what makes Lee different from most other Certified Scrum Trainers(CST’s) and presenters I’ve seen.
I know what you’re thinking. Brad Pitt? Really?
Everything I said above is my true opinion of Lee, but let’s face it, I’ve already set your expectations high enough(maybe too high, but I doubt it), so let me throw a caveat in. I did not say, but you might have inferred, something about Lee’s looks because I mentioned Brad Pitt and Lee Henson in the same sentence. Lee’s a nice looking guy, but don’t contact him if you want a CST to show you some rock hard abs and model jockey underwear for you. Let’s face it, nobody on the planet looks like my boy Brad Pitt.
So, if you’re looking for a CST that will knock your socks off, this is the guy. You can contact him via his AgileDad web site.
Disclaimer: This might be the biggest suck up in Agile history, so you may be wondering if I have a financial interest in promoting Lee’s services. I have never accepted money for referring good people to other good people, nor do I plan to. Those of you that know me know that I have a very high standard when it comes to people earning my admiration, Agile or otherwise. I am much more interested in people and relationships, and in giving the best advice I possibly can, than some referral fee or commission.