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.
✣ ✣ ✣
{{{wish full}}}
Key Principle: The one who carries the risk, decides.
Therefore:
{{{therefore full}}}
✣ ✣ ✣
The product owner in need of the item needs to persuade the other product owners to include it in the backlog (in the appropriate order)—have the others buy in to the item. If needed, product owners may track work done for other squads in order to reasonable balance this. product owners need to help each other out. One service deserves another.
Note that including the item in the sprint backlog is just in time. Assigning it to a squad earlier will trigger just the problem on service deserves another addresses.
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.
✣ ✣ ✣
[[wish::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?|]]