Software development can be fast-paced. Backlogs can seem to be endless, and the need to ship something is ever-present. However, there is more to being agile than just constantly being busy. In fact, if you are always, busy you are missing opportunities. It may seem counter intuitive, but constantly working and pushing forward isn’t always the best course of action.
Agile Origins of Nothing
One of the key tenants of lean manufacturing is the ability to identify and map value. Anything that doesn’t align to the defined parameters of value constitutes waste and should be eliminated. In the same vein, a core principle in the agile manifesto is the idea of simplicity (see principle 10). You should be developing a solution that is simple and effective that delivers value. Anything outside of that simple scope is likely waste and should be avoided.
Often times, features can enlarge over time as you speak to more people, do more analysis, and think of new possibilities. But, rather than just adding on to the feature with more requirements, you need to reflect on what it is you are building. Is it simple? Does it only meet the need of the defined problem? Does this simplify a person’s job, or are you adding more work to the end user? If you answer no to any of these questions, then stop. Take a time out and review what you are adding to the backlog. It may make more sense to not add this feature or program this thing. In these instances, doing nothing will help you avoid mistakes of over doing something.
A Practical Example
In my line of work, I encounter these situations pretty regularly. I’ve worked for a number of different clients as a consultant and also as an in-house Business Analyst. Regardless of who I am work for and what industry they are in, the tendency to over-engineer a product is always present. In one feature collaboration session that I had with a product owner, UI/UX designer we encountered this situation. As we added on user stories to a feature we all began to feel an uneasiness of where this was going. Our session got to a point where we all had to ask, does this make sense anymore? Is this really solving a problem?
After an honest evaluation and assessment of the work we were possibly adding to the backlog, we unanimously decided not to add that feature. It was too complex. There were too many assumptions and the risk wasn’t worth it. This was the time where doing nothing was better than doing something wrong.
Agilist Recommendations
Since “shifting left” is all the rage as buzz words, I propose you also “shift left” your backlog refinement sessions. What I mean by this is that you should be critical to what you are adding to the backlog in the first place. Obviously don’t push back on everything. But, develop an innate feeling of uneasiness when things seem to be getting too large. When those feelings are present, then push back and really call into question the value of the feature.
If you are a product manager, another recommendation is getting comfortable with saying no. The more you say no, the better position the team will be to work on things and deliver more value. Time is a limited resource and as such, you need to keep that constraint in mind when adding things to the backlog. While the team is working a poorly fitting, giant feature A, they aren’t working on the limited scoped, but highly valuable feature B. Don’t make your backlog a list of busy-work items just for the sake of putting something out there. Be more intentional.
Finally, encourage collaboration. Sometimes you may not notice that something doesn’t really make sense. But, if you have a healthy team of peers looking into the features that are being added, and by healthy I mean people that aren’t afraid to ask questions, then leverage those people.
So, the next time you are pressed for doing something, maybe start by deciding what provides value by doing nothing.
If you found this helpful, please share with your colleagues, friends, boss, etc. Also, feel free to start reading my Agile Laws series here.
Thanks for reading!
Agile ↑
