Difference between revisions of "One service deserves another"

From Pearl Language
Jump to navigation Jump to search
(Zeroth version.)
 
m (Typo.)
Line 6: Line 6:
|therefore in a single line=Have the product owner crew decide which build squad will pull this item into their sprint backlog.
|therefore in a single line=Have the product owner crew decide which build squad will pull this item into their sprint backlog.
|wish=You want to get work done, in time, by another {{p|squad}}. How do you decide if and when this item will be picked up by the other {{p|squad}}?
|wish=You want to get work done, in time, by another {{p|squad}}. How do you decide if and when this item will be picked up by the other {{p|squad}}?
|background=Key Principle: {{principle|The one who carries the risk, decides}}.
|background=Key Principle: {{principle|Whoever carries the risk, decides}}.
|therefore=Have the {{p|product owner crew}} decide which {{p|squad}}—willing and able—should pull the item into their {{p|sprint backlog}}.
|therefore=Have the {{p|product owner crew}} decide which {{p|squad}}—willing and able—should pull the item into their {{p|sprint backlog}}.
|new=The {{p|product owner}} in need of the item needs to persuade the other {{p|product owner}}s to include it in the backlog (in the appropriate order)—have the others '''buy in''' to the item. If needed, {{p|product owner}}s may track work done for other {{p|squad}}s in order to reasonable balance this. {{p|product owner}}s need to help each other out. One service deserves another.
|new=The {{p|product owner}} in need of the item needs to persuade the other {{p|product owner}}s to include it in the backlog (in the appropriate order)—have the others '''buy in''' to the item. If needed, {{p|product owner}}s may track work done for other {{p|squad}}s in order to reasonable balance this. {{p|product owner}}s need to help each other out. One service deserves another.
Line 20: Line 20:


{{Source
{{Source
|author=Martien van Steenbergen,  
|author=Martien van Steenbergen,
|coder={{mvs}}
|coder={{mvs}}
}}
}}

Revision as of 14:36, 18 April 2013

…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: Whoever 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?|]]