Who decides what to do?
This element may appear to be the same as the Project Selection element and for small teams there may be little difference. Project Selection is focused on choosing projects with durations measured in months or years, and is driven by people higher up in an organization in large companies, whereas this element focuses on the decisions developers make each day about where to spend their time. In some large organizations, a project is selected and given to a development team and the company personnel that selected the project are involved very little until they receive notification that the project is complete. In other organizations, the people that choose the project to work on join the team daily to help decide what tasks each developer works on each day. Some organizations let their developers decide what to spend their time on each day, even when that may mean the developer chooses to attend training, refactor some architecture, or fix some bugs instead of working on the project to which they are assigned. Other organizations don’t trust their developers to do what is most valuable and thus provide directives daily to each individual. This lack of trust is not always merited, but sometimes it is. A lack of trust in developers is an organizational problem, and a problem in the developer culture. For most teams, it is best to allow the developers to decide what is most valuable to work on because they understand the software and its needs the best. However, this is probably not the case for junior developers on the team, or team members new to the company or software solution. Until developers have time to learn the business domain of the software and how it is delivered, guidance about where they focus their time regularly is probably wise.
The people involved in developing the software have different knowledge and perspectives. Many will assign more importance to things they understand well. A business owner is more likely to prioritize the features most demanded, or to fix the user experience problems that are most pressing. A coder is most likely to prioritize changes that reduce the number of bugs or decrease their impact. An architect is more likely to stress the need to evolve the solution to meet future requirements with less cost. A person in the role of product manager, which could be a business owner, developer, architect, project manager, or other, is the person that can objectively consider the tradeoffs of all perspectives and select tasks that are best for the product. Many teams are business focused or coder focused, ignoring the impact of the other perspectives. However, a product owner perspective is only best for ‘products’, which are software solutions intended to be used a long time that probably will have additional changes and likely involve input and display of changing data. A project focus, used for initial prototypes, solutions with a short usage period, and that are very low maintenance once deployed, should use a project management, not product management perspective.
When less valuable tasks are chosen, the team is creating waste in the form of ‘value not produced’ that could have been.
Decisions need to be made frequently and by those that know the work best to avoid time being wasted. Producing a software feature, at the same time as developing a software product, at the same time as making improvements to development processes, at the same time as trying to improve DevOps, requires the ability to consider dozens of factors about the most valuable use of time of team members. That decision should not fall to a product owner, or a project manager, or a Scrum master, or individual developer. Ideally stakeholders can work together to guide decisions, otherwise a team can become unbalanced. For example, they may focus on just delivering features as fast as they can, when they could eventually deliver them faster if they took time for automating builds, taking a few days for training, or fixing some bugs that consistently consume time. Conversely, a development team may seek to build the optimal framework and devops automation prior to delivering many features and may waste a lot of valuable time building robustness that is vastly under-utilized.