Small Feedback

In my experience one of the single biggest impediments for teams trying to embrace Agile is: they can't 'think small.' This cognitive challenge is a significant obstacle to attaining Jon Kern's goal in Agile: "Reduce the gap in time between an action and getting feedback."

Yet the very essence of incremental development and delivery is to embrace small batch size. The value of this should be self-evident. For example, is it easier to debug and isolate a defect in 10,000 new lines of code (LOC) or in 100 new LOC? The answer is obvious. A small batch of new code is much more manageable.

Similarly, small stories are more manageable, more easily tested, and provide more rapid feedback on whether the code matches that part of the requirements implemented for the story.

Big stories are a liability. Two major symptoms alert us that a story is too big. 

1) The story is not 'done' until the last day of the sprint and the team may expend extraordinary effort to meet this deadline, or
2) A story committed by the team in Sprint Planning is not completed within the sprint and rolls over to a subsequent sprint.

I have been astounded when teams experiencing both of these symptoms said that their solution is to increase the length of the sprints!

When a story is too big we do not get immediate feedback. We have to write a lot of code for big stories. Testing a lot of code takes a lot of time. We know from decades of empirical research that the number of potential defects (bugs) is directly proportional to the LOC we write. Defect isolation is difficult when we have lots of LOC. But developers seem to naturally fall into thinking 'big' about stories, and commonly state, "But we have to have all of this functionality." What these excuses are missing is, yes, we have to have all the functionality eventually, but not all in this sprint!

Ironically, technical teams often do 'think small' very easily when they choose to create backlog content that is really low-level tasks rather than value-laden business functionality. This is a direct consequence of how developers have been trained to think of their job as completing programming tasks rather than delivering business and end-user value. If your team does not engage or even mention problem analysis in their planning, then you know you have a team of narrow programmers rather than mature product developers.

As Scrum Masters we must guide our teams to think small. And small stories should not be delivered all on the last day of a sprint: they should be delivered early and throughout the sprint. Small stories should not roll over to the next sprint: they should allow the team to meet their commitment to the current sprint. Small stories lead to fewer LOC and, therefore, code that is faster to write, easier to debug and test, and generally higher quality. Small stories are conducive to "maximizing the code not written." And most importantly, small stories enable Jon Kern's goal of getting feedback as quickly as possible as, and after, the code is written.

So, now we can be honest about how we fool ourselves into thinking we are agile. Agile was not created as a way to have daily stand ups, nor to use tools like Jira, or even to write requirements as stories rather than 300 page Business Requirements Documents. All of these activities are window dressing, and really have nothing to do with Agile. These mechanical practices seduce us into thinking we are actually doing something different from Waterfall.

Agile exists for one reason: to get feedback on usable value as quickly as possible so that we can confirm we have developed and delivered the right thing, or that we need to make adaptations to correct our deviation from our goal. If we are not achieving this, then we are deceiving ourselves and might as well be doing Big Waterfall.

This post is Part One of a discussion about 'thinking small'. In Part Two I will provide a rather lengthy and detailed discussion with a case study of how to actually engage in breaking down a large amount of work into multiple smaller efforts following what I call a 'thin thread' approach.