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. Contact us for more info
Filed under: Agile, Bad Smells, Kanban, Organizational Change, Scrum, Scrum Adoption, ScrumMaster Tips, The Retrospective, The Sprint Review |
The Scrum Crazy Blog 
The post starts out OK. The heading of point 1 is correct enough, but the last paragraph seems like a fairly unfair personal attack on David. I wonder if you could back it up a bit. I don’t think it is wrong to link Kanban and agile software development. Kanban grew up in software development teams, and many of the changes that a team using Kanban will implement will come from agile software development. Kanban probably is the main tool used for its purpose in the agile community. The culture that Kanban encourages is the same sort of culture that agile development and Scrum work best with.
Point 2 is plain false. You certainly make no attempt to back up your claims. Kanban doesn’t actually define a process. Scrum does. Scrum says what roles you need, what events need to occur and when. You have to strictly follow the steps of Planning, Daily Standups, Review, Retrospective etc. Not that there is anything wrong with that, there is always some sort of process present, and a team could do a lot worse than a minimal framework like Scrum. A Scrum team using Kanban might have columns on the board like Grooming, Planning, Task Breakdown, Review, Retrospective, Release for example, but these defined steps don’t come from Kanban, they come from the actual Scrum based process being used. The bits that makes Scrum ideal for complex work, that developers define their own tasks and have the ability to continually improve their process are still present in Kanban, arguably to an even greater extent, since Kanban places even more focus on improvement than Scrum, and allows team members to change potentially anything, even things upstream and downstream of the parts of the process that Scrum covers.
Also feedback is an explicit practice in Kanban.
Your point 3 doesn’t make any sense either. I had to check to see if you were a PST, as this is something I have heard many PSTs say. You don’t actually make any attempt to argue the truth of it or back it up, so it is hard for me to help you identify exactly where you went wrong on this point. Is it because Kanban involves visualizing an existing process as a series of “repeatable” steps? Like I said above, if a team using both Scrum and Kanban has columns like “Write PBI”, “Backlog”, “Plan”, “Task Breakdown”, etc, then those “repeatable steps” don’t come from Kanban, they come from the Scrum based process that Kanban is trying to improve.
I don’t know if “layering Kanban on top of crap will still yield crap.” is true either. The whole idea is that you have some process or something that needs improvement. Whether good or crap, Kanban applied correctly should still be able to help support improvement. Probably with a crap process the opportunities for improvement are more obvious.
Your bottom line is correct when read literally, but I can’t help but detect a sarcastic tone when you say “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?”
Your points 2 and 3 especially are doing just that. Criticizing a hammer for not doing a good job of being able to insert a screw into a wall. So I am not sure, do you in fact think Kanban is a software development methodology or something?
Kurt,
Thanks for the detailed comments. I have some too. 🙂
Re: Point 1 last paragraph
I’m unsure what you mean by personal attack. I said people are not listening close enough to what David, The Kanban Method creator, is saying, and that is unfortunate. I don’t see anything personal in that paragraph. It’s not like I called him fat or ugly or anything(of which he is neither, btw) — there were no *personal* attacks. Even if I had said no one *should* listen to David about Kanban, that would not be a personal attack — that is a professional criticism. Having said that, I think people should listen much closer to what David says about Kanban, because most of them aren’t understanding what he is trying to convey, and like I said — that is unfortunate.
Re: Point 2
I disagree that point 2 is false. I do agree with you that I didn’t back up that statement, but the article was already too long. However, now that we’re down in the comments, I’ll elaborate.
Kanban is modeled more after the assembly line and manufacturing.
“…Kan-ban is a Japanese word that literally means ‘signal card’ in English. In a manufacturing environment, this card is used as a signal to tell an upstream step in a process to produce more. The workers at each step in the process are not allowed to do work unless they are signaled with a kanban from a downstream step…” — David Andersen in his Kanban book, page 5.
Scrum is modeled more after creative product design.
“…We call the approach the SCRUM methodology (see Takeuchi and Nonaka, 1986)…” — Jeff Sutherland
Click to access schwapub.pdf
Takeuchi and Nonaka’s 1986 paper:
http://hbr.org/1986/01/the-new-new-product-development-game/ar/1
Point 3 is about how Kanban really only focuses on repeatable work steps, and not the multi-dimensional complexity that comes with software development, where the work steps are not always the same. As I stated in point 2, there are no built in feedback loops. There is only a general statement about “improving collaboratively” which anyone can satisfy in a normal work conversation. Every day at work we talk about improving collaboratively, so that principle doesn’t really add much to any process or framework that already exists. You are right though, this is a different way of saying that Kanban is not a software development process. It was not designed to handle the complexity or ROI/TCO of a software product, so we shouldn’t expect it do so.
> do you in fact think Kanban is a software development methodology or something?
No, I do not, but I think many in our industry do, and that was a big reason why I wrote this post.
Thanks for reading and thanks for taking the time to reply.
Charles
In reality, both Kanban and Scrum have the same origin, the Toyota Production System. Kanban is a direct application of the TPS to software development (or any other process for that matter), while Scrum is an adaptation of TPS specifically to software development. However, if you go to the root of it, they are both the same, a form of visual management of value flow.
No, Kanban and Scrum do NOT have the same origin. That is false. Kanban is based on Lean manufacturing techniques, while Scrum is modeled more after Lean Product Development techniques (and closely related, the “New New Product Development” paper by Takeuchi and Nonaka). One is modeled after manufacturing, while the other is modeled after product development. One seeks to perfect making the same widget over and over again, while the other seeks to develop new products and connect with an audience. This is why Kanban doesn’t work well for software dev teams, in my view.
I thought kanban was created in the 40es in Japan?
I believe it was, but what we are talking about here is Kanban with a capital K, an idea put forth by David J Andersen in a book.
I think post is really pertinent to the times. I’m seeing a lot of confusion generated, in minds of clients and indeed the community. Based on the context, many people in support and continuous delivery assume that since Kanban seems to fit better, it is somehow superior to Scrum.
However it is not clear why you say Kanban is to be used for change management. Actually “Change management” is done via a project managment and here also Scrum is an excellent framework.
Srinivas — good points, especially the one about Scrum being an excellent framework for change management. I see Scrum as a change management framework PLUS a whole bunch of other good stuff that supports software product excellence.
This has a lot of Schwaber in it, and that is ok. However, many of us don’t look at it as Scrum vs. Kanban. Kanban originated in the TPS and for sure that is a manufacturing context. But we know and appreciate that elements of kanban flow are found in Scrum. Indeed, my friend and fellow CST has written about it and applied it extensively. He first wrote about it in the Crisp Blog in 2009: http://blog.crisp.se/2009/04/03/henrikkniberg/1238795520000. Anderson wrote about the comparison in his blog back in 2009: http://www.agilemanagement.net/index.php/blog/Comparing_Kanban_to_Scrum/. Schwaber has blogged his opinon about it too: http://kenschwaber.wordpress.com/?s=kanban.
Those of us who have sufficient experience try earnestly not to get sucked into these arguments anymore (Including Scrum versus Waterfall, directed teams vesus self-directing teams, etc.) It’s akin to teaching a pig to sing. Intelligent and critically thinking people will discern the appropriate from inappropriate and the meritorious from non-meritorious in these matters. We’ll apply those concepts that work well and understand how slippery slopes work.
Tom,
I’m not really sure as to the points of your comment. So let me try to summarize them:
1. You think I have similar views to Ken Schwaber. That might be true, but I also have views similar to David Anderson’s, as I have mentioned. The views of those two are not all that different, in terms of when it is most appropriate to apply Scrum or Kanban. This was one major theme of the above post.
2. You think discussing the different contexts that Kanban and Scrum might be more appropriately applied is a waste of time(teaching a pig to sing). I obviously disagree. I think much more time and money is wasted by not thinking(critical thinking as you mention, respectfully debating, ritual dissent, etc) *enough* when they are more appropriate to apply.
3. You think smart people will eventually figure out when to best apply Scrum and Kanban. I think you are right about #3, and my hope is to speed up that process.
If I’m way off on my summary of your comment, please let me know. With all due respect (and I have a ton of respect for all CST’s/PST’s), I had a hard time understanding what your point was — beyond what I’ve tried to discern above.
Charles
I think I should also mention that it is my opinion that Kanban currently suffers greatly from “semantic diffusion.”
“Semantic diffusion” explained here by Martin Fowler:
http://martinfowler.com/bliki/SemanticDiffusion.html
Scrum and other methods in our industry have suffered from it too, of course. It has always been my view that Ken Schwaber’s attempts at defining Scrum via the Scrum Guide are primarily to help prevent this semantic diffusion. I should also mention that, so far, I’m 100% behind the Scrum Alliance’s “Agile Atlas” efforts for the same reason. Another reason I support the Agile Atlas is because it has reflected the recent changes to the Scrum Guide(“forecast”, “ordering the PBL”, “Development Team vs. The Team”, etc), and that too, will help with the “semantic diffusion” of Scrum.
Codifying the definition of these methods, especially coming from the originators and early pioneers of the methods, will help quell some of these debates. (Mike Cohn has done well in this area) In the meantime, the debates bring a lot of value to the newer methods in the ‘hollywood’ way: “All PR is good PR.”
I think our industry should learn how to incorporate “ritual dissent,” expert facilitation, and other peaceful debate mechanisms to help move the industry forward. Lyssa Adkins and Michael Spayd are doing some good work in this area — “leading conflict.” See: http://www.infoq.com/interviews/adkins-spayd-coaching-conflict
Here’s another interesting view on a Scrum and Kanban:
http://scrum.jeffsutherland.com/2011/11/alternative-to-kanban-one-piece.html
I wonder whence the semantic diffusion comes. Follow this to the definitions from the sources: http://scrum.jeffsutherland.com/2011/11/alternative-to-kanban-one-piece.html. Look in particular at the comments. Many of them claim that the emperors’ new Kanban isn’t what Toyota calls Kanban though I am pretty sure I’ve heard Anderson make this claim in the past. I guess it really doesn’t matter with so many people blindly following something whose formal basis seems to lie in queuing theory rather than in project management — if it’s the latter, they got it wrong.
[…] Kanban vs. Scrum: Kanban is NOT for Software Development, but Scrum is! […]
[…] That’s when I saw this post https://scrumcrazy.wordpress.com/2013/02/04/kanban-vs-scrum-kanban-is-not-for-software-development-bu… […]
All this discussion makes me feel I’m back to 2008. Charles, imagine you’ve got a team that every Monday morning plans the work for the week. Imagine that everyday at 2pm you run the Team’s daily meeting. Every Friday you do a review and run a retrospective. The focus is “building software”. This happens over and over again every week. Can I claim you’re doing repeatable work?
The same goes with Kanban. Both Kanban and Scrum do not care about what happens inside your batch, the creative work. You can’t claim “reapeatable work” based on batch size.
> Can I claim you’re doing repeatable work?
No, you cannot. You can, however, claim that you’re doing repeatable process.
The work itself is not repeatable in the same manner, and as such, inputs and outputs are rarely repeatable. This is the nature of what we mean(in the Cynefin sense) when we say “Software development is complex work, and complex work is not repeatable.”
So, you rely on Cynefin to prove that Kanban is not for complex work? Are you sure? Do you know the opinion of Dave Snowden about Scrum?
Again, Kanban and Scrum don’t care about what happens inside your batch, the creative work. If you understand Scrum and Kanban approach to batch size, saying that Kanban is for repeatable work makes no sense.
> Do you know the opinion of Dave Snowden about Scrum?
I’ve had the good fortune of working personally with Dave Snowden in a 2 day Cynefin work shop, but we never discussed Scrum…. not once. Why don’t you tell me what his opinion is?
1. Scrum is not a “out-of-the-box” fit to Complexity:
http://cognitive-edge.com/blog/entry/5758/its-all-about-the-granularity/
2. “His approach is deliberately controversial and he makes no apology for attacking the “sacred cows” of the Agile movement. He was particularly scathing about the Scrum devotion to a single process and the role of the ScrumMaster.”
http://www.infoq.com/news/2012/09/snowden-agile-practice-theory
I would like to point out that I wasn’t relying on Cynefin, simply referencing “complex work” in the context of Cynefix and Complexity Science. Having said that…and since you brought up David’s comments…
> 1. Scrum is not a “out-of-the-box” fit to Complexity:
I don’t think that’s a fair summary of that article. For instance, Dave also says: “I think the sprint concept needs little change and it handles complexity. ”
> “He was particularly scathing about the Scrum devotion to a single process and the role of the ScrumMaster.”
Given the third hand account, I don’t know what Dave was trying to say here. If he’s saying that the Scrum community thinks they are the *only* solution to complexity, then he’s wrong. We just think we’re the only solution out there now. We think the Agile Manifesto itself also supports some solutions to complexity, it’s just that no other Agile approach is nearly as consistent with the Agile Manifesto as Scrum. I completely leave open the possibility that something will come out to challenge Scrum in this space, but so far, no approach has even come close.
I stand by my original statement, that process is repeatable, and complex work is not. I also stand by my view that Scrum has several built in risk mitigators to complexity, and Kanban does not.
In my opinion, this is why David Anderson said:
“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”
Nice article overall, but reality of many creative software – from free web browsers to large enterprise apps costing millions – is to deliver software in “release trains”, the logistics of it feel very similar to the assembly line. Still that is layered on top of individual features that may be developed in scrum, so while the overall premise is valid, just consider this release train trend.
When I say assembly line, I’m not talking about a release train as that is not software development — that is software assembly/deployment.
I’m not sure I’m a big fan of the release train concept either, as it implies a strong bias towards highly dependent component teams, which is generally not a great idea.
[…] Kanban’s Agile & Lean heritage, David Anderson and LKU have distanced themselves from Agile, Software Development and […]
[…] discipline of pretty much every industry. In the end, who cares. Some Scrum evangelists even argue: Kanban is NOT for Software Development, but Scrum is!. Again, who cares. If it works, it works. And it does work, […]
Is maintenance, enhancements and fixing bugs considered software development? If so, then Kanban can be (and is being) used for software development. Consider a mature set of systems with a list of legal or compliance changes, enhancement requests, and break/fix items. We prioritize these items and funnel them through our “assembly line” of Requirements, Development & Testing using Kanban. We are not in a sprint, we just update, enhance or fix whatever needs done according to the priority. And, yes we can still be creative when developing our software.
Yes, software dev includes maintenance, enhancements, and bug fixes, and I’m still not convinced Kanban is a good choice there either. For handling the kinds of things you describe, see my other post here: http://ScrumCrazy.com/bugs
[…] (and should not be). One example is Charles Bradley, whose blog post on the subject can be found here. According to Charles, “scrum is about software development [and] Kanban is about change […]
[…] https://scrumcrazy.wordpress.com/2013/02/04/kanban-vs-scrum-kanban-is-not-for-software-development-bu… […]
I worked at a company using Kanban to manage a 12- to 16-month release cycle. It was a disaster and releases frequently had to be postponed.There was no real feedback cycle and it was a “push” system, rather than a “pull” system as proposed by Anderson. People came to work in the morning and just took Kanban cards from the board and started doing that work. There was no real coordination and in my opinion it was not a self-organizing team but self-organizing individuals at work. We used Scrum before this, but people didn’t want to plan sprints anymore and Kanban was introduced.
Kanban seems to work best in a support environments … fixing critical bugs and prioritizing them for the team. David Anderson once gave a workshop here in Cape Town (South Africa) and he used a support team as an example for using Kanban.
Kanban has its place, but I wouldn’t use it everywhere! Yip, it is a tool. Scrum and Kanban are two different tools. You have to use them in the right context. The same is true for computer languages.
[…] you might notice, however, is that Kanban for Software Development is a bit of a misnomer. By their own admission, the founders of the movement point out that Kanban works alongside […]
[…] So is Kanban agile? It is not strictly an agile process, but it is more a way of continuously improving your development process. In fact some authors would argue that Kanban should not be used for software development.. […]
David Anderson’s comments could equally apply to SCRUM. it is a few techniques, not a complete methodology.
Even in a manufacturing context, or air-traffic control, or any system there is a need to improve processes by responding to feedback.
Luc, this post is about software development, not other domains.
Charles
Not directly reference perhaps in this blog post, but I thought you have considered that Scrum is primarily oriented to software development?
This seems too bad not to utilize where it can provide value in other work that has multi-dimensional complexity, e.g., network infrastructure deployment and tailoring. Your thoughts appreciated. 🙂
http://www.scruminc.com/how-to-use-scrum-in-hardware-2/
https://www.scrumalliance.org/community/articles/2013/december/agility-looking-beyond-software-development
Doug, this post refers to Software, so my comments here are limited to that domain only.
Kanban actually works quite well for Software Development. Common (good) sense will evolve some practises outside the core but it is a great starting place and works well on it’s own. 80% of Scrum Transformations fail. (stats from various sources agree) Why bang your head against the wall? Scrum is ok for new product development but look carefully and you will see that Scrum is rarely used on its own. Stories are from XP and are the most common way to manage a backlog. Kanban can work ‘out of the box’ so the teams can get started right away with minimal training. I think that Scrum is currently more visible is it makes more money for consultants through training and coaching as Scrum is hard to adjust to…
Coaching is valuable it even if you are doing waterfall. Coaching can make the Kanban team approach high performance sooner. Kanban can be taught in 20 minutes. High-performance takes time.
Kanban works well almost anywhere and can be used overlayed on your waterfall or your scrum to improve it.
Rethink your ideas on Kanban and try it!
Michael, I’ve re-thought and re-coached, and re-exercised, and I still come to the same conclusion. Kanban as a software dev approach for software teams does not work well because it is missing things that are key to software development success. While some people may be able to fill in those gaps, in my experience, they don’t generally do so or do so well at all.
Both Kanban and Scrum are completely missing anything that has anything to do with software development. I agree that Kanban doesn’t work well as a “software dev approach for dev teams”, no one that understands Kanban would claim that it is. Scrum is a minimal framework that allows product development teams to build a process, and is often a good choice for software development teams. Kanban is a minimal framework for helping anyone (not just teams) to manage and improve knowledge work systems, that may also include product development. It also has a lot of other advantages related to the management of knowledge work systems. They actually work well together. Scrum at the software development team, task and iteration level, and Kanban for covering the whole value stream, and the value level. Kanban sort of sits on top of Scrum (e.g. covering multiple teams or projects), and works upstream and downstream of the software development teams. Scrum is not that useful to the business, because the business cares about the whole value stream, not just the typing in of code. Kanban takes care of this need for the business to understand what is happening at a higher and wider level.
[…] Business Values as a sign of maturity of Scrum, the lack of such a concept in Kanban makes them deem this other modern framework unsuitable for software […]
Hi, I would love to share your bug chart in our enterprise community – is this possible wihtout violating against the copyright law? Looking forwart to hearing from you. Best regards jenny
feel free to share it, it’s creative commons so you are free to share it wherever as long as you don’t claim it as yours! 🙂