A Common Phrase

It’s not uncommon that I will hear a team, Product Owner or even a Scrum Master describe their refinement efforts as “chunking” up the work. While it might sound harmless it’s almost always an indication that there is a lack of understanding of Scrum and user stories in particular.

If you are creating “chunks” of work it implies that you have a larger, defined effort that, when the chunks are later reassembled, equal what was initially planned. I have several Lego models that come to mind. When you build a Lego kit you create a number of smaller “chunks” that, when later snapped together, equal the whole. But how well does that concept apply to knowledge work such as software product development?

What is “Complex” work?

Software development is an example of solving Complex problems. In 1999, Dave Snowden, from IBM, created what is called the cynefin (kuh-NEV-in) framework. This framework can be used to make decisions on how to proceed based on the situation/problems encountered. There are 5 Domains in the cynefin model: Clear, Complicated, Complex, Chaotic and Confusion.

Much of the work that Development Teams do can be classified as either Complicated or Complex. Characteristics of these domains are (descriptions from wikipedia):

  • Complicated: “The complicated domain consists of the “known unknowns”. The relationship between cause and effect requires analysis or expertise; there are a range of right answers. The framework recommends “sense–analyze–respond”: assess the facts, analyze, and apply the appropriate good operating practice.”
  • Complex: The complex domain represents the “unknown unknowns”. Cause and effect can only be deduced in retrospect, and there are no right answers. “Instructive patterns … can emerge,” write Snowden and Boone, “if the leader conducts experiments that are safe to fail.” Cynefin calls this process “probe–sense–respond”.

Agile is designed to solve Complex problems

Problems that lie within the Complicated space will have a set of known solutions that likely require experts to identify and implement. In an IT context, an example would be using the concept of “connectors” when implementing single-sign-on with any number of legacy systems. The solution (good practice) is known, a connector is used. This is often the domain of expert Consultants.

Problems in the Complex domain don’t have “correct” solutions that are known in advance because they are characterized by “unknown unknowns”. Solving them requires probing the situation, sensing how those probing efforts alter or change the environment and then responding accordingly, resolving unknowns as you proceed. That sounds a lot like the Plan, Do, Check, Act/Adjust (PDCA) cycle that is at the heart of iterative, emergent software development. It also sounds a lot like the Scrum event flow of Sprint Planning, executing/doing the Sprint, the Sprint Review and the adapting/adjusting during the Sprint Retrospective. That’s not to say that Agile = Scrum, far from it. But Scrum does support and promote iterative, emergent software development.

The Complex domain is the domain of emergence. The best products will emerge by probing, sensing and responding to customers needs in small iterations. Continually delivering valuable product increments based on feedback of what has been created so far keeps the team on target. The best working methods and practices will emerge by utilizing short, safe to fail experiments based on inspection of the current environment. Emergence is a primary element of Agile.

Thinking in “chunks” creates a Story/Feature Factory

Recall the example of building a Lego model. Chunking larger work implies that you already have the final solution in mind and that the team just needs to do this “things”, in this order, to deliver that previously defined solution. You’ve created a to-do list that can just be handed off to the developers to code and test. The development team has been reduced to simple order-takers executing a plan.

The Features and Stories will continue to flow, go do these things, in this order. The focus shifts to creating a massive amount of output that is often measured using something like Story Points and Velocity (listen to my thoughts on that here). The team may use Scrum events like the Sprint Review but it will largely be a demo and not a conversation to gather, and act upon, feedback from customers. The team may even simply call it a demo (forgetting the review aspect).

These are not the actions of an Agile team that understands the PDCA cycle, developing a product that emerges based on what they have done so far utilizing customer information and feedback. They are attempting to solve Complex problems with linear thinking. The focus is not on the outcomes they are delivering but instead pushing out “chunks” of output according to the to-do list (the various chunks of the larger effort). They are not solving the Complex problems by using emergence, or more loosely, Agile.

The team has become a Feature Factory. You can read more about that in Escaping the Build Trap by Melissa Perri.

Scrum is a discovery framework

Like the situation describe above, the team is using Scrum to implement a traditional software development process. The “requirements” are being cloaked as user stories (chunks). The other traditional waterfall steps are being implemented under the guise of the Sprint. The focus is largely on pushing out a lot of output with little regard to feedback, outcomes and, ultimately, the impact on customers of all of this output.

The intent of Scrum is to discover what is needed as the work proceeds. In other words, through emergence (recall the PDCA cycle). Scrum implements a number of feedback loops and events that support an emergent Product Backlog, not one pre-populated by “chunks” of larger efforts. It’s unfortunate that many teams don’t understand the importance of the Sprint Review in emerging the highest value outcomes. Many simply do a demo and expect the Product Owner to approve their work. End of story, now go do the next chunks.

Everything is an experiment

One of the key concepts I’ve found is to think of everything as an experiment. A user story, a feature, everything is an experiment. It is this thinking which will allow the team to emerge the highest value outcomes which will have the largest impacts – to change the world for the customer if you will. Approach every story as an experiment – does this increase the value to the customer? If no, what would? This is how you iteratively emerge high value products, services and methods.

If a story or feature doesn’t add value to the customer, get rid of it. Don’t maintain that code in the code base. It will become technical debt and be harder to remove in the future. It’s also a good practice, in this situation, to examine the hypothesis that was created as part of the story or feature. Was the experiment sound?

Wrapping Up

Scrum can be a useful framework for teaching teams and organizations to solve Complex problems in an Agile way. But often times I encounter teams that are hiding a traditional approach under a thin veneer of Scrum labels and events. One of the key symptoms is teams that are “chunking” work. Almost like they have taken a formal requirements document and cut it up into paragraphs (chunks) and written then as user stories. Those are to-do lists, not outcomes that we hypothesize are of benefit (high value to the customer).

Until next time!

(Visited 48 times, 1 visits today)

Leave A Comment

Your email address will not be published. Required fields are marked *