Friday, April 22, 2016

What I Wish My Training Had Covered

In proposing this session, I had expected most of the feedback might be about things Scrum Masters or Product Owners had encountered as problems/issues and would have wanted some "heads up" about in the training.  You'll see below what actually was raised.  Some comments of mine to provide more context are in brackets - "[ ]":

Would have liked more on

Diverse (culturally) and distributed teams.

Project tracking techniques, KPIs

Keeping teams engaged [after they've been through a number of Sprints]

How to coach Product Owners

Shouldn't there be a Scrum "team" certification [everyone who wants any sort of Scrum training just has SM, PO, and a 5-day developer course to hope covers the topic]

What's the Scrum master sphere of influence, how to get teams to grow

Managing one's own personal change (and help others do the same)

[What to do about teams feeling that there are] Too many meetings

Maintaining morale [team]

Coaching team members

Training seems to teach the "target state," but not how to get there

What could be "compromised" to get things started

What not to do [i.e., dysfunctions to avoid]

And toward the end of the session, Peter Stevens asked the group "What is causing you pain?" to which he got the following comments:

*Servant* not needed [i.e., teams feeling that, after a while, they "know" Scrum and don't need the Scrum Master perhaps because] the "Pressure is off when they got the basics right".

Lack of cohesion between silos (most of the work is between the silos)

What's the next step? No career path [and this seemed to be to be suggested by many of the prior comments above]

Lot of change in management [i.e., having to "(re)educate" a new set of management]

My SM has no SM training [right, management picked a Scrum Master who had never had any formal training and did not indicate they would need it]

Spillover [the prior session to this discussed the problems of teams not finishing work and having it spill over into the next Sprint]

[Management or POs feeling teams should] Do defects in your over[/own] time, misconceptions about story points [, saying defects should be worth '0' points, viewing points something like a scoring system you "get credit" for, hence no credit for defects]

Useful tools? {and someone suggested the] Spotify health check

How do you validate that what you did yesterday really works?  [Something I have taught in my class as a daily, individual "retrospective" on one's own accomplishments for the day.]

No comments:

Post a Comment