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 definitelyenough 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), but  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… people 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.

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.

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.

we need stories from more lean companies

From what I understand of the mass recalls from Toyota, the company lost its culture of quality first. Apparently some managers chose to prioritize growing the company, which caused a conflict of interest any time a problem was discovered--and managers didn't invest the resources to dig to the root cause of the problem. I think this story doesn't kill the credibility of the Toyota Production System, but I do think that it shows that even a 50-year-old culture can be compromised if a company tries to grow too fast. I think that Toyota still proves that average people can have a collective intelligence greater than their own individual strengths, but that this is very fragile.
So much of the lean literature and discussion is about Toyota that this has been rough news... we need to hear more stories about Dell, Zara, Amazon, and other lean companies. Where do you get this kind of news?

the revival of an oral tradition

Around 400 BCE, Socrates stated he didn't trust the written word for the following reasons:

• When the audience was confused, no one could respond to questions
• When we no longer train our memory to recall facts, we become more forgetful
• The written word cannot tailor the message to the audience, nor does it afford the art of performance

We in the Agile Community can appreciate this perspective; in fact we have embraced face-to-face communication in many ways, from encouraging teams to Sit Together, to promoting peer learning through user groups, conferences, and the Gordon Pask Award (or official Pask Award site), as well as the Agile Manifesto's explicit valuing of "working software over comprehensive documentation", and the popularity of story cards/backlogs that are so brief that they offer no more than a "promise for a conversation".

Yet why is the oral tradition so important? I think it is the most direct way to capitalize on the Wisdom of Crowds, to tap the collective intelligence of the people on our teams who are doing the work. When system requirements are written down, organizations tend to be more hierarchical, individuals more specialized, and more ceremony is involved in software processes. On the contrary, when we rely on oral communication, the organization tends to be more flat, relational, and responsibility is shared. This means that people who have to live with a design/process decision also have the ability to fix any mistakes... and so mistakes are fixed more readily.

There is more. Oral tradition fosters an environment where we begin to use words in a particular way--leading to inside jokes, even dialects--and gelled teams. Often the words used by team members helps them communicate faster and more precisely, at the same time as giving them a sense of belonging and identity. If corporate documentation attempts to standardize on certain word choices, this can damage the fabric of a team. On the other hand, if we allow our teams to specialize their language, grow close and communicate face-to-face, they'll make smarter decisions together, and work together to achieve goals better than if we rely on armchair architects.

Agile Besançon -- beautiful code

Last night at Agile Besançon we talked about beautiful code (based on the book Beau Code). We started with about a 25-minute implementation of a binary search algorithm, followed by compare/contrast of code, and an analysis from the book of common mistakes. Apparently this is much harder to implement than one would first expect, and only 10% of programmers can get it right in 2 hours. We all found vulnerabilities in our code (overflows, invalid assumptions about boundary or repeating cases), and it was a great opportunity to reflect on the assumptions we make as we code.

estimate-free still needs estimation

Some agile teams have moved to a kanban-style process in which there is no explicit planning game or estimation cycle--but I think it is an oversimplification to say there are no estimates in the process. How could a team have dozens of story cards approximately the same size if no one ever tried to predict the size in advance?

I posted the following to the XP list today, in response to the Task Underestimation and Overestimation thread:

To [estimate], or not to [estimate]; that is the question,
Whether 'tis nobler in the mind to suffer the slings and arrows of outrageous [deadlines],
or to [code bravely] against a sea of troubles, and by [overtime, to deliver]...

When I think about it, the experiments I've done to remove estimation from our stories were more about reducing the waste, than entirely removing estimates. Consider this--there must be *some* implicit estimation if we're going to slice our stories until they're all about the same size.

My current team has rejected estimation-free cards. We tend to like the size value on the card to remind us of the scope, to keep an urgency about the work, etc.

Still, we've also been unable to add estimates to all cards, using our current planning game; maybe 1/3 of the cards in an iteration show up without estimates at all, and it's too much BDUF to split the stories more. Instead, we treat an un-estimated story as a timeboxed research or a spike--the only expected result of these kinds of cards is a stack of new story cards with estimates. Sometimes the product owners pick how much time to invest in this research, in which case we'll tag the story cost as SPIKE:2, for example, to mean 2 points' worth of spike activity.