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

(Scrum I, Early Scrum, 1995-2004-ish) PO usually external to team, negotiates sprint backlog with the team. The team self-organizes, produces “done” product, and has a Sprint Review with the PO, who either approves or disapproves the work. The only way to “officially” change requirements in the middle of the sprint is to have an abnormal termination and start over. After the sprint the team (sometimes including the PO) has a retrospective to improve its process, and the PO modifies the release plan.

This leads to a number of Issues/Forces:
 - adapting to business changes within the sprint is difficult
 - hard to talk to PO for additional guidance during the sprint
 - often caused the team to view the PO as “one of them” and not “one of us”
 - many teams created a “Product Owner Proxy” who represented the PO day-to-day on the team

(Scrum II, Modern Scrum, 2002-Present) PO internal to team, and negotiates sprint backlog with rest of team. The team (including the PO) self-organizes, produces “done” product that is accepted by the PO along the way. Teams develop various methods for reprioritizing and bringing in new work during a sprint (negotiating techniques, mid-sprint replanning, etc). The Team (including PO) reviews the results with external stakeholders during the Sprint Review and receives feedback that changes the release plan and is incorporated into the next sprint’s planning. After the sprint the team (including the PO) has a retrospective to improve its process.

Differences:
 - PO on team
 - more in-the-sprint changes to Sprint Backlog
 - PO is more a part of the team’s day to day work
 - Adaptive Evolution of the Product is finer grained
 - Focus on delivery to Stakeholders, not PO

There were/are some Issues/Forces:
 - Still not quite adaptive enough for some
 - “last few” stories on sprint backlog are always being supplanted by new ones
 - Sprint lengths got shorter to allow for more frequent feedback and planning
 - can’t make the sprints as short as we’d like to because some stories just “take that long”

(Scrum III (KanBan-ish version), 2007-Present) There is no Sprint Backlog, only Work In Progress (WIP), which is fixed length set of stories currently being worked on. There is still a Sprint, which is a fixed-length timebox that defines the time between reviews, the changes to release planning, and the setting of sprint goals. At the beginning of the sprint the Product Owner negotiates goals for the sprint with the team. The team is constantly grooming and reprioritizing the backlog. When a story is completed, a new one is moved up to the WIP and begun. At the end of the Sprint there is a Sprint Review for the Stakeholders where the completed work is reviewed.

Differences:
 - Sprint Backlog replaced by WIP
 - because is WIP, stories can go across sprint boundaries

Note that this evolutionary change is much smaller than the former. Perhaps we are converging on a final solution – I don’t know. I have no idea what comes after this. We’ll just have to wait and see what issues come up, and what patterns emerge.

Dan  

• 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.