Difference between revisions of "One service deserves another"

From Pearl Language
Jump to navigation Jump to search
(Forces++)
m (Content++)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Oyster
{{Oyster
|goal=fairly help each other out when needed
|stage=Sparkle
|stage=Sparkle
|theme=Agile, Lean, Scrum
|theme=Agile, Lean, Scrum
|context=you are analyzing, refining and ‘cracking’ {{p|epic}}s in order to make them {{p|ready to build}}. Just before you pulled it through {{p|ready to analyze}}, the realization {{p|squad}} is already selected. Next, you discover that changes need to be made in systems that are covered by other {{p|squad}}s. Besides, your {{p|squad}} lacks the expertise and skills to make the change. Your {{p|squad}} has made the item {{p|ready to build}} for the other {{p|squad}}.
|context=you are analyzing, refining and ‘cracking’ {{p|epic}}s in order to make them {{p|ready to build}}. Just before you pulled it through {{p|ready to analyze}}, the realization {{p|squad}} is already selected. Next, you discover that changes need to be made in systems that are covered by other {{p|squad}}s. Besides, your {{p|squad}} lacks the expertise and skills to make the change. Your {{p|squad}} has made the item {{p|ready to build}} for the other {{p|squad}}.
|wish in a single line=How do you decide if and when an item—for which your squad neither have the time or skills—gets pulled in by another squad?
|wish=How do you decide if and when an item—for which your squad neither have the time or skills—gets pulled in by another squad?
|therefore in a single line=Have the product owner crew decide which build squad will pull this item into their sprint backlog.
|so=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 full=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|Whoever carries the risk, decides}}.
|background=Key Principle: {{principle|Whoever carries the risk, decides}}.


Line 14: Line 15:


Including the item in the {{p|sprint backlog}} is just in time, at the latest responsible moment.
Including the item in the {{p|sprint backlog}} is just in time, at the latest responsible moment.
|therefore=Have the {{p|product owner crew}} decide which {{p|squad}}—willing and able—should pull the item into their {{p|sprint backlog}}.
 
{{NB}}Actually, it is even simpler than that: '''Any and all requests that affect the {{p|product backlog}} or the {{p|sprint}} must go through the {{p|product owner}}''', no exception, as it affects planning. {{p|product owner}} performs {{p|triage}} on each request and decides when it is due: never, some time, later, soon, now (i.e. next {{p|sprint}}), emergency (i.e. disrupts current {{p|sprint}}.
|therefore full=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}} 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. {{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}} 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. {{p|product owner}}s need to help each other out. One service deserves another.
Consider having subject matter experts do a {{p|knowledge injection}} into the dependent {{p|squad}} If this happens structurally rather than incidentally.





Latest revision as of 08:59, 16 June 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.

✣  ✣  ✣

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.


✣  ✣  ✣