Precision does not imply authority

I read a comment a while back about how a description had higher precision and therefore higher authority.

Precision implies nothing but precision.  Precision especially doesn't imply accuracy.  Believing that because something is described in greater detail, it should be considered more authoritative, is utter folly.

Colleen Barrett on leadership

Via Alexander Kjerulf,

Colleen Barrett, the former president of Southwest Airlines, speaks at a Knowledge@Wharton event:



She mentions the same viewpoint that Ishikawa has (though I don't know if that's where she got it from). In order of priority of focus:

1. Employees
2. Customers
3. Shareholders
   

Dijkstra on YAGNI

Via Douglas Crockford,

E.W. Dijkstra talks about "superfluous features" while reviewing the IBM 1620 Data Processing System:

Before going on I should like to explain why I may have objections to "superfluous features".  Suppose that a machine contains a certain feature and that I can show, for instance, that it is impossible to use it intelligently or that its use gives rise to undesirable programming conventions; suppose furthermore that the defender of the design agrees to my objections but defends the feature by pointing out that, if I do not like the feature, I do not need to use it, implying that no harm can be done by something "extra".  In that stage of the discussion I shall stress that the design would have been better without the feature under discussion.  If it is impossible to use it intelligently every effort to do so is spoilt and the programmer would have been better of without it.  If its use gives rise to undesirable programming conventions, also in that case the programmer had better ignore the feature completely.

There's also quite a funny line in the concluding remarks (emphasis mine):

As the reader will understand, my recent study of the IBM 1620 has been a shocking experience: I knew that it was a rather small machine but I had never suspected that it would embody so many basic blunders.  Personally, I cannot undergo such an experience without asking myself what its morals are.

Next SyXPAC meetup on the 23rd February 2009

For the Sydney readers...

The first formal SyXPAC event of 2009 will be on the 23rd of February at ThoughtWorks Sydney.

I'll be doing an Overview of XP / Agile for beginners (as well as a reminder to the rest) while Dave Newman will be doing an Introduction to SOLID Design Principles so that you can avoid being mistaken for Jeff Atwood.

Please sign up on the Upcoming page so we have an idea of numbers.

P.S.: If you're interested in speaking or running an exercise at future events, comment here, contact us, or add something to the Topics Backlog

P.P.S: I'm wondering how many responses will come from here versus the SyXPAC blog?

Another look at the rules of simplicity

Been thinking about the XP rules of simplicity and re-phrasing it to reflect my current view of things:

Rule 1: It has to work.  "Work" means that it does what is needed to achieve whatever goal that led to us building this thing in the first place.  This includes works functionally, performance, usability, etc.

Rule 2: No duplication that anyone on the team can figure out how to remove.  This does not include incidental duplicaton.

Rule 3: Nothing is written that the best person on the team finds non-obvious or difficult to understand.  Everyone else on the team must also understand it.  Therefore everyone on the team must be developed.  Making things is about making people.

Rule 4: If something is here today that is not needed until tomorrow, it must be removed.  Also, designs that require less code are preferred over designs that require more.

A new left side for the Agile Manifesto

Via Antonio Terreno,

The New Left Side of the Agile Manifesto (aka The Software Craftsmanship Manifesto):

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft.  Through this work we have come to value:

well-crafted software                   over working software                   over comprehensive documentation
steadily adding value                  over responding to change               over following a plan
a community of professionals     over individuals and interactions       over processes and tools
impressing our customer            over customer collaboration             over contract negotiation

That is, while we still value the items in the middle over the items on the right, we value the items on the left even more.

If leader should be teacher, then...

If we follow the leader = teacher concept, then the effective number of direct reports should be similar to the effective size of a classroom.

Jon Miller writes about The Lean Workplace as Classroom:

Teacher student ratio. Classrooms with more than 12-14 students per teacher do not perform as well as smaller class sizes. In the workplace this is known as span of control and likewise when a team leader has a team size that is too large, quality, safety, productivity all suffer. Too many companies look only at the indirect to direct ratio and increase team size, reducing one small visible cost while increasing other large, less visible ones.

Another Lean sketcher

Lean Dictionary

View more presentations from Staffan Nöteberg. (tags: dictionary english)

JAOO Sydney 2009 early bird registration ends 15 Feb

A heads up reminder for the Sydney / Australia readers... JAOO Sydney 2009 early bird registration deadline is coming up.

People on the speakers list that I find interesting:

• Clemens Szyperski
• Michael T. Nygard
• Linda Rising
• Avi Bryant
• Joshua Bloch
• Douglas Crockford
• There are also a bunch of ThoughtWorkers but that's not really a big deal for me...
  

Register here: http://jaoo.com.au/sydney-2009/registration/

Before and After codebase quality

Naresh recently had a couple of posts showing before and after shots of some project rescue gigs he's done. Quite a powerful way to visually summarise codebase improvement for people who may not otherwise be aware of the details. [Project Rescue Project] [Another Project Rescue Project]

The things to watch to learn why to prefer cards over spreadsheets

I almost always prefer using physical tokens (like index cards) over electronic mechanisms (like spreadsheets) when facilitating any kind of meeting.  I recently noticed the aspects that I'm paying attention to that has led to this preference.  This could be an experiment that people can try.  Use cards, then use a spreadsheet, and observe the difference in the following:

• Mannerisms
• Energy levels
• Engagement
• Who's talking?
• Who's writing?
• Where are people facing?
• How long does it take?
• How much do you trust the result?  That is, how confident are you that people are committed to the decision?
  

If it's easy to read about, it must be easy to do

Via CommonCraft,


A Scientific American article about University of Michigan Ann Arbor research suggesting that the ease of reading about something translates to how easy people believe it is to actually do the thing:

The findings were remarkable. Those who had read the exercise instructions in an unadorned, accessible typeface were much more open to the prospect of exercising: they believed that the regimen would take less time and that it would feel more fluid and easy. Most important, they were more willing to make exercise part of their day.

Apparently the students’ brains mistook the ease of reading about exercise for the ease of actually doing push-ups and crunches, and this misunderstanding motivated them to think about a life change. Those who struggled through the Japanese brushstrokes had no intention of heading to the gym; the reading alone tired them out.

The World of No Assholes

Via Bob Sutton,

Matticus on constructing a civilized World of Warcraft guild by using The No Asshole Rule:

Do you realize that you spend 15 bucks a month to play WoW? Where does it say you have to spend those 15 bucks playing alongside assholes who do nothing but treat you like garbage everytime you’re on? You deserve a lot better than that. There have even been studies that have shown that interacting with assholes often can lead to physical health problems like anxiety, fatigue, anger and depression.

Hand wash mistake-proofing

Via Mike Wroblewski,

An example of mistake proofing to ensure hospital staff wash their hands before entering and exiting (second half of the video):

A few pointers for stand-up tokens

I pretty much always use Pass the Token for daily stand-up meetings these days and I've noticed a few subtle key points about what makes this pattern most effective.

Randomise the order.  Don't just pass the token to the person beside you, that defeats the purpose of the pattern, which is not just about having a "talking stick".  Randomising the order means that everyone needs to pay attention because you don't quite know whether you'll be next...


Because we're randomising, it means we're not really passing the token so much as throwing it.  This means that the token should be something easy to throw and catch.  I find a tennis ball to be too small, though whiteboard markers seem to be okay (because of the different shape?).  Better is something like a mini rugby or AFL ball (or a mini football depending where you are).  Soft is good, like a plush toy, but I prefer using balls because there seems to be an increase in energy due to, I suspect, an association with tossing a ball and play.

A quick summary of how I like to do stand-ups

I have a much longer article on stand-up meetings (which I should actually update) but here's a quick summary of how I like to do stand-ups.

----
Goals (in order of importance):

1. Improvement - raise obstacles/impediments so that they can be removed; raise better way of doing things
2. Commitment - publicly commit to the team on what will get done; raise obstacles to keeping that commitment
3. Status - raise items that would not otherwise be known via other channels or as a reminder even if they are. I normally try to push status info into other mechanisms such as the story wall or simply talking to each other.

Roles and responsibilities:

• Team Member - raise obstacles; raise improvements; report on past commitments; make commitments
• Coach / ScrumMaster / Iteration Manager - ensure participants follow the rules of the ritual; track obstacles/improvements and ensure they are addressed
• Observer - only observe and wait until after the ritual to discuss if necessary

Sequence:
In turn, each team member provides the team with specific pieces of information:

• Things I have done since yesterday's meeting
• Things I am going to get done today
• Obstacles that I need someone to remove
• Improvements that are worth sharing

Key points:

• Good stand-ups are quick, supportive, and mostly self-managed
• Team Members are the people doing the work; everyone else is an Observer
• Members are committing to themselves and each other, not the manager. If necessary, managers should break eye contact to discourage reporting to the leader behaviour.
• Focus on the scheduled work items
• Take it offline. Cover details and other digressions outside of the stand-up.

A quick summary of Release Planning with Poker Chips

I wrote a paper on how I typically like to do release planning for PLoP 2007 but here's a quick summary that I used recently.  Interestingly enough, the last couple times, this approach wasn't actually appropriate because the forces were different.  That is, this approach assumes time and cost are primary and scope is secondary.

----
Goal:
Shared understanding and agreement on scope for a release.  All stakeholders are involved and are therefore more likely to be committed.  Reduces likelihood of future conflict on prioritisation.

Prequisites:

• Capacity based on historical velocity and the target timeframe.  For example, 100 points for a 15 March release date.  I would normally provide a buffered number and a few alternatives as well.  So for example, 150 for 15 April release date; 125 for 15 March release date with a little extra just in case we're faster than we predict.
• Identified stories that are "backbone stories".  These are stories that are mandatory for the foundation of the system and can not be negotiated out of scope.  Available capacity used for the exercise is the full capacity subtracting what's needed for the backbone.
• Stories on index cards with cost in points.
• Enough poker chips (or other physical tokens) to spend on stories.
• A large table to place everything on.  Conference room table or similar is usually required.

Participants:

• Any stakeholder with authority to make priority decisions.  For example, project sponsor, business representatives,  etc. 
• Any stakeholder with relevant information to support decision-making.  For example, operations representatives, developers, architects, business analysts, etc.

Steps:

1. Present overview of stories on the table
2. Present backbone
3. Present available capacity
4. Have decision makers buy stories with the chips.  Summarise and record what was bought
5. If necessary, continue with extra chips assuming extra time, extra people, better than expected productivity, etc.