When plans and reality collide there is a need for agility.

As much as we love Scrum, even we would have to admit that it’s not perfect.  Nothing is. In fact, a large part of the literature describes workarounds for various deficiencies that Scrum presents to us in certain circumstances.

One of the more commonly noted deficiencies in Scrum is that it plans its work a whole Sprint at a time.  This “batch” planning process is often not agile enough to cope with the actual rate of change of requirements.  In fact, PlaceHolder Stories, discussions of mid-Sprint Re-planning, and discussions of renegotiating the scope of a Sprint are common deficiencies that teams must cope with.

The new kid, called Kanban, which solves some of these deficiencies and presents others, is becoming popular for software development projects.

Altogether, Kanban, Scrum, XP and many other agile methods rely on a task boards and index card like systems to simultaneously decompose and manage the work. What’s new about task boards and index card systems? Index card systems have been around at least since 1925, when the first one was formalized by Dr. Crawford and used later to build NASA rockets. Increasing task orientation is a well understood method for improving team performance and has been well documented since the 1950s. Our goal will be to highlight both Kanban and Scrum and then touch on why we need to reinvent them ourselves so often.

Learning Objectives

• An overview of Kanban
• An overview of Scrum
• Stacking them side by side
• The Power of Index Card Systems and Task Orientation
• Can one reduce or evolve from one to the other?
• Why do we repeat ourselves so often?

1. No way, they are opposites: Kanban is for flow / Scrum batch
2. Yes, Scrum is old school big planning steps
3. Yes, Kanban minimal planning / Scrum is heavy planning
4. No, Scrum can reduce to KanBan

As much as we love scrum, even we would have to admit that it’s not perfect

. Nothing is.  In  fact, a  large part of our book describes workarounds  for various deficiencies that scrum presents to us in certain circumstances.

One of the more commonly noted deficiencies in scrum is that it plans its work a whole Sprint at a  time.   This “batch” planning process  is often not agile enough  to cope with the actual rate of change of requirements.    In fact, Chapter 4.4 on PlaceHolder Stories, the  discussion  of  the  mid-Sprint  Re-planning  in  Chapter  4.8,  and  the  discussion  of renegotiating the scope of a Sprint in Chapter 4.3 are all about resolving this deficiency.

There  is  another  agile  process,  called  KanBan,  which  solves  this  problem  and  is becoming popular  for  software development projects.  In our upcoming book we will describe the main strength of KanBan and how to integrate it into scrum.

Brief Description of KanBan

The  “KanBan  for  software” movement  is  really gaining some  traction  in  the  agile  community.    The main  idea  of  KanBan  is  very  simple  and based  on  the  Lean  “pull,”  “Just  in  Time”  (JIT),  and  “reduce  inventory”  principles:  eliminate planning inventory by making sure that you don’t commit to doing work until you are actually ready to start the work.

Choose

1. The development team creates a spec.
2. The Product Owner says it is.
3. The business asks for it.
4. There is a test which actually requires it to be there and fails when it is not.

Comment: We often find ourselves lost in the desirements trying to find the real requirements for our system. Those things which seem required often end up being only desired. The word requirement has suffered more from confusion and misuse than just about any other word in the IT lexicon of development. What is a “nice to have” requirement? I mean really! I have close to 20 years of experience in the industry including training and writing requirements. Even with all of that experience the word still makes me a little crazy. I like the word desirement because of it’s contrast with requirement. When there is a test that makes it required with a pass/fail then it is a requirement, until then it’s just a a desirement.

So, a more interesting question is …. When is a requirement truly required?

Comment: The idea here is that there can be only one source for Scrum knowledge. I guess that depends on where you get your definition from and what you need. Should there be only one way to think about scrum? Probably not, although,  a rookie mistake is to modify without have deep applied practice and experience under your belt. The 1st common mistake we see people make is modifying scrum without understanding it. They often confuse themselves and their organization.

In this chapter we explore how it applies to Scrum.

How it scales?
Where the difficulties are?
etc.

Please read and comment.

Thank you
- Dan and Doug

I hope you enjoy. Please leave a comment on your experience.

Look for more videos coming soon from a wide audience of practitioners, coaches and trainers.

Capabilities are the things we talk about with our stakeholders, and we talk about them in the stakeholder’s language. Strictly speaking, capabilities are seldom of concern to the development team, as the developers will be working on stories, which we’ll discuss later in this chapter. Capabilities far too often too big, hard to validate chucks of work, so it is not something we want to feed our team directly as an item of work. The reason is simple, large chunks or difficult to validate chunks of work lead to elongated feedback cycles and this is what got us into trouble in the first place.

Our development is being done to acquire those capabilities for the stakeholders, and therefore we must be able to talk about capabilities with our stakeholders. Capabilities are the language the stakeholders are thinking in and it’s is what they will use to understand the product we have built.

As we know, stakeholders can ask for virtually anything. Therefore, capabilities can be virtually anything, from small bugs that he be fixed to extremely large wishes and dreams. For example, each of the following statements describes a capability:

• Remove the extra linefeeds in the presentation of the list of flights on the “Choose a Flight” page (a bug);
• I want to be able specify that I need a special meal for my flight (a new feature); and
• Make it faster (an extremely large, ambiguous request).

What’s important to know about capabilities is that the priorities of the capabilities derived from the stakeholders, even though they may be modified by dependencies that the developers see. Since scrum is all about having a prioritized list of things to work on, we can see that most of the priorities that we derive from the stakeholders.

What we are usually trying to deliver in a release is a releasable capability. This leads to concepts that we find in the literature such as Minimal Marketable Feature (MMF), Minimal Releasable Feature (MRF), and so on. Even though I won’t discuss it, I think that for scrum what we really need to produce is Minimal Demonstrable Features (MDF), as the basic concept of scrum is to inspect and adapt, so we need to produce capabilities that we can demonstrate in order to get feedback.

The tasks for a story are “owned” by the team; the team commits to stories, not tasks. The tasks only exist to aid the team in its development efforts – it is the “doneness” criteria that define the “contract” for the story, not the tasks. Generally speaking, it is nobody’s concern except the team’s who works on what task, or even what the tasks are.

In any case, an epic is an item that contains at least one story, even if the story is just an investigatory one. Usually, an epic contains analysis stories that produce other stories that also belong to the epic. In other words, an epic is a container of stories, and we tend to refer to any container of stories as an epic.

Since an epic becomes an epic if the team can’t commit to it, sometimes we are surprised when an item we thought was a story turns out to be an epic during planning; we only find out when the team declines to commit. This is not unusual, because we can’t know whether or not we can commit for sure until we know what “done” means for the item.

Most capabilities are epics rather than stories; the main counterexamples being bugs or trivial features. If we think of a use case as being a typical capability for our software, then it is an epic, with the individual scenarios of the use case being potential stories. Of course, some of them might actually be big enough to be epics of their own.

Some examples of epics are:

•        “We want the system to be able to manage the pilots’ schedules”;

•        “We’re going to need to train all our users on this new release”;

•        “As a <tourist>, I want to <fly to Catalina for the weekend>”; or

•        “I need you to translate the website to Spanish, because I’m planning to do a lot of marketing of Catalina Air in Mexico”.