Re: tonight's Agile talk

On 7/21/2010 9:18 AM, Jared Richardson wrote:
> For those of us who missed it, can someone summarize? I would've loved to
> have been there.
>
> Jared

Hopefully Jeff can share his slides with Manon so she can put them on
the web site. (webmaster at trijug dot org is the right email address)

But, in the meantime, "here goes nothing."

I missed the first few minutes because of administrivia, but I assume
Jeff set the context within which Agile came about. I'll have to leave
it to somebody else to provide a more complete, time-ordered summary.
All I can do is offer a hand full of memories passed through the filter
of my own bias. Apologies in advance.

1) (Opening remarks, context and where scrum came from)

2) Scrum replaces the waterfall model with one that attempts to minimize
wasted effort while maximizing customer-centric development efficiency.
It folds some parts of the waterfall model into an iterative
process with relatively many relatively short iterations.
3) Scrum dictates decomposition of problems into relatively small tasks
("stories") that are rapidly completed and that result in well tested,
customer usable software components that "properly tell the story".
Continuous integration (or nearly so) was implied. Very clear
criteria for whether or not the story has been properly told is a
requirement.
4) Scrum teams are small (4-7) and work during one or more short (2-3
week) periods called "sprints" that result in demonstrations of that
period's deliverables. Sprints typically imply a management commitment
to the team remaining stable until the sprint is completed, that is wrt
being pulled off into other work or otherwise reassigned, etc.
5) Projects are composed of multiple sprints and projects larger than
some limit are done by multiple Scrum teams in concert, but team
coordination was beyond the scope of the talk.
6) Scrum team member roles vary from mostly specialized (product owner)
to general but senior/lead (scrum master) to highly general (developers
who are architects/coders/test writers/testers/customer-facing
requirements gatherers and deliverable demonstrators/technical writers/etc).
7) Scrum puts sharp constraints on meetings overall while requiring
short daily meetings throughout sprints to establish who's done what,
who's expecting to do what next, and what is impeding progress. The
scrum team attempts to make daily meetings highly effective while also
putting a hard time limit in place (e.g. 15 minutes), after which team
members are free to stay or go back to work as they see fit.
8) Both "story development" activities and end of sprint demonstrations
offer well defined opportunities for customer contact.
9) Prioritizing scrum tasks that have estimated completion times and
resource requirements, keeping track of actual completion times (and how
many tasks , and reducing estimation error work together to increase
productivity ("velocity of backlog burndown" in scrum-speak, if I recall
correctly) as well as estimate precision and customer satisfaction.

  Aspects of Scrum were described in black and white and some of the
attendees initially could not make the mapping to their "reality is too
often a shade of gray" experiences. In particular, the notion that
stories are completed in one sprint cycle such that the customer can
treat the resulting software as production quality to the point of
becoming dependent on its functional spec remaining stable from that
point on was hard for some of us to swallow, especially for cases where
initial sprints provide insufficient experience to avoid design changes
that break backward compatibility.
  I'll close with my personal translation of a few relevant attendee
remarks that come to mind.

  "There are all kinds of customers, and (for example) feature
withdrawal has different implications for the 'peer dev group customer'
vs the 'end user customer', to name the two extremes."
  "Proper decomposition into relatively independent stories is key."
  "If there is a bad surprise the customer finds out faster than with
traditional dev processes."
  "No matter what is being claimed (my experience dictates
that) there is the 'sprint release' and then there is the 'product
release' and this implies a weaker customer contract for the former."
  "Prototyping can be a scrum story, the stories can be either/or
choices, and they can be created in parallel."

  (And from somebody after the meeting: "Everything is negotiable, no
matter what anybody tells you.")

And here's a scenario that Scrum is aiming to avoid:
http://www.businessballs.com/treeswing.htm :-)

-Pete