Agile 2006 Conference – Day 2 Report

Sessions I Attended

KEYNOTE, Peter Coffee, Technology Editor of eWeek Magazine

The
keynote address was delivered by Peter Coffee, Technology Editor of eWeek magazine, and
was effectively a list of books that we should read with some observations thrown
in that were implied to be gleaned from the books being mentioned.

Although delivered in monotone, I was able to capture these pearls before I decided
to go find coffee.

Disaster potential goes up with the square of communication time
Each level of management reduces communication effectiveness by 25%
Computers just speed up the mess
Feedback is not useful unless the system changes as a result of the new input (I disagree,
by the way)

THE ROLE OF CUSTOMER TEAM IN THE AGILE DEVELOPMENT, Dan Rasthorne of Net Objectives

Dan did a reasonable job of making the case for responsibilities inherent to the role
of the customer team, while also touching on some nuances of Scrum process as practiced
by, well, him.

Basically, he started an argument about whether or not each story card should have
a name on it identifying a StoryBoss (his term) who will be accountable for seeing
it to completion.  It was very productive .

Dan did finally assert that the responsibilities of the Customer Team to the rest
of the Product Development Team are as follows:

• Solidify the concept
• Drive the project at a sustainable pace
• Explain requirements to the team
• Validate product releases

Dan also shared the following table of success criteria from a study performed by
the Standish Group, which assign percentage points to factors influencing the successful
outcome of a software development project.  This is an amazing and not wholly
surprising table.

DEMONSTRATING RESPONSABILITY Christopher Avery

It was during this presentation that I began to feel good about actually coming to
the conference.  I won’t say that Chris Avery’s presentation made
the whole tuition fee worth it, but it did.

Instead of summarizing the session, I am going to simply copy and paste the first
few actual notes that I took in the session.

1.       Accountability
!= Responsibility

1.1.     Accounting
for miserable performance is not taking responsibility

2.       Accountability

2.1.     To
be held to account for a system of…

2.2.     Being
held to account is not up to you

2.3.     This
is external to you

2.4.     AMH
– Accountability Management Hierarchy

2.5.     Measurement
by a 3^rd party? PMO

3.       Responsibility

3.1.     A
feeling own ownership

3.2.     An
internal sense of what you are willing to do in order to influence an outcome

3.3.     An
observable mental process

3.3.1.  Language
and actions

3.4.     Not
a character trait, it is observable behavior

3.5.     Is
a skill

3.5.1.  Can
design direct curriculum

3.5.2.  The
army develops personal responsibility

3.5.2.1.  Consequences,
rewards ß indirect
teaching methods, like with the kids

3.5.3.  Can
be trained

3.6.     Satir’s
Change Model

3.6.1.  Virginia
Satir

3.7.     Change
introduces disorder

3.7.1.  People
begin failing to function well

4.       Agile
is the choice to integrate instead of isolate as a management tool

5.       People
don’t know what they want until they see it

6.       You
don’t get to see the difference you make on a team as you come or go

6.1.     How
do you know if the team was bad before you got there?

This is truly great stuff, and only tangentially related to Agile.  He was making
the case that Agile advocates are actually leaders taking responsibility.  He
then presented a framework within which you could work to further discipline your
personal responsibility.  I loved every minute. 

For more on Mr. Avery, see http://ChristopherAvery.com 

You can join me in aggregating him here: http://ChristopherAvery.com/blog

OVERALL, today was a much better day than yesterday.  All team
members reported actual learning, which is always good . 
I am beginning to form the opinion that this conference is better suited to organizational
technology leaders, Project Managers, and Development Team Manager types
rather than being immediately useful to individual contributors.  I am reserving
judgment for now, though.  We’ll see how tomorrow goes.