The Scrumban [R]Evolution

What is Scrumban? Evolved Scrum? Applied Kanban? A combination of both? I needed to find out, therefore I read the book ”The Scrumban [R]Evolution” by Ajay Reddy. The subtitle is ”Getting the Most Out of Agile, Scrum, and Lean Kanban”. The book has 384 pages and was released in 2105.



The book consist of 10 chapters divided into four parts. The chapters are:

  1. Manifestations: Scrumban Demystified
  2. The Matrix and the Mess: Where It All Begins
  3. The Mission: Clarifying the Relationship between Purpose, Values, and Performance
  4. Motivations: Why Scrumban Works
  5. Mobilize: Rolling Out Scrumban
  6. Method: Working under the Hood
  7. Measurements: Gaining Insights and Tracking Progress
  8. Management: Management Is Doing Things Right – Leadership Is Doing the Right Things
  9. Maturing: Like a Fine Vine, Scrumban Can Get Better with Age
  10. Modeling: To Baldly Go Where Few Have Gone Before

I will try to start with answering the first question, ”What is Scrumban?”. Corey Ladas introduced Scrumban in his book from 2008. He defined Scrumban as a transition method for moving software development teams from Scrum to a more evolved development framework. Some of Corey’s work is covered in the beginning of chapter 4 in this book, ”The Scrumban [R]Evolution”.

In the first chapter Ajay Reddy introduces Shu-Ha-Ri to understand Scrumban. It stands for:

  • Shu (Beginner) – The first stage of learning. The student seek to reproduce result by following a set of instructions.
  • Ha (Intermediate) – The student understand and live by basic practices, values and principles.  
  • Ri (Advanced) – The student has become a master.

I’ve also seen it explained something like this: Shu (”learn the rules”), Ha (”live by the rules”), Ri (”break the rules”).

Scrum has the following values: Focus, Courage, Openness, Commitment & Respect. Kanban the following: Understanding, Agreement, Respect, Leadership, Flow, Transparency, Balance, Collaboration & Customer Focus. Scrumban, as an independent framework, brings three additional values:

  • Empiricism – Empirical approaches are always favored over theories.
  • Humility – We must always be ready to challenge our understanding.
  • Constructive interaction – Constructive debate that improves understanding over blind acceptance.

When Scrumban core practices are mastered, other frameworks and models can be ”woven in” like:

  • A3 thinking
  • The Cynefin Framework
  • Real Options

Basically the whole book goes on like this. By referring and briefly describing everything that has been ”a hot topic” in the agile world during the later years. Delicate pieces, but small, like a smorgasbord. You want some more examples? Here are three of them.

Jason Yip has summarized patterns for a good stand-up (remembered as GIFTS):

  • Good start
  • Improvement
  • Focus
  • Team
  • Status

Bill Wake’s INVEST for work breakdown:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

Characteristics central to the role of a servant leader:

  1. Listening
  2. Empathy
  3. Self-awareness
  4. Responsibility
  5. Persuasion
  6. Conceptualization
  7. Foresight
  8. Coaching/mentoring
  9. Systems thinking
  10. Empirical decision making

Any many, many more. So how do you get started with Scrumban? That is covered in chapter 5 but an appendix holds a quick reference guide:

  • Step 1: Visualize your system
  • Step 2: Start Measuring Performance
  • Step 3: Stabilize Your System and Improve Focus with WIP Limits
  • Step 4: Improve Your Understanding and Management of Risk
  • Step 5: Continuously Improve


This book has good structure, well written texts and a lot of illustrating figures. However, I think the overall purpose, to explain Scrumban, gets lost when describing all the surrounding agile practices. Keeping it simple is a virtue.

All the best,
 Tomas from TheAgileist

Visualization Examples

I was introduced to Jimmy Janlén and his work at “Agila Sverige 2015” (a yearly Agile conference in Stockholm, Sweden). Jimmy did a speech called “Visualization bonanza”, where he presented 40 visualization examples in ten minutes! I learned that he was about to write a book, and I immediately got excited since I’m a big fan of visualization myself. When the book with the full title ”Toolbox for the Agile Coach – Visualization Examples” was released, I got hold of a copy and started reading!



The book holds 124 pages focusing on visualization examples, together with some general information. It is really hard to pick which examples to high-light in a review! It depends where your teams are in the Agile journey, and if they are using Scrum or Kanban. Instead I will list five visualizations we are using and can recommend, complemented with five we are curious about and want to try out.

Recommended visualization examples:

  • Urgent lane – Some of our teams use this for urgent stuff
  • Kaizen board – We use this to keep track of our continuous improvements
  • WIP limits – We use swim lanes to limit work in progress (together with avatars)
  • Limit by space – Really good to work with this
  • Pyramid backlog – We have used something similar, that has evolved and we are now using this.

Curious about and want to try out:

  • Dependency sprider
  • Achievement poster
  • Review queue
  • Today’s trick
  • I want to learn


I can truly recommend this book! The format is perfect; focused & really to the point. The book is packed with visualization examples you can start to use today. Jimmy Janlén is THE wizard of visualization!

All the best,
 Tomas from TheAgileist

No project managers in Agile?

Recently I visited another Lean Coffee in Stockholm. I really like these meetings, they give me new insights and more to think of. This time was no exception. The question that caught on to me was:

”What is the role of the project manager in the Agile world?”

This blog post is a summary of the discussion and my thoughts afterwards.


The role of project managers in software development

The person who wrote the question started to describe that his experience was that a project manager is someone who works ”från ax till limpa”. That is a Swedish expression roughly translated to ”from seed to bread”. It is used to say that you take part in the whole process of something, from the very start until it’s finished.

Now in Agile where the teams are empowered, the role of the traditional project manager becomes more vague. In Scrum for example, no project manager role is specified. You have the team, Scrum Master and Product Owner roles that all share management duties between them. In Kanban, no roles at all are stated, merely ”Respect the current process, roles, responsibilities and titles”. The writer of the question continued to say that the project managers he sees at his company now works with ”packaging”. They ”take the bread from the oven, and put in bags for delivery”.

As I have written earlier, the executives of the company sets the vision. The teams starts to seek and find solutions to the problems that are in line with the company vision. The knowledge and power are now more evenly spread. Teams are autonomous and self-organizing. Management is there to remove impediments and reminding of the overall vision (to prevent sub optimization).

What now?

But what about the ”middle managers” (between the executives and the teams)? What shall they do now? I think that solving this question will remove a huge obstacle that now stands in the way for a wider agile adoption throughout companies worldwide.

First question, shall we have projects at all in software development? We have stable teams that continuously work iteratively with the same product over a longer period of time, so the need of time boxed projects seems to be vanishing. There is a #noprojects movement within the Agile world (lead by Allan Kelly).

In Kanban 2.0 there are actually two roles specified (David J Anderson states this in his upcoming book that will be released in 2016)! From the ”Essential Kanban Condensed Guide” I take the following:

The two roles are:

Service Request Manager: responsible for understanding the needs and expectations of customers, and for selecting and ordering work items accordingly (alternative names for the role: Product Manager, Product Owner, Service Manager)

Service Delivery Manager: responsible for the flow of work in delivering selecting items to customers (alternative names for the role: Flow Manager, Delivery Manager or even Flow Master)

The second one there sounds to me a bit like the one that keep track of all the pieces and put the puzzle together. Or to ”take the bread from the oven and put in bags for delivery”, to put it another way.

Right now I think that many former project managers in agile companies are working as agile coaches or have the role of a release/delivery manager.


So what about project managers? My take is that the role of a project manager, as we have thought of it, will slowly disappear and in some years there will be no project managers in traditional sense left within software development.

All the best,
 Tomas from TheAgileist

The Nature of Software Development

Time has come for me to do a another book review. Now it’s ”The Nature of Software Development” by Ron Jeffries (one of the original Agile Manifesto signatories, @RonJeffries on Twitter). It was published 2015 and is a truly agile book with 150 pages full of wisdom! And questions. That can raise wisdom. If you ask me, I think this book is fantastic! Let me try to explain why, whilst sharing some quotes from the book.



A few weeks ago I attended Lean Kanban Nordic 2015 in Stockholm. Henrik Kniberg did a keynote presentation with the title ”The Art of Figuring Out What to Build”. It was all about focusing on building the right things, the ones that brings value to the customer. This shall be done in smaller increments to allow fast feedback to avoid the ”big bang”-approach that is the case with the Waterfall-method. As you will see, this resonates 100% with what is written in this book.

”Here’s a better way: set a time and money budget, produce the most valuable features first; keep the product ready to ship at all time – and stop when the clock runs out.” – Ron Jeffries


The book consist of 22 short chapters and they are divided into two parts:

  • Part I – The Circle of Value
  • Part II – Notes and Essays

The first part starts by stating ”As we do, your job is to think a lot, while I write very little”. A lot of thoughtful questions are raised throughout the book, time should be spent thinking of those! First out in the book is value, that is the point of our work, and stated to be ”what you want”. We should ship value in smaller pieces.

How should we bring value? One key component is to organize ourselves into small teams that deliver features, feature teams. Persons that share the same competence in the feature teams will form a guild or community of practice. Things go best with frequent releases of the software. We should not think or keep track of low-value ideas. Two levels are used to describe functionality; features -> stories. Stories is not recommended to be broken down into tasks, but rather smaller stories. As for planning use ”Yesterday’s Weather”. You will probably get as much done in this coming iteration, as you did in the last one. If you need to state how long things will take, just count the things that are done and make a prediction.

Build your product, feature by feature. For this to work the product needs to be nearly free of defects after each iteration (two week period). In fact, the product needs to be nearly free of defects all the time! The features needs to be build upon a solid foundation or ”infrastructure”, that is developed at the same time as the features. We test at two levels, with ”Business” tests and ”Programmer” tests. All these tests needs to be automated. Refactoring is also essential.

Ron Jeffries emphasize ”Show us the software”, for him meaning:

  • Focus on value for best result
  • Produce real software often
  • Build in small steps for faster feedback
  • Learn the planning and management skills needed

Management shall state what to do, but leave to the teams the how to do it. Management shall also limit the number of products and programs to work on, since working on a lot of things in parallel just slows everything down.

In chapter 20, the final point is ”Most of all, think”. Building a product is complex, you should use inspect and adapt.

”Dirty code slows you down as well. If the code is clean, the next features go in smoothly.” – Ron Jeffries


This is a true master piece! Since the chapters are so short and to the point, it’s almost like reading poetry. Agile poetry. This is the ”true north” or ”guiding star” in Agile we all should aim for! In 5 to 10 years from now, everything in this book will seem darn obvious and the whole software industry will be working this way. Hopefully. If everybody reads it. I check on Amazon and see that the book is only in place #222,501. That worries me. A lot. So read it and spread the word, like me and others have done.

”Generally speaking, estimates are likely to be wrong, and they focus our attention on the cost of things rather than on value. Consider de-emphasizing or eliminating cost estimates and steering to success by a focus on value.” – Ron Jeffries

All the best,
 Tomas from TheAgileist


The Product Backlog is an essential artifact in Scrum. The description of the Product Backlog on currently says: ”The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value.” Many organizations have taken these words literally, and have hundreds of items in their product backlogs. Time is spent ”backlog grooming”, where items are re-estimated and re-ordered. To me it’s pointless to keep track of such a long list of things to do. You only need a shorter list, with what you should do next. I think it’s time for this to be changed.

Sources of inspiration

I have been thinking about this for some time and the following sources of information have inspired me:

  • ”Backlogs Are Not Waste” – Jurgen Appelo made a great blog post that really made me think. In it he separates wish lists (”A wish list is a list of Could-Haves”) from checklists (”A checklist is a list of Must-Haves”). Even if you don’t buy everything from your children’s wish list you can still make them happy at Christmas (if you buy the things that delivers most value to them). If you forget something from your checklist while shopping food for a dinner, you can end up with a Chili con carne without beef (making it a Chili sin carne). On a wish list you need to dome some things, while for a checklist you need to complete all of them. I think that many people think of a product backlog more like a checklist, not a wish list.
  • #NoEstimates semantic discussion  – I have been following the vivid #NoEstimates debate on Twitter for some time. A few months ago the focus was on semantics. The term #NoEstimates was attacked because is says ”no estimates”, while the founders of the movement more are meaning ”to seek alternative ways to reduce the need of estimation”. The debate was that it should be called #LessEstimates, #BeyondEstimates or #EstimateFree. My conclusion is that you should call things for what they really are. Backlog sounds to me something that goes ”back in time”, meaning things that you should have done already, giving a feeling that you are late from the start.
  • ”The backlog” – Ron Jeffries recently published a very thoughtful blog post about backlogs. Here he presents other ways ”around” using a backlog with Index Cards, Product Vision, Product Increment and Regular Live Product Review. He thinks that the backlog notion should be eliminated, but leaves it up to other persons to actually do so.

Ron Jeffries is a ”big fish” and I assume he can’t come up with new definitions without the risk of annoying a large number of people. Since I don’t have that problem, I hereby introduce the futurelog!




”A futurelog contains items that may or may not be included in your product in the future. A futurelog is best kept short and visualized.”

Some more explanation may be in place:

  • A futurelog is per definition a wish list.
  • A futurelog focus on value.
  • A futurelog is best kept short only showing the items that are ”next in line” with some reasonable buffer.
  • A futurelog should be visualized (see next section for some ideas on that).
  • The futurelog needs to be revised on regular basis.
  • A futurelog is never ”complete” or ”done”, it shall live as long as your product live.

Other than that you can think of and use the futurelog just as a regular product backlog.

How to visualize the futurelog

Since I’m a big fan of visualization I have some ideas on how it could be done:

  1. ”Priority pyramid” – The simplest way to visualize your futurelog is to use the ”Priority pyramid”. You need to replace priority with value.
  2. ”The Arrow” – If you have one product and one team working on it, I recommend that you visualize your futurelog using ”The Arrow”. As for the ”Priority pyramid” you need to replace priority with value.
  3. ”Product radar” – One other elegant way to visualize this is to use the ”Product radar”. Things closest to the center have highest value.


I hope you like the idea of a futurelog to replace the product backlog. As usual, if you have feedback and comments let me know! Finally, you can now say ”I see into the future” whenever you look inside your futurelog :).

All the best,
 Tomas from TheAgileist

Learning Agile

I have to admit, I have a little quest going on. To read all books that come up on the first page (12 items) when searching for the word ”Kanban” in Books on (sorted by relevance). It’s a fun quest, but I don’t know if I will ever complete it though, since the search result keeps on changing over time 🙂 Anyhow, in that quest, I have read ”Learning Agile” by Andrew Stellman and Jennifer Greene. The book was released in November 2014 and the sub title is ”Understanding Scrum, XP, Lean, and Kanban”.



The book has ten chapters and they are:

  1. Learning Agile
  2. Understanding Agile Values
  3. The Agile Principles
  4. Scrum and Self-Organizing Teams
  5. Scrum Planning and Collective Management
  6. XP and Embracing Change
  7. XP, Simplicity, and Incremental Design
  8. Lean, Eliminating Waste, and Seeing the Whole
  9. Kanban, Flow, and Constantly Improving
  10. The Agile Coach.

The first chapter sets the agenda for the book by presenting what Agile is (”Agile is a set of methods and methodologies that help your team to think more effectively, work more efficiently, and make better decisions”) and how it is structured.

In the second chapter the Manifesto for Agile Software Development is introduced. This and all the following chapters are structured in a very pedagogical way. The subjects are first described in ”plain text”, broad up again in a narrative (fictive stories), summed up as key points and finished off as a FAQ (Frequently Asked Questions). This redundancy is intentional according to the authors ”we do it to help you get that ’aha’ moment”. For me, that have read a few other books on Agile, this gets a little boring and time consuming with all the repetition. The book spans 420 pages which could have, in my option, been less to be a truly ”agile” book.

Moving on, the third chapter explains The 12 Principles of Agile Software in greater detail. This is a good chapter to get a deeper understanding of the Agile principles!

Forth chapter starts off with a good slogan from the board game Othello: ”A minute to learn, a lifetime to master”. This can be applied to all Agile methodologies described in this book (well, maybe not just a minute to learn, but they are all very simple to get started with but needs a lot of practice to ”master”). If you want to know the basics of Scrum, you can download the official Scrum Guide. More in this chapter are the five Scrum values:

  • Courage
  • Commitment
  • Respect
  • Focus
  • Openness.

Chapter 5 completes Scrum, it has a reference to a survey (on page 142) that states that 64% of the features in software is never used! It can be due to something called gold-plating. Developers that, with the best of intent, throw in extra functionality that never has been requested.

Chapter 6 & 7 covers XP (eXtreme Programming) that has similarities with Scrum. A personal takeaway from this section (though I’m not programming anymore) was the section about code smells or anti patterns (”a pattern of behavior that a team exhibits that cause problems with the project”). Those being listed are:

  • Shotgun surgery – A small change to one part of the code requires another change in another part of the code than in turn requires yet another change somewhere else in the code and so on.
  • Half-baked code – An object that needs to initialize other (irrelevant) objects as well to be used.
  • Very large classes – Hard to read and maintain.
  • Duplicated code – Identical (or almost identical) blocks of code that does the same thing.
  • Spaghetti code – Code with complex and tangled structure.
  • Lasagna code – Too many layers.
  • Hook – A hook added for future use (but then never used).
  • Edge case – Code that handles an edge case that seldom (never) will happen but makes the ”normal flow” much more complex to understand and maintain.

”A system that’s designed to immediately report a failure as soon as it happens is called a fast-fail system” – Andrew Stellman & Jennifer Greene

I would also like to list the XP practices:

  • Pair programming
  • Continuous integration
  • Energized work
  • Ten-minute build
  • Incremental design
  • Whole team
  • Refactoring
  • Sit together
  • Test-driven development.

Chapter 8 talks about Lean that is a mindset with its own values and principles. The values are:

  • Eliminate waste
  • Amplify learning
  • Decide as late as possible
  • Deliver as fast as possible
  • Empower the team
  • Build integrity in
  • See the whole.

Reaching the end here, chapter 9 is about Kanban, flow and constantly improving (kaizen). Not so much new stuff for me here, once again WIP (Work in Process) limits are enforced and described as the ”secret sauce” behind Kanban.

”Kanban is about helping a team improve the way that they build software” – Andrew Stellman & Jennifer Greene

Final chapter tells you about the agile coach that helps the team adopt agile. The team needs an agile mindset to be successful with an agile methodology.


If your are new to Agile, and have a lot of time to read, I can recommend this book to get more knowledge about Scrum, XP, Lean and Kanban. If you only want to know about a specific method, or have short of time, there are other more suitable books around.

All the best,
 Tomas from TheAgileist

Agile captains

This blog post will tell you about how we define the role of agile captain, something that I know stands out a bit after discussing with others in the agile community.

In Scrum, three roles are defined:

  • Scrum Master – Leads the team and work with removing impediments to get the work forward.
  • Product OwnerReceives, handles and prioritize the requirements for a product.
  • Team members – Persons that are part of the team that shall be cross-functional and self-organizing.

We are in a transition phase from Scrum into Kanban and what roles shall you have then? Looking in the Kanban literature, it only states:

Respect the current process, roles, responsibilities and titles” (taken from Wikipedia)

It feels awkward to call the team leaders for Scrum Masters when we are not using Scrum. We looked to the world of sports for inspiration.


In most team sports, the concept of captains are present. Like in ice hockey for example. The captains are players with extra leadership qualities that leads the others on the ice. They interact with other ”stakeholders”, like the coaches (to discuss game strategies) and the referees (to discuss decisions that are being made). The coaches are not playing the game themselves, they supervise and make adjustments (enforcing different game tactics, shifting players, etc.) trying to win the game.

Agile captains

For me, an agile coach it not necessarily part of the team. This is how we define agile captains:

  • ”C” – The head captain. A servant team leader with some extra responsibilities.
  • ”A” – The assistant captain. Also a servant team leader with a few extra responsibilities. However we don’t really make any difference in status between ”C” and ”A”, they are equal.

One of them lead the daily standup meeting. Why have two? Maybe the captain is sick or working from home one day, then it is more convenient to have the assistant stepping in. It’s also good to be two persons, to have a natural part to discuss with before making a decision. The captains also work as a interface from the team to other stakeholders. Comparing to Scrum the role of captain has similarities to the ”Scrum Master”-role.


  • Redundancy – If one captain is not present, the other one can step in and for example conduct the daily standup meeting.
  • Sharing work load – An example, each team needs to be represented on a high-level planning meeting. Then the captains can decide between each other, given the tasks they have at the moment, who shall participate.
  • Better decisions – Not one single person being responsible for a decision. There is always another person (the other captain) to discuss with, before making any type of decision. Two brains are better than one!


  • No one solely responsible for the team. Since we are not giving the ”C” captain more status, we don’t have one single person responsible for the team. It could be a problem, leading to a ”blame game” between the captains, but we have not experienced this.


The role of agile captain is working really well for us, what do you call your team leaders in Kanban?

All the best,
 Tomas from TheAgileist