As children we were told by adults to take smaller bites when eating. We didn’t always understand the risk of choking that they saw, but ultimately it was easier and safer to chew those smaller bites. In some cases, taking smaller bites made the difference in finishing more of the meal. But have we translated that lesson to other things in our lives?
Often we try try to tackle things that are too big to sufficiently understand, estimate, or complete in a reasonable amount of time and we suffer for it. We don’t always see the risks that hide in more complex items and thus don’t feel compelled to break them down. Other times we fail to break things down due to unknowns, ignorance, uncertainty, pride, optimism, or even laziness.
Variation in Software
Delivering software products is a constant struggle with variation of size and complexity. It’s everywhere, from the size of user stories to tasks to code changes to releases. It is present from the moment someone has an idea to the moment software is deployed. We strive to understand, simplify, prioritize and execute on different types of things that are difficult to digest. The more variation we see, the more we struggle with staying consistent and predictable.
Because of this variation, we need to be good at breaking things down to more manageable sizes. This need is so pervasive, I propose it be viewed as a fundamental skill in software. I don’t think most teams recognize this and certainly don’t develop the skill. Many people on Agile teams exposed to concepts like Story decomposition don’t often realize how often they need to apply similar practices in so many other ways.
Why Decomposition Matters
My example of eating small bites was simplistic. In developing software, there is a lot more to gain but it is still ultimately about reducing risk and making tasks easier.
Progress
According to
The Progress Principle, a strong key to people remaining happy, engaged, motivated, and creative is making
regular progress on meaningful work. Not surprisingly, we want to get things done, but we also want to feel a sense of pride and accomplishment.
Of course, stakeholders and other parties are interested in seeing progress from those they depend on. When we are able to make more regular progress toward goals, we provide better measurements and visibility for ourselves and others to know how we are doing.
It should be no surprise that smaller items enable quicker progress toward goals, if done right. We certainly need to take care to avoid dependencies and wait time. Smaller, more independent goals allow more frequent progress and all the benefits that come with it.
Collaboration
As we have more people working on something, is it easier to put them all on a larger, more monolithic task or divide and conquer? Usually we prefer to divide and conquer. Yet how we divide is important as well because dependencies and other kinds of blocking issues create wait time and frustration.
Decomposition can be one of the easier ways to get additional people involved with helping accomplish a larger goal. By breaking up work into more isolated items to be done in parallel, we are increasing the ability to swarm on a problem.
Complexity
Complexity is one of the greatest challenges in software development. With more interactions, operations, and behavior,s we are more likely to have edge cases and exposure to risk when anything changes. Large goals are easier places for complexity to hide. The larger the task is when we try to accomplish it, the more details we have to discover, understand, validate, and implement.
Focusing on smaller units of work can be a helpful constraint we place on ourselves. Why add our own constraints? When we constrain ourselves to work on a small portion of a larger task we are trying to limit the complexity that prevents us from accomplishing something. We want to avoid a downward spiral of “what if?” and “we are going to need” scenarios that, while important, can slow the task at hand and lead to overthinking and overdesigning and accumulating work we may never need. We are trying to avoid
Analysis Paralysis.
Control
By looking at Kanban systems we can see wide variations in size can impact lead times. If we can be more consistent with the size of items flowing through a system then we will have more consistent throughput and cycle times. By breaking down work items more frequently into items of similar size cycle times become more stable and the average size (due to whatever size variation remains) becomes more useful for forecasting due to the
law of large numbers.
Clarity
It isn’t a coincidence that
Break It Down is also a slang phrase appearing in music and pop culture that also relates to our goals.
Urban Dictionary defines “Break It Down” to mean: To explain at length, clearly, and indisputably. By looking at the pieces of a larger whole individually and in more details we can often gain more clarity and understanding of the bigger picture than if we had never spent the extra effort.
Summary
Software Development is a continual exercise in dealing with variation of size and complexity. From early feature ideas, to low level code changes we have work that can be difficult to understand, manage, and predict, especially when it is large. Decomposition helps us make this work more manageable.
So, we need to remember to Break It Down. It is all about decomposition. And in software, decomposition is everywhere, yet so many struggle with recognizing the need and applying it well. I believe decomposition should be considered one of the most fundamental and critical skills in software development. Getting better at it takes a combination of discipline, practice, and learning but can pay off immensely.
To be effective, even this post required decomposition. We are going to continue with a series of posts exploring many of the individual types of variation in software and how lean/agile teams cope with these different situations.
Agile Velocity is pleased to announce the addition of Mark Spitzer to our team as an Agile Coach. Mark is a practicing Agile Coach and Software Craftsman. He believes in doing things right, doing the right things, and having the organizational courage to address tough issues. Having served as a principal engineer for many years, he is a strong advocate of software craftsmanship and clean coding.
