What the Agile Manifesto Left Out
I really enjoyed Brian Marick's keynote on What the Agile Manifesto Left Out. Marick, one of the original authors of the Agile Manifesto, defined 4 values that he felt were missing: discipline, skills, ease, and joy.He talked about problems that he sees with teams adopting XP now. He cautioned developers--don't try to please the customer too much; go slow. If your customers are really happy, then you're probably going too fast.
Jessamyn asked him if he had seen Kent Beck's talk on Ease at Work. Marick said he was not aware that Beck was also discussing "ease".
Marick gave an impassioned statement that humane companies will remove visible status differences among their employees. In particular, he said that there are good reasons that developers should have more powerful computers and bigger monitors than testers. However, as a tester, Marick thinks that this sends a very strong (and wrong) message to employees--that testers are "inferior" to developers.
Deriving XP from Theory of Constraints
J. B. Rainsberger gave a great presentation on how all XP practices can be derived from the principles of Theory of Constraints:- Maximize production
- Maximize production capacity
- Minimize operating expenses
- Maximize throughput
- Minimize inventory
JB described common mistakes:
- Maximizing production to the exclusion of production capacity.
- Not recognizing inventory. That is, all code written that is not delivered is inventory. Short iterations minimize inventory.
JB recommended a halving/doubling trick for process improvements. Don't move from 6-month iterations to 1-week iterations. First, halve the 6 months and do a 3-month iteration. Once you're comfortable, move to a 6-week iteration. Then, 3-week. Keep going, until you've gone too far, then back off.
JB described how to deal with a customer reluctant to prioritizing. If a customer insists that all features are important and must be implemented, then pick the least important feature, and say "okay, we'll start with this one". Once customer says "no, start this one", and touches card, you have priority.
Jessamyn asked how to release software frequently without annoying your customer. JB used the company 37signals an as example. 37signals has different grades of service. If you want the latest features, or more powerful features, you have to pay more. Existing customers never lose functionality, and 37signals can continue to create features and charge for them. JB also mentioned how companies can raise initial capital without venture capitalists. The company TextDrive raised initial capital by offering lifetime service for a fixed number of accounts.
Lean Software Development
Deborah Hartmann is an XP consultant that has been using Lean ideas very successfully. She asks her clients uncomfortable questions: "What is the value of this program/feature?" She attempts to use the elimination of waste as a common value to cut through competing corporate interests, and then teaches companies how to use value stream maps to reduce waste.XP and American Chopper
People that are not exposed to XP have difficulty grokking it. One fun idea that came up in an open space is to create a series of videos showing pairing, standup, test-first, and planning game along the lines of American Chopper, with personality, music, flare, and with master XP-ers. Even without the flare, I think there's some money to be made for good videos of the XP process. Hartmann says she gets asked for these videos a lot, and they just don't exist. The best thing I've seen for exposing the curious to the experience of XP are mock XP exercises.Agile Companies
I hosted an open space titled "What does an agile company look like?"An early question in the discussion was "How to maintain a strong culture of innovation and propagate effective processes?" One person proposed having a Process Coach. Someone else responded that for process innovation to really work, you can't centralize process and value decisions. They suggested that Process Coaches are a good idea, but a prerequisite is to have the entire team (for his company, it was 50 developers) collectively discuss and define shared values and process (his company had dedicated a couple days offsite).
We then discussed how to recognize an Agile company. Physically, Agile companies are distinguished by open spaces, white boards, cards on the wall, and windows. Agile companies are also recognizably different in their emotional atmosphere. Some of the words that were used to describe this emotional difference: fun, empowered, energized, and excitement. Agile companies are louder--a lot more conversation.
Someone from GreenPepper discussed how company culture changes as the company grows. As GreenPepper grew from 4 to 25 employees, the employees spoke about how the culture of the company had changed--how you had to get approval for everything. This happened, even though there were actually no changes by management to centralize control. As employee count increases, people start to make assumptions about their colleagues' roles and responsibilities. As companies grow, job titles become significant, because people start to make assumptions about roles and responsibilities, based on titles. It is important to make roles and responsbilities explicit, because implicit assumptions can prevent people from taking initiative. We're certainly experiencing that at Intelliware. Architects at Intelliware would be surprised at how junior staff perceive Architects; and junior staff would be surprised at how much autonomy is desired from them.
Someone recommended that an effective way to kill initiative in a company, and to produce a culture where people focus on things like titles, is to create visible status differences among employees (e.g. expensive chairs and corner offices for senior staff).
There was general consensus that performance reviews were more bad than good (for an alternative, see how Google uses blogs to track public commitments); team compensation was better than individual compensation; and that public salaries were better than private ones. Buckley raised the point that changing any of these policies in a given institution is unlikely, since, for every person that benefits from such a change, someone loses.
Someone mentioned that a business contract has a different meaning for the Japanese--a business contract is not seen as a defensive device to punish lack of delivery; it is a promise to work together.
The general conclusion of the discussion was that, yes, Agile companies are productive, but, more importantly, they're humane.