Re: Formalizing Scrum Chronicles #1
- --- In email@example.com, "tsteele3rt" <tsteele@3...>
>I believe we will find that this presentation technique is very
> What are the Formalizing Scrum Chronicles?
> The Formalizing Scrum Chronicles (FSC) will be a series of posts to
> the Scrum mailing list detailing my attempt at formally introducing
> Scrum to an organization/team. My main goal for these posts is to
> share my experiences and observations. I am also interested in
> feedback and suggestions from members of this group.
effective -good call.
I have introduced Scrum in this manner before, hope my comments below
may lend some insight.
> My Background
> I have been an Agile advocate for several years, primarily focusing
> on XP. A few months back, I began investigating Scrum and
> I had been following more Scrum practices than XP practices. Iagree
> with the conventional understanding that Scrum and XP areScrum
> complimentary, but currently favor the lower entry barrier that
> Project Background
> Inspired by "stealth" Scrum discussed in Chapter 5 of Ken's second
> Scrum book, we are roughly following the Scrum approach without
> anyone knowing it. We are organizing the work on our project around
> monthly releases (Sprint). Initial release work is planned as a
> (Sprint Planning), with our manager (Product Owner) prioritizingwhat
> he would like to see us accomplish (Product Backlog). We conductWho is present at the Daily Scrum? Who facilitates it? Who
> daily meetings with the project team (Daily Scrum) and demonstrate
> new features to stakeholders prior to release (Sprint Review).
> Things are going pretty well, so why try to "formalize" things? My
> reasons include:
> 1) Despite my example, our Daily Scrums are far from optimal.
participates and who observes?
My experience often is that it may take a team a couple weeks to
implicitly realize that these are not micro-management sessions.
If that is a similar source of resistance for you, one approach that
works for me is sort of sacrificing myself for the team(in their
eyes); helping them understand that above anything else, I only want
it to be made known initially what is impeding them from our shared
To establish this buy-in, our initial stand-ups are no more than
quickly probing each participant's obstacles to progress, always with
our goal and decomposed tasks as a visible focal point(this is key).
I immediately radiate any raised roadblocks and spend the rest of the
day knockin' em down.
This is different than most software teams operate, developers are not
used to management serving them and allowing them to focus on high
value activities that provide more instant feedback.
Sooner than later the team understands this and we gradually build a
> 2) The Product Owner continually interrupts the team during aSprint
> with "fire drill" work.You indicated the product owner is your manager, how does he represent
the business needs?
When a 'fire drill task' is imposed, ask this 'product owner' how this
satisfies customer expectations vs. the other work that has been
identified. Then ask him if there is someone more closely associated
from the customer (or a novel idea, a real customer stakeholder), that
can help clarify your priorities.
> 3) The team will be expanding in the New Year, and I think a morethe
> formal description of what we are trying to accomplish could help
> transition.A colloaborative cross functional team, some of which will be new, is
great opportunity to discuss your guiding framework.
I prefer to focus on communicating core principles, why their
important, and only then getting into specific practices.
> 4) While the Scrum Team plans work collectively and meets daily,What sort of feedback do the stakeholders provide at your reviews?
> there does not seem to be commitment.
How is this different from what the team has experienced before?
Is the team 'assigned' tasks by the manager, or do they understand a
goal expressed by a stakeholder and are empowered to creatively pursue
Iterative retrospectives also are important to learn and uncover new
opportunities that the team can co-create for improvements.
> 5) I maintain a private Product Backlog based on conversations withYou indicated the product owner is your manager, how does he represent
> the Product Owner.
the business needs?
Consider publishing the backlog on a shared server and encouraging
entire team maintenance.
Bring it to planning meeting and emphasize prioritization from a
> 6) Only two of the team members maintain the Sprint Backlog.I'm presuming you mean in terms of maintaining burn-down/up status.
Ask the stakeholers and management if having awareness of work
remaining to satisfy a goal is a priority for them.
Probe them entire team in an iterative retrospective on their
perceived value of this, and velocity overall. Acknowledge the two
team members in your stand-ups.
How different is this from what you did in the past?
> Please feel free to comment and look for the next installment ofthe
> Formalizing Scrum Chronicles.
MessageWe added a Scrum Experiences forum (for chronicles, experience and results) to ScrumForums.comFor anyone not familiar with it, there is a similar thing on the theory of constraints at Goldratt's site. See: http://toc-goldratt.com/index.php?cont=2Hope it's useful.- Michael