🚀 go-pugleaf

On Wed, 2018-07-25, Ahem A Rivet's Shot wrote:
> On 25 Jul 2018 09:54:23 GMT
> Jorgen Grahn <grahn...@snipabacken.se> wrote:
>
>> All those things can be done well or badly.  For example, back when I
>> was in a proper Scrum team, the Scrum Master was just another team
>> member, who also worked part-time as the team's secretary.  Planning
>> was Post-It notes on a whiteboard, and so on.
>
> 	Sure that's the usual when it's done properly - a variant (when
> there are many teams) is that scrum masters do nothing else but they do it
> for several teams.

I've been in that scenario, too.  I've no idea if it's kosher, but I
don't like it so much.  The scrum master tends to become more of a
manager, and the team feels less responsible for the scrum stuff.

My first scenario above was 4--5 teams, internal scrum masters, /and/
a guy called an "agile coach".  He helped us with scrum procedures,
and pointed out when we did something stupid, such as running for the
wrong goal.  He also helped resole conflicts in the team (conflicts
seem more common in agile teams).

> 	Even when done properly it can be quite an overhead - especially
> with short sprints. One PPOE we had one week sprints but out of that week
> the whole team would lose half a day on sprint planning and another half
> day on the sprint retrospective as well as five minutes a day in standups,
> also part of the team would lose another half day to backlog grooming and
> user story prep. So a five person team doing one week sprints only gets
> something like 19 person days (two people tied up in grooming and story
> polishing) to work in out of the 25 they started with - more than a 25%
> overhead.

I know what you mean; planning and retrospective can be frustrating.
Especially the time estimation -- although I can understand why
someone would want a believable prognosis.

> 	Longer sprints have much lower overhead but greater probability of
> management interference^W^Wpriority changes during the sprint.
>
> 	The sprint planning tends to be the silliest waste of time as
> everyone goes through the user stories and votes on the number of story
> points for each - typically only one or two people have a really good idea
> of the complexity involved (different people for each story of course) and
> the rest try and go with the flow and vote accordingly in the planning
> poker.

I partly agree (and if you catch me right after such a session, I'd
agree more!). But at least it's a chance to have all team members
"buy" the sprint as a whole and get a feeling for all its contents.

> After a few sprints the retrospective is also mostly a waste of time
> as people get more and more desperate to find "things to start doing",
> "things to stop doing", "things to do more of", "things to do less of" and
> "what went well" and "what went badly".

Perhaps the retrospective can be shortened when nothing exciting is
happening.

The saddest part is going through last sprint's issues and realizing
you haven't done anything about them ... or that all major problems
are outside the team's control.

On the other hand, you can get surprising insights in those sessions,
mostly about what your coworkers silently liked or hated during the
sprint.

> 	For most projects I prefer the continuous flow model of Kanban to
> the artificial pulse beat of sprint.

Personally, I cannot say. I like to have a deadline, but perhaps
Kanban gives you that.  I've been in Kanban-ish situations where noone
noticed if you slipped a week or month, and paradoxically I found that
more stressful -- the nagging suspicion that you were always late.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .