ASK Jeff Gothelf

#1

1200x630-1DQCPLG
1200x630-1DQCPLG.png1200Ă—630 485 KB

Please use this topic thread to post your questions directly to Jeff Gothelf! Jeff will be answering YOUR questions September 24-28th 2018.

#2

Hi Jeff,

Can you describe the day in the life of a brand new, never done this before Product Owner who is grappling with the enormity of the task. Putting first things first, where would you tell them to start? How do they work with the designers they may have to produce product that works?

#3

Hi Jeff,

Can you suggest some tactics for weaning an organisation off a project-based approach to change (including funding and resourcing), and to move to more of a product-based approach?

#4

start with the problem they need to solve. why are they undertaking this task? then, decide how you’ll measure success in terms of customer behavior. then brainstorm with the team ways to achieve those outcomes and run experiments to de-risk the high risk/high value ideas.

#5

post mortems of previous efforts that tried to be predictive but didn’t hit the mark is one place to start. another is to timebox an experiment for this new way of working. run one small team working towards outcomes for 3 months and have them report back on how productive they were, what they did, what they learned and whether they think this can and should scale in the org.

#6

Hi Jeff,

I’m a scrum master. Me and my teams have been hit lately with a lot of production bugs from the last release. I’m working on reducing that number in the next release, but right now I’m getting “drop-what-you-are-doing and fix these” orders that I can’t ignore. I’m thinking of running a separate Kanban board and a separate planning meeting for these still coming bugs. That way I can measure the bugs and the scrum work separately and the team can better organize the work while maybe hitting our sprint goals. Do you think this is wise and do you have any other suggestions?

Thanks in advance!

#7

Whilst I’m not not Jeff, I’ve seen this happen.

One of the things I’d advocate is making things visible. If you aren’t having reviews with the people that are injecting work, start there. In his book, Scrum Shortcuts without Cutting Corners, Ilan Goldstein suggests capturing a number of metrics for team’s work that can be revealed at the review.

  • Injection (work forced into the sprint)
  • Deviation (blowout from a story getting out of control)
  • Distraction (planned/known work that occurs during, but apart from the sprint)
  • Interference (unplanned/unknown work that occurs during, but apart from the sprint)

Separate to the above, I’d suggest a General Life clause as well, for sickness, leave and other things that can’t be controlled for in the above.

Like many things, you aren’t worried so much about the one-offs, but patterns that occur over time. If injected work is affecting sprint forecasts and goals, identify it and make it clear the impacts that it is having.

If you are getting many bugs at Severity One, maybe investment into technical practice or automation might be needed, perhaps you have acquired too much tech debt and spike needs to be planned to identify improvements and explained properly to the PO and/or stakeholders. OR maybe they aren’t all severity ones and can come into following sprints.

Finally, I’ve seen the practice of having a Batman/woman being assigned to bug-work work well, where 1 person has that as a focus and their capacity isn’t taken into consideration for sprint planning. If doing this though, it is important the role shift around and not be given to the same person every sprint.

Hope that helps.

#8

Thank you, Brad Stokes. That is helpful and somewhat what I was thinking but taken beyond, which is why it is helpful. They are, indeed, Severity Ones and a threat (or in Agile Speak, anti-value) pattern. I expect them to go down over time, but still high risk (unknown unknowns). I should discount the capacity of the Batmen/women that the team has decided to handle them and adjust the sprint goals accordingly.

#9

I’d say leave the current sprint in tact. Reveal the reason for not hitting the forecast and then adjust accordingly for subsequent sprints.