No subject

The team has a brief "sprint meeting" every morning and each member reports the following:  What I did yesterday (the preceding work day); what I plan to do today; and what impediments I face.  Then they go back to work, and the project managers are forbidden to distract them.  We also update a wiki each morning (if we're on the ball) so most questions are answered before the sprint meeting.  On any given day, the wiki only reports for that day; it doesn't retain a bunch of boring history.  An entry from the boss also notes our current target dates and goals.  All this tends to be quite terse, just the facts.

One thing I enjoy in the literature is that, in the daily sprint meeting, participants are classified as pigs and chickens.  You know the old bacon and eggs thing:  The chickens are "involved", but the pigs are "committed".  Only the pigs are allowed to talk:  the chickens are seen, but not heard.  If they don't like what they hear, they can take it up with our manager, who will do any necessary load-balancing to keep things moving.

We don't really use XP.  We're not pair-programming, except when there's a problem that needs some extra brainstorming resource.  Mostly we each work on a specialized piece and coordinate on design, interface and test issues.  The manager can adjust personal priorities on a daily basis, to add leverage if someone's in a jam.

One principle that's supposedly part of our approach is test-first programming.  If we are fixing a defect, we should have a test case set up to reproduce the defect ahead of time, so that we can use the same test later to demonstrate that the problem is corrected.  In some cases reproducing the problem is not possible, and we have to use a unit test, or even a special module-level test, rather than an integrated system test.  We also work with QA to ensure at least a good, relevant regression test at the system level.

At the end of each sprint, we're supposed to have a released product with all the new stuff in it, even if some of it is not yet enabled.  So we have a single active code base at all times, avoiding risky and distracting branch management.  The result *will* go into production for all customers.  If there are unintended consequences, hopefully they will show up soon enough that the developers will remember what it was all about!

You probably know of cases where developers have spent years to produce a whole new product, and when it comes out it turns out to be irrelevant.  The piece-wise release means that the customers get to see new features appearing incrementally, and will let us know if we've strayed off the track due to miscommunication, or because the use cases were flawed or incomplete, or just because what seemed like a good idea turned out to stink in practice.

Disclaimer #1:  Any of the above rules will, on occasion, be broken.  But enough of them are followed at any given moment to avoid a lot of bureaucratic inertia, time wasted in meetings, jerking around of developers, delivery of the wrong thing, silver bullet syndrome, etc.  The stated rules provide a baseline from which exceptions can be dealt with.  While a purist may find a lot to pick at, I think it has been a very positive approach.

Disclaimer #2:  My involvement in scrum is partial, because I spend most of my time in internal support, special projects and little firefighting tasks which are usually outside the main flow of development.

I can't make next Thursday's meeting, but it sounds interesting.  Good luck with the discussion.

Vic

---- Alan Dayley <alandd at consultpros.com> wrote: 

=============
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

After hearing some netcasts and watching some of the "TechTalks" on
Google video, I am becoming very interested in Scrum.
(http://en.wikipedia.org/wiki/Scrum_%28development%29)

Aside from the videos I have also found some good documentation and
presentations from various sources.  While I feel like I am learning
much, I have no practical application experience.

So, who here uses scrum?  What is good?  What is bad?

I am willing to drive a discussion of the topic at the January 4th Devel
Meeting next week, unless someone else has another topic they'd like to
present.  It'd be good to have people who use it present in the discussion.

Alan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFlucuDQw/VSQuFZYRArUIAJ9Ur784HQVmIuwNHNa+apNW57sksgCdFqFM
xI2UO6uPhQ577AhZvdewB0k=
=Vjpy
-----END PGP SIGNATURE-----
_______________________________________________
PLUG-devel mailing list  -  PLUG-devel at lists.PLUG.phoenix.az.us
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel