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?

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.

In general, a story is simply a request for the team to do something of value. This does not mean releasable value; that’s what capabilities are for. It does mean demonstrable, testable, verifiable value, as we need to be able to be able to inspect and adapt based on the results.

A story is an extension of the user story, which was introduced in eXtreme Programming (XP), but we don’t restrict stories in scrum the just the ones that user value. This is why we just call them “stories”, and often add a modifier, like “analysis story” or “infrastructure story” or “development story”.

In spite of the fact that not all our stories are user stories, it is useful to look at the INVEST acronym, which Bill Wake originally introduced to describe “good” user stories:

While the acronym needs to twist a little bit to fit when we expand the concept from “user story” to just plain “story”, the basic ideas are good. Basically, a good story is one that is small and well-understood enough for the team to commit to and not be confused by. If we are talking about functional stories, the definition of “small” the I like to use is “one thread” or “one positive test” or “one state of the system” or something like that. We’ll discuss this concept in the next chapter, when we discuss the definition of “done.”

The concept of the story is both simple and brilliant. What makes it simple is that at its core a story is just a request for something of value, and the purpose of the story is to start a conversation.  The story takes the place of a requirement, but it has a completely different tone.  Whereas the requirement has the tone “here’s what I want, just go do it” the story has the tone “here’s what I want, let’s talk”. As Alistair Cockburn has said “a story is a promise for a conversation”.

What makes a story brilliant is that not only does it replace a requirement, it also replaces the low-level activity; a story is not only the request for value, it is also the activity, or work, that it will take to provide the value.  In practice, this means that as you are doing analysis in order to find requirements/stories you are also developing your units of work.  All you have to do is add prioritization, and you’re good to go – your planning is done. Some examples of stories include:

•         “As a <passenger>, I want to <be able to select my seat online>, so that <I don’t have to do it at the airport>”;

•         “Go talk to the pilots and find out what they think about pilot compensation”;

•         “Review the suggestions the pilots have submitted to see if there’s anything cool there”; or

•         “I need somebody to spend an afternoon with the pilots, to explain to them how the pilot compensation page works”.

There are other things we want from our stories, as well, and we’ll be discussing them throughout this book. For now, though, this is enough.

• Project Management is mainly about “managing the work” or stimulating the environment so the work gets done with minimal telling people how / what to do.
• Source Control if it’s only one file then, I don’t need it of course it is always more than that as soon as it goes over 100 files it becomes a necessity.
• Build automation (and repeatable automated configurations as a whole) shows up after source control and becomes a necessity around 500(pick a number that you think you will go crazy at) items or so. It is a number thing but, I can get by longer without repeatable automated configurations than I can without Source Control.
• Test Automation this shows up as needed after 1000 plus code files. Test automation is all about feedback. When I say feedback it assumes people are already thinking in terms of interface design “start with the end in mind” if not then TDD/Unit must be purused because people are missing critical thinking skills.

Here is round 2.

This is close to a done draft.

Please read and comment.

                                               Scrum In A Nutshell – Quick Summary

For a group of people, when the visilbility of the work between is poor or hidden then the  collaborative interactions are correspondinlgy very  poor. This holds especially true for work that is largely coneptual in nature. 

By making things visible people have a chance to self organize to the work and pitch in without being told. They work together collaborative to do the job. Making things visible in the right way is the challenge of management. 

Download Scrum In A Nutshell

excerpt… “While the Stakeholders are the most important people for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is held accountable by them for the success of the Team. The Product Owner provides direction and goals for the Team, and prioritizes what will be done.”

• How much is the PO truely seprate from the team?
• Is there a single wringlable neck?
• Is the team / PO a symbiotic ecosystem with a centralized model for detemining direction? thoughts?

This is free for you to consume. It is our hope that you will provide comments and feedback. Those that do can register on our community site and provide constructive comments. They will be acknowledged. We will use your comments to evolve the explanation of thought here or clarify ideas. As you read, hold on to your shoes because each sentence is loaded with deep layer focused meaning and if you skip around reading this will hurt your understanding.