This Real Kanban Question is based on a Twitter conversation with @ThinkBA.
One set of answers (David’s) assumes the existence or creation of a process step for assessing architectural impact:
- Make sure that this step is reflected in the team’s kanban system
- Have policies for feeding back on items whose impact is determined to exceed tolerance
- Refine these policies by making them specific to a class of service, allowing (for example) non-urgent items to have greater impact than urgent ones without the need for some special decision making process
- Have a class of service for items expected to be high impact (platform improvements, say) and reserve some capacity for these so that they are analysed in good time
But what if that assumption doesn’t hold (or can’t be made to hold cheaply)?
“How does the team know?” is a “smell”, meaning that there may be a dysfunction to sniff out here! It begs a number of questions:
- Why doesn’t the team know?
- What are the architectural concerns that the team wishes the customers to take into account?
- Are there perhaps architecturally significant pieces of work that the team is anxious to get prioritised? And failing to?
- Armed with better information, would the customer make better choices (better for all concerned)?
In other words, the question implies to me that the customer and team are insufficiently aware of each other’s concerns and priorities, indicating that collaboration doesn’t feature enough in work selection and (moreover) risk management.
Let’s return to the key paragraph of question #1 (interestingly, another “how do we know?” question):
One very cool but rarely discussed effect of limiting work in progress (WIP) with Kanban is that it pushes choice back upstream. Or to put this the other way round: too much WIP and the prioritisation and risk management problem is sucked into the development team. Horrible! Better to keep it where it belongs: in a partnership between the team and its key stakeholders. Getting this right goes a long way towards neutralising the value question; difficulty here likely reflects broader problems in the organisation.
The opposite of “sucking the risk management problem into the development team” is “creating opportunity for collaborative risk management upstream”. The more informed the customer’s choices, the better those choices will be, to the benefit of both customer and team. Win!
Do you have a Real Kanban Question?
