One service deserves another
…you are analyzing, refining and ‘cracking’ epics in order to make them ready to build. Just before you pulled it through ready to analyze, the realization squad is already selected. Next, you discover that changes need to be made in systems that are covered by other squads. Besides, your squad lacks the expertise and skills to make the change. Your squad has made the item ready to build for the other squad.
✣ ✣ ✣
You want to get work done, in time, by another squad. How do you decide if and when this item will be picked up by the other squad?
Key Principle: Whoever carries the risk, decides.
Forces:
- Having a squad taking responsibility for all activities—need analysis, interaction design, analysis, design, architect, develop, test, and deploy—gives a sense of belonging, and is satisfying.
- Sometimes the current organizational structure forces working on items that later need to be transferred to more suitable squads.
- Assigning an item to a squad too early reduces flexibility, and increases potential dependencies, and triggers just the problem one service deserves another addresses.
Including the item in the sprint backlog is just in time, at the latest responsible moment.
- NOTA BENE—Actually, it is even simpler than that: Any and all requests that affect the product backlog or the sprint must go through the product owner, no exception, as it affects planning. product owner performs triage on each request and decides when it is due: never, some time, later, soon, now (i.e. next sprint), emergency (i.e. disrupts current sprint.
Therefore:
Have the product owner crew decide which squad—willing and able—should pull the item into their sprint backlog.
✣ ✣ ✣
The product owner in need of the item needs to persuade the other product owner to include it in the backlog—have the other buy in to the item. Optionally, track work done for each other in order to reasonable balance this. product owners need to help each other out. One service deserves another.
Consider having subject matter experts do a knowledge injection into the dependent squad If this happens structurally rather than incidentally.
You can avoid this situation by decoupling the refining and building states, since, during refining, you will find out which squad is most suitable to build it.
A more profound way that spreads knowledge, fosters autonomy, reduces dependancies, and increases resilience is to adopt the principle: anyone is allowed to change anything, anywhere, anytime, as it:
- educes collaboration and communication between squads and its members, as well as professionalism and autonomy (thus reducing dependancies); and
- requires the expert squad to do a knowledge injection, and train the lay squad so it becomes competent to implement the item themselves.
✣ ✣ ✣