Tuesday, March 9, 2010

Agile Besançon--March

This month at our Agile Besançon meeting (meeting announcements at http://groups.yahoo.com/group/software_dev_in_free-county/), we did a Cowboy Coding Contest.   Six people came,  which is definitelymini_P030310_20.49enough to have fun, and we set up one  laptop with a projector so everyone could see what Ludovic and I were up to.   Initially we thought we’d do multiple attempts at the same  algorithm (implementing a Decimal to Roman Numerals converter), mini_P030310_20.50but  we wanted something new for the second try, so we did a binary search instead.  We spent just over 30 minutes for each programming task, followed by a review of our approach.  Anyone who wanted could share their code, their algorithm, or speak more generally if preferred.  Since people were allowed to code in any language, we ended up seeing implementations in Java, Python, and C++!  I would have gone faster if I’d picked Java, but I don’t want to lose everything I know about Python, so I practice it when I get a chance…

As usual, we ended our meeting with a quick feedback cycle… mini_P030310_20.53people enjoyed coming out to do code, but thought the algorithms could have been laid out more clearly (bduf?).  They also thought algorithm implementation isn’t good practice for object-oriented programming.

Thursday, March 4, 2010

Point Synchro with a timebox

Some of our synch points have been too long recently, so we decided to timebox them. When the music plays, we meet around the story board and start a 5-minute timer. We look at the story board, focused on what it will take to move the stories along--and whoever is closest to the board asks people questions, using the stories as the focal point, instead of going around the circle to give everyone a chance to speak. At noon the meeting is slightly longer, because we make sure everyone has a chance to speak--but the rest of the time the objective is just to find out who should be talking to who.

Tuesday, March 2, 2010

favorite lines from Peopleware

Peopleware, Productive Projects and Teams, by Tom DeMarco and Timothy Lister, is a classic software project management book for good reason. They discuss problems that have existed for a long, long time, and are not going away any time soon--the High-Tech illusion: "the major problems of our work are not so much technological as sociological in nature".

Counter-productive Managers
Much of the management culture that has been exercised for millennia is simply counter-productive:
  • Rather than scolding employees for making mistakes, pro-actively ask them "what dead-end roads they've been down" recently. If none, then they're not being creative enough, not taking enough risks, and not going to provide the value we expect of them.
  • On average, they claim that salaried workers spend only 5% of their time on "planning, investigating new methods, training, reading books, estimating, budgeting, scheduling, and allocating personnel". Without a curious/reflective attitude, how will the workers improve?
  • There's no such thing as overtime. "The best workers have been through it all before... they take their compensatory undertime when they can, and end up putting in forty real hours of work each week". Instead, managers need to identify workaholics, and encourage them to pay attention to their personal lives, because otherwise, ultimately, they'll burn out.
  • We cannot increase productivity in knowledge work by turning up the pressure. Any short-term gains in productivity have to be weighed against future loss of employees.
  • Cutting corners on quality is no way to increase productivity. Just as the lean folk say today, DeMarco and Lister said 25 years ago that "the trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted". They add "Quality... is a means to higher productivity", yet "Quality is free... to those who are willing to pay heavily for it". That is, we must pay heavily for quality but the returns justify the investment.
  • Parkinson's Law: "work expands to fill the time allocated for it". The authors say this is a destructive myth.
  • Coding Wars: the authors collected data from various environments and compared time-to-completion for correct implementations of sample programming tasks. They found a 10:1 ratio between best-to-worst, and better half being 2:1 as fast as the wore-performing half of programmers. What was more interesting, though, is there was a 10:1 ratio between best-to-worst organizations. If you work in a noisy, disruptive office, well, everyone is affected. If no one can can get any work done "between 9 and 5", work on it.
  • Disrupting the flow of concentration may require "fifteen minutes or more" to get productive again. Many environments are so disruptive, no one gets into flow enough to get anything done. When applied to an agile context, I think that flow is different. The authors concede that people doing similar work in the same room aren't often disrupted by the hum of their coworkers, and the general consensus on the XP list is that we're trying to optimize the flow of the team, not of individuals in a team environment. That means interruptions related to the current activities on the team are OK, a change in direction and distractions are not (hence the Scrum rule prohibiting changes to the sprint's cards?) Answering the phone--is obviously disruptive. The authors advise against electronic interruptions of any sort.
  • Cornell University's findings on the effect of music--workers were less creative!
  • "Professional means unsurprising". An organization is constantly becoming more uniform, more rigid, more standardized. This reduces "the potential to generate energy or do work".
  • Aptitude testing doesn't work for making hiring decisions--but it does help employees do self-assessments, to motivate them to improve and to work hard. What we need is autonomy, purpose, and mastery, according to Dan Pink.
Supporting Teamwork
They say that "someone who can help make a project jell is worth two people who just do work".
  • In Alexander's A Pattern Language, he writes "without communal eating, no human group can hold together...we found this worked most beautifully when we took it in turns to cook the lunch"
  • "The business we're in is more sociological than technological, more dependent on workers' abilities to communicate with each other than their abilities to communicate with machines"--and so recruiting should include an evaluation of a person's communication skills and sociological aptitude.
  • Change the culture of turnover. Encourage employees to sign-on permanently.
  • "Voluminous documentation is part of the problem, not part of the solution". And so the Agile manifesto wasn't first to publish this idea. They even touch upon the idea of complex rules-->simple behavior; simple rules-->complex behavior explained in Complex Adaptive System theory, and talk about "malicious compliance" where employees can follow the letter of the law while going entirely contrary to the spirit of it.
  • This is the book that coined the term "jell" to refer to a cohesive, interdependent group of individuals whose production of the team is greater than the sum of its parts.
  • On a jelled team, managers don't need to provide motivation--it's already there. The people find the work more enjoyable than it should be--just because of the team. The goal could be arbitrary--but everyone has agreed to help achieve it.
  • Much of our work is still independent--the team serves to make sure everyone's pulling in the same direction.
  • "You can't make teams gel"
  • Autonomy only exists when managers give their employees room to make mistakes.
  • Managers who support teams aren't doing the work of the team--they're focused on healthy relationships
  • Promote excellent quality
  • Make (even fabricate) milestones, so people can see progress and feel done
  • "Promote eliteness"
  • "Encourage heterogeneity"
  • "Preserve and protect the team"
  • "Provide strategic but not tactical direction"
What is a jelled team?
  • they have a strong sense of identity (shared jokes, shared lingo)
  • they've got a sense of eliteness
  • joint sense of ownership
  • individuals seek peer review
  • interactions are fun, easy, healthy, warm, confident
  • loyalties within the team are stronger than to the company
One example, Black Team (at IBM?), was particularly impressive--they formed a culture that stuck even when individuals eventually moved on; their effectiveness improved dramatically over time, and the company considered them a great success.