Software developers are responsible for carrying out tasks from a product backlog for delivering increments of value in a regular manner. The mindset we adopt towards work can have a direct impact in the quality and speed of our output. In this article I briefly discuss how adopting a “consultant mindset” internally within your company can help improve the product development workflow.
Backlog Refinement
In an ideal world software developers would only work on tasks from a perfectly refined product backlog. Tasks requirements, user stories, user flows, interface designs, edge cases, etc would be thoroughly detailed, allowing for maximum productivity during development since all required information would be easy to access and readily available.
In practice this is seldom the case. Backlog refinement is an important but often underattended process. Below I provide a usual definition of what it is:
Backlog refinement is the ongoing process of reviewing product backlog items and checking that they are appropriately prepared and ordered in a way that makes them clear and executable for teams once they are planned for development
It can be regarded as a specification process somewhat perpendicular to the software development process, i.e., backlog refinement is driven by the product vision, fit to technical constraints and performed concurrently and in anticipation of development:
Typical signs of a deficient product backlog are:
- Lack of user stories detailing what a feature should do
- Missing interface designs defining what a feature should look like
- Absence of relevant non-functional requirements (ex: performance, technology stack, etc)
- Variability of feature requirements
In the absence of information developers are faced with two choices, either halt development and switch to another task, or work to fill in the gaps themselves to make the task completion feasible. This latter approach can be dangerous if not handled properly, since strategic product decisions could be left open and done on the fly without oversight.
Here enters the consultant mindset, which I propose as a solution to mitigate the risks posed by insufficiently refined backlog items and improve development productivity.
The Consultant Mindset
A consultant-minded developer is expected to work collaboratively within the organization taking part not only of a software project’s technical scope, but also getting involved in its business scope as well. He/she is genuinely interested in helping people understand problems and solve them, acting as more than merely an executor of technical tasks.
Larger organizations usually have the resources to build fully featured specialized business and technical teams. A deficient product backlog in this case will most likely be the result of problematic internal processes or underperforming professionals.
However, medium and small organizations, specially early stage startups, may not have the resources to maintain these fully featured teams, and team members are often required to hold multiple responsibilities, of both business and technical scopes.
In this context consultant-minded developers are most valuable. Put simply, they are software developers that take backlog items to work on and double check they i) capture business value, ii) have clear acceptance criteria and iii) are technically feasible before starting development.
Upon finding specification issues with the task at hand they actively collaborate with stakeholders seeking more information to understand their perspective, giving expert technical and user experience design advice, which (most) developers naturally acquire over the years working in different projects, and proposing practical solutions for moving forward.
Agile software development frameworks (ex: Scrum) dictates that developers should be shielded from external influences and interruptions as to leverage their productivity. While this is true, it doesn’t mean the development team should be isolated in a silo prevented from reaching out stakeholders when needed, internal or external ones, in the context of backlog items to clear the path for development. As a bonus software developers employing this mindset will grow their vision of the product and potentially perceive their work as more useful and meaningful.
Finally, this simple proactive behavior promotes a culture of action and an environment of open and transparent collaboration beneficial to the company, and even if the motivation for proposing it comes from a scenario of a deficient product backlog, I see no reason why it wouldn’t also add value in a scenario where product backlog refinement is performed appropriately.