Just like the effective salesperson is the one closing the sales, effective engineers and managers in our industry are the ones that can deliver business value. Deliver without ", but", deliver without TODOs, without creating a mess and without putting dust under the carpet.

I will describe what I mean by "closing" in software development and why I think it is a very valuable and practical principle to follow.

The opposite of closing

Let's start from the opposite side and take a look at a few examples of behaviour I am sure everybody can relate to.

• Probably you worked with an analyst or product owner who often argues that additional requirements shall be part of next release after the scope has already been fixed. He may extend user stories after they have been developed. He tries to fix UX problems before users even have a chance to touch the product. He may tolerate but does not accept the idea of iterative development.

• You may know or work with managers who almost always say yes to a neat idea, but initial enthusiasm is rarely followed with any plan of action, not even mentioning successful implementation.

• Almost every larger project I saw have a huge backlog with hundreds of old user stories that nobody will ever consider for the upcoming sprints. Same goes for piles of TODOs scattered around the code, doomed to be forgotten, but still adding complexity.

• Developers that have an unbearable number of topics "open". The most pathological example I saw was a guy with tens of open issues in the tracker. There was no way to tell what this person was working on.

I can extend the list even more but I think you get the idea by now. Even though the behaviours I just described are from different branches and one may think they have nothing to do with other, I suggest that there is one underlying principle.

Those kinds of behaviour emerge when people, for some reason, can't mentally close topics they started in the past. They cannot accept that "later means never" and "there is no trying". I think it is caused by that tempting feeling of hope that "in the future" we will have some free time and we will fix the problem at hand. So, just in case, we keep that "TODO: design to be improved" comment that week from now, nobody will remember what was about. Just in case, we keep backlog with years of work, when we are not even sure if the project will last 6 more months.

Unfortunately, reality does not care about our hopes and dreams. I have yet to see a phase in the project when the team would have some "free time" to fix TODOs. Your neat idea from last week, if not aggressively pursued will perish under the road roller of new more important work items.

Better alternative: closing mindset

People are ridiculously bad at remembering stuff, especially in the complex and ever-changing field of software development. Therefore, we need to work in such a way that leaves minimal (even better nothing) amount of information to remember. Every time we have something "open" it takes our brain capacity and prevents us from focusing.

The closing mindset I advocate here means being realistic about ourselves and give up unfounded hope for "better" times. Either I am committed to the issue at hand and develop a plan to implement it immediately or not. In the latter case, we still need to apply closing mindset and either forget about the issue(remove user story, delete the todo etc.) or schedule plan to review the issue with a deadline.

Let's see how "closing" mindset works in examples:

• During sprint planning, product owner sees that one of the user stories is not groomed enough, there are many questions regarding business impact or implementation details. He immediately says "put that out of the sprint", which immediately shuts down unnecessary discussion and sends clear message that only well understood can be committed to. Developers feel respected and can commit to other well-specified user stories for that particular iteration.

• During code review, the developer finds out few TODOs left by a fellow colleague. She refuses to accept those and suggests either to remove them or add appropriate entries to the issue tracker, which can be later prioritized. The fellow developer, fixes one of the TODOs immediately, because it was really important but removes the others, which were not worth the effort. Code stays clean, and trust between developer is maintained.

• During the implementation phase of the iteration, the business analyst discovers that one user story could be improved by using some other user interface approach. He asks the developer directly if he can implement it on time. Developer kindly responds that it was not what the team committed to and asks the product owner to choose one of the alternatives. Either kill the sprint and start a new one or carry on with previous design and prioritize new idea for next iteration. Management does not want to disrupt developers and carries on with the sprint. During the next sprint planning, it turned out that there are many other more important user stories and proposed improvement was never implemented. Development time was saved and the team stayed on track to deliver the final product.

These are just a few examples of situations that happen all the time in real projects. By following the "closing" mindset we are gaining lots of advantages.

How exactly it helps?

• Builds trust. How can I trust that a developer is going to deliver when I can see tons of open issues he/she left in the past? How can you trust a manager that raises your hopes and promises to apply some changes for the better, but then forgets about them? Answer "yes" to few questions, but then commit 100% to them. If for some reason you need to back up from the promise, do that in the spirit of self-responsibility and explicitly close the topic.

• Encourages focus. Having a minimal number of clearly defined goals is a huge performance boost. Some distractions, like TODOs scattered here and there are relatively small, while others like extending the scope of user story during sprints are devastating. All of them, however, degrade performance and morale of the team.

• Maintains alignment between various stakeholders. Just think about the clarity that short backlog brings to the table. Anyone can take a look and instantly know the priorities of the project in a given point of time.

• Keeps morale high. Completing a successful iteration is one of the most gratifying moment for the development team. After a few successful sprints teams seem to get into the habit of "winning" which is huge in terms of team-bonding. However, this can be easily disrupted by constantly changing goals or leaving some work behind, for "later". Managers often are not aware of how much does overall mess demoralize developers.