Key takeaways
|
Scrum is a widely used Agile Framework and it has proven very useful for many companies and organizations. However as Fred Brooks famously said there is no “silver bullet” in IT, and despite the good parts of Scrum, on occasion as agile professionals we struggle with some aspects of Scrum for a variety of reasons. Before going any further I want to make it clear that I like Scrum, I’ve used it since 2008, I am even a Certified ScrumMaster. Moreover I find two concepts of Scrum particularly valuable: having protected iterations or Sprints, and also having someone who officially represents the customer that is the Product Owner.
My personal vision of Agile and Lean however goes beyond one single method or framework to benefit from the wisdom of several sources of inspiration such as Kanban, Extreme Programming, Lean Development and Crystal among others as a better way to achieve agility. For that reason I began building a method that was based on several Lean and Agile influences, Kanban being the main unifying force, in 2013 the Kanban-Ace Method was announced in our website.
Until now however no book has been written to document the values, principles and techniques of the Kanban-Ace Method. The reason is that at AgileLion we focused on teaching via recorded online videos, and also through live classes. This turned out to be a blessing, the Kanban-Ace Method reached people across the globe, and received plenty of feedback in these 3 years from people as close as the US and Canada, or as far as Germany, Switzerland and Australia.
One thing that I noticed from our students, and from my professional consulting practice is that Scrum is everywhere, it has become almost synonymous with Agile; and although Scrum is only one of several Agile methods, it is undeniable that it is the most widely adopted. Furthermore as a Certified ScrumMaster I care about Scrum and would like to show people who come to Kanban-Ace exactly how they can improve their agility while still retaining several of the key strengths they like in Scrum.
Kanban-Ace is now a Framework, not a method. The reason is that frameworks are built to adapt to a given domain, and we intend to grow Kanban-Ace into several new areas: full support of Scrum, light-weight agile scaling, and product innovation tools.
This article is a preview of what's coming in the first key area: full support of Scrum. However we don't stop there, we want to improve on Scrum and make the Kanban-Ace Framework a valuable addition to your agile toolset, but before we start we need to give you some background on what is Kanban.
Kanban - A Brief History
To understand where Kanban is today we must know where it came from. Manufacturing Kanban, sometimes called "kanban" with lowercase letters refers directly to Toyota’s manufacturing technique to organize work across factories and divisions, this technique and several others constitute the Toyota Production System or TPS. TPS began in 1945 and had a major milestone in 1978 when Taiichi Ohno published his book in Japanese, it would take 10 more years for an English version to reach the Western world thanks to the efforts of Norman Bodek.
Knowledge Work Kanban or Kanban with an uppercase letter refers to the adaptation, and innovations around applying the ideas of TPS, the Theory of Constraints, Lean Development and other related sources to focus in managing and improving the areas around human creativity, with a particular emphasis in software development, IT, marketing and management. Knowledge Work Kanban is the original Agile and Lean method that is the father of all Kanban flavors we have today. From now on all our references to Kanban refer to this particular type of Kanban.
Kanban's Origin
Kanban was introduced first by Corey Ladas in his 2009 book on Kanban entitled “Scrumban - Essays on Kanban Systems for Lean Software Development” and later the method received another key contribution from David Anderson’s original 2010 book “Kanban: Successful Evolutionary Change for Your Technology Business” on this book David proposed his initial ideas about Kanban as a Lean and Agile approach.
This early history of Kanban is closely associated with the Agile movement, and both Corey and David have strong software development and IT backgrounds. Kanban remained an Agile and Lean approach in these early days, drawing also from previous Lean related work from Donald Reinertsen, Mary and Tom Poppendieck.
The Kanban Method
Around 2013 however David Anderson decided to take his version of Kanban, which he calls The Kanban Method in a different direction, away from all the other Agile methods, to focus instead on “evolutionary improvement” and ways to improve management. This journey led him to say multiple times that The Kanban Method was not Agile, although it may lead to agility. During this time many early members of Kanban decided to follow a different path, one that remained Agile, and stayed closer to IT and Software Development: Classic Kanban.
Classic Kanban
Classic Kanban represents the original Lean and Agile approach to Kanban. Classic Kanban embraces the Agile manifesto fully and maintains strong ties to software development, IT, DevOps, and product development.
Classic Kanban is very much alive and growing today, it’s main representatives are Corey Ladas, Al Shalloway, Henrik Kniberg, and myself. Corey represents Classic Kanban through Scrumban and Lean Kanban. Al Shalloway through his Lean Kanban for Teams, and most recently Leanban. Henrik Kniberg through his books especially Lean from the Trenches, and his writings derived from his practice at Spotify and Lego. To this prestigious list I would humbly add our main contribution the Kanban-Ace Method, and the upcoming Kanban-Ace Framework which this article discusses. It is also good to mention two other minimalistic Kanban methods first Personal Kanban by Jim Benson & Tonianne DeMaria; and our own Open Kanban which is the core of Kanban-Ace.
While we are on the subject of Classic Kanban, I would like to dispel a myth. Scrumban is not a hybrid method of Kanban and Scrum, but rather a way to embrace Kanban when we start the journey from Scrum, here is now Corey explains it:
Scrum can also be useful as a starting point for an experienced Agile team to evolve into a Leaner process. I have always assumed that I am writing for that audience, and such an evolution is the “Scrumban” process that gives this book its title.’ Corey Ladas, Scrumban: Essays on Kanban Systems for Lean Software Development
Scrum's Strengths and Weaknesses
Without a doubt the abundance of books, ScrumMasters, training and success stories are the biggest strength of Scrum. The framework has become a base level for Agile, and many in the IT, software development, marketing and product development are familiar with it.
In my opinion besides success and recognition, the two other key strengths are:
- The concept of a protected iteration, or the Sprint.
- The creation of two key roles to guide the development of products: the Product Owner and the ScrumMaster.
However Scrum is not without weaknesses and areas where it could improve. Recently through AgileLion Institute we gathered some feedback on this topic via a survey. The original article has our detailed report on our findings, but I would like to summarize our findings in the chart below:
As the chart shows there are 4 weaknesses that users of Scrum identify: 
- Planning & Estimation 40%
- Difficulty to Scale & Rigid Roles 28%
- Abundance of Meetings 13%
- Lack of IT Technical Practices 11%
To address every single item on that list fully would require several books, I have chosen instead to show how the Kanban-Ace Framework can improve all those areas, and make the life of ScrumMasters, Product Owners, Developers and Managers more enjoyable.
The Kanban-Ace Framework - A Brief Introduction for Scrum Practitioners
Rather than explain every value, practice and technique of the Kanban-Ace Framework I have chosen instead to give you a brief introduction to the main benefits we bring to Scrum.
If you are interested in a comprehensive discussion of Kanban-Ace including the theory, values, principles and techniques I strongly recommend you visit AgileLion Institute, there we provide online and live training and certification.
The Kanban-Ace Framework provides a collection of tools and techniques to address the weak areas of Scrum within Kanban, but maintaining the key elements of Scrum you are used to utilizing every day. This collection of tools and techniques we provide is called Akashi. But before we dig into the technique that allows us to merge the best of Scrum with Kanban-Ace we must understand how Kanban-Ace works through it's main strength: visualizing work.
Understanding Kanban-Ace's Key Strength for Scrum: Visualizing the Forest and the Trees
Scrum uses task boards to show progress inside a particular iteration or Sprint. Sprints can be one to 4 weeks in length, and each task board usually has 3 columns: To Do / Doing / Done. For a visual of how they look, I recommend this fine article by Agile Coach John Yorke.
Unlike Scrum, Kanban-Ace does not visualize a single Sprint, but the whole overall effort to build a product from idea to cash. This is huge, it means that Kanban-Ace boards can see the whole forest of the Software Development Life Cycle, the Product Development Life Cycle, or frankly any business system that crosses different stages to deliver value such as hiring personnel, achieving sales, and designing new products. On this article however we will concentrate on the software side. In essence what I just explained means Kanban-Ace can see the forest clearly, and any time get a picture of what is happening in our software team.
But it does not end there, in addition to the eagle view of the effort you also get a zoomed view into the trees. Kanban-Ace boards have a series of columns that identify the stages that 
identify critical steps in your software development process, being able to clearly show bottlenecks, and where each individual in your team is at any time. To better understand this key advantage: seeing the trees in detail, I want to first explain how a Kanban-Ace board works, so take a look at the board shown on Diagram 1.
As you can see from that graphic Kanban-Ace Boards flow from left to right. It is a continuous flow, that approximates real time, so at any moment you can see where your team is.
On this minimal Kanban-Ace board you can see that on the left-most column a series of pieces of work of different sizes in the PENDING column, one many call Backlog. Next to it you can see a READY Q column, which means the stories, epics, features, Minimum Viable Releases, MVPs or tasks now are ready to be worked on. The next column is where the main work happens, here I call it the RIVER OF WORK. This time it is just a wide column, but in practice it usually gets divided into the stages of work you want to track, and make visible. Finally we have the TV column, and no it's not time to watch TV! It actually stands for Trust or Verify, since work usually needs either of those before announcing it to the world. And of course once it is all done we have the TRULY DONE column; which many friends affectionally call sometimes DONE DONE ;-)
Now below, notice Diagram 2, there you have a realistic Software Development Kanban-Ace board, let us examine it in detail. First you will notice that the team has mapped their software development life cycle into 8 columns that flow from left to right: Backlog, Prioritized Backlog, Ongoing Development, Done Development, QA Ongoing, QA Done, Deployment, and Done Live.
Now let us examine what is exactly going on in this Kanban-Ace board. This time let's read it from right to left, since value delivered is always at the rightmost end of the board. First we can see that the team has delivered story A to production; story W is just about done, and now it is getting ready to be deployed by a Sys Admin. In the testing part of the team there are two stories, one just passed QA (story B) and another is occupying the time of two QA analysts (T1 and T2) that is story E, we can safely deduce that it is a more complex story. Now on the development side we can see that the team is now very busy with 4 stories, one was just delivered to the Done Development column (Story Y), so whenever the QA team has capacity they will pull story Y to work on next. In the meantime the development team has a blocking issue that has stopped progress on story C. This is where the ScrumMaster, Kanban-Ace Coach or Agile Project Manager would step in to do whatever needs to be done to unblock that story, and make it possible for the team to move ahead and develop it. For now however no time has been lost, two developers are busy working on Story D, and a UX designer is working on some screens for story H. On the Prioritized Backlog side of the team, a Product Manager and a Product Owner are working with a key developer to put some needed details for Story Q, so that it can be ready to be developed next. On a similar type of effort is Story G, where we notice developer 3 is adding some details to the story before making it available for the development team to pull it into their development column. Finally the Backlog shows 6 stories waiting, once they go through the whole process the whole effort will be most likely done, and the product will be fully built and released.
By now you can probably understand what I meant before when I said that a Kanban-Ace board allows you to see the forest and the trees of your software development life cycle. In a few minutes or seconds you can literally see where the whole product is, or at what stage is the product any given day.
In addition do remember that those columns are not set in stone, the team may decide together how to introduce changes to the board in order to improve the process, or visibility of the system represented by it. For example they may introduce additional columns for Code Review, Code Merge, UAT, User Demos, etc.
Now one more thing, Kanban-Ace boards can also have Work in Progress limits, or WIP limits represented on them. They are represented on the board above by the numbers you see on top of some of the columns. WIP limits are there to focus the team on a workable set of stories, so that their efforts are not wasted on doing too many things at the same time. Solid theory behind queues and even psychology has shown that focusing on less things actually allows you, and your team to deliver more in less time. Less is more! However the Kanban-Ace Framework considers WIP limits optional, but highly recommended. We emphasize first the principle of Reducing BASE, which means reduce the Batch Size of your Efforts. A WIP limit of 1 is useless for a development team, if that "one" represents a mega feature, Reduce BASE says basically this: make your efforts as granular, and small as possible, and once you have them small, work on as few at a time as possible, so that you focus your efforts. Once you've Reduced BASE, limiting WIP is easy!
Introducing the Kanban-Ace Akashi Bridge for Scrum
The ideas inside of Akashi have been part of Kanban-Ace since the very beginning, but now the Kanban-Ace Framework adds a systematic approach to working with Scrum so that they fit well, and work as a unified whole. 
Akashi is named in honor of the Akashi bridge in Japan, the longest suspension bridge in the world connecting the cities of Kobe and Iwaya. I chose this name given that both Kanban-Ace and Scrum have a common Lean heritage from Japan. Notice that this long bridge has two main towers that unify the whole structure, the same is true for the Kanban-Ace Akashi Bridge and those towers represent Scrum and Kanban-Ace!
Below on Diagram 4, you can see the full Kanban-Ace Akashi Bridge, let me go step by step into explaining how it works. Let's start from the top, there are 4 main pillars or columns that divide the Bridge into sections. First on the left-most part of the Bridge you can see Pending pillar which holds the Product Backlog. Second is the Scrum Tower. Third is the Kanban-Ace Tower, and at last the Truly Done pillar.
The two main Towers of the Akashi bridge allow Scrum practitioners to embrace the power of Kanban-Ace to see in a glimpse the forest and the trees of work, and be able to easily embrace continuous flow and every single strength of Kanban-Ace while retaining the key events that make Scrum valuable to them.
The Scrum Tower is a mini Kanban-Ace board that shows all the activities related to Scrum Events. On the left most section of the Scrum Tower you can see the Event Backlog, which contains the estimate of Scrum ceremonies the team believes is needed to deliver a full release, or a product. The next section entitled "Event Day" is used when the ceremony is scheduled to start. For example in the board below you can notice that the 2nd Sprint Planning (2PL) event is scheduled for today, as is the Daily Standup (ST.) The Scrum Tower also shows us that since the Akashi Bridge was in use the 1st Sprint was done fully, with Sprint Planning, Review and Retrospectives already done in the past (1PL, 1RV and 1RT respectively.)
At the same time we have all the goodness of near realtime view of the whole team effort on the Kanban-Ace Tower of the Bridge, so you can see the forest and the trees. The Kanban-Ace Tower is itself a full Kanban-Ace board! Let’s examine for a moment where the team is on this Akashi Bridge. Let's start from the right most column to see what the team has done so far: Stories 1 to 4 have been fully done, Story 5 has just passed QA, Stories 9 and 8 are in QA now. Stories 10, 11 and 6 were recently done by the development team, they are now working on DEV on Stories 7, 12 and 13, finally ready to start from the backlog are Stories 14 and 15 the development team will pull them once they are done with the current effort.
But wait that's not all! Since we have the Scrum Tower, we also know that Sprint 1 delivered 4 stories, that Sprint 2 has the challenge of taking care of the whole board; and probably won't make it given that before they only managed to finish fully 4. This is very valuable information for the ScrumMaster, ProductOwner, Kanban-Ace Coach and the team to Inspect and Adapt on the coming Sprint Planning meeting for Sprint 2.
On the next topic of this article we will move away from the Akashi Bridge, to discuss other advantages that Kanban-Ace offers to all Agile practitioners.
Additional Kanban-Ace Advantages for Scrum Teams
As I have explained along this article, Scrum teams that decide to adopt the Kanban-Ace Framework maintain their key roles and events, while gaining the whole gamut of tools that Kanban-Ace brings to the table such as: ability to view the whole and yet be able to zoom-in the details of their work, the ability to plan and execute on a continuous flow horizon, the key Scrum events they are used to enjoy, and many more advantages that are already part of our Kanban-Ace classes today. I would like to bring to your attention two of those additional advantages to the Akashi Bridge which we introduced previously.
A. Kanban-Ace Advantage: Lean Thinking
Kanban-Ace as a Lean-Agile method fully embraces Lean Thinking and one of its core principles: reduce waste. What is the impact of this principle for a Kanban-Ace Scrum team? The main impact is to question the value of events or ceremonies that are perceived as a waste by the team. Let me explain with an example: a team that develops an iPhone app needs several days to do any significant change to their app, therefore they decide that the need to have a daily standup is a waste, instead they choose to have two standup meetings a week, instead of five. This will not only give them additional time, but it will also improve team moral since no one is particularly fond of wasting time in a meeting, but people will attend a meeting that is truly useful like a retrospective after a release. Therefore Kanban-Ace urges you to reduce waste, this time reducing meetings so they respond to the communication and economic needs of your team. One warning though, reducing waste is an important principle, but never obsess on it. Unlike machines people need slack, and rest to perform at their best.
Lean Thinking also invites you to think about the whole system, and how your place in it affects the creation of value for the whole value stream. One consequence of this is to choose when having a Sprint (meaning a protected iteration) makes sense for the overall business, or department. Usually when dealing with Product Development Sprints make perfect sense, but when you deal with Operations, IT Infrastructure or any other technology area that requires several releases a day, removing Sprints and opting for a standard Kanban-Ace board that embraces Continuous Releases is better! So Inspect and Adapt, embrace Sprint-less continuous flow if it matches your needs!
B. Kanban-Ace Advantage: Our Knowledge-Base
Kanban-Ace offers many key principles, values and techniques to the Scrum practitioner, all of them are available now in our knowledge-base. I would like to highlight just a few:
- Minimal Actionable Planning that creates useful, agile plans that can guide the delivery of releases, or the creation of Minimal Viable Products (MVPs.)
- On Demand Releases. Kanban-Ace boards embrace on-demand releases, anytime you are ready to deploy them; whether it’s several times a week, or many times a day. Sprints are optional, to be used only when needed. Kanban-Ace welcomes Continuous Integration, Continuous Releases and works perfectly with IT Infrastructure, Operations and DevOps.
- Kanban-Ace Gears. A tool that teaches how to examine whole value chains and flows to bring radical improvement to it, so that the process, the tools, and the team can reach new levels of performance. This is not Kaizen, or small continuous improvement, but Kaikaku or revolutionary change.
- Role Pragmatism. Kanban-Ace today recognizes that if an organization has chosen to have a role, there must be a need for it. We don't fight those roles, or ask the company to rigidly adopt new ones, we start with what we have now, and improve from there. The Akashi Bridge shows that same kind of philosophy applied to welcome Scrum roles.
- Values. It took Scrum over a decade to finally embrace values explicitly as part of the framework, this is still great news, however we are happy to report that Kanban-Ace has embraced values to protect the team and deliver software since day one! Values such as: courage, focus, collaboration and respect for people.
As a final point I wanted to mention that I am busy writing the upcoming Kanban-Ace Framework book which will be released in 2017, where I plan to introduce many useful innovations such as Ace Story Points, Light-Weight Scaling, and SAFe support. If you would like to keep in touch and be the first to know when the book is out, just contact me.
To close this article I want to quote a line from someone I admire greatly, Sir Isaac Newton who said: "We build too many walls and not enough bridges.”
About the Author
Joseph Hurtado is the author of the Kanban-Ace Framework, and Open Kanban. He is also the founder of AgileLion Institute. Professionally he is an Agile Coach certified as a SAFe SPC 4, a Kanban-Ace Trainer and a Scrum CSM. He is passionate about the human and technical sides of software and product development, having led teams to deliver technology solutions across a variety of industries. His Agile approach is to make work an enjoyable effort, and then deliver fantastic software while keeping the team's morale high, and their health intact. Outside of tech his interests are photography, art and philosophy. You can find him on LinkedIn, Twitter, Web.