second Agile Besançon event

This is a long-delayed post, seeing that we're about to have our next Agile Besançon event this Thursday--but for our last event, Monday, Dec 14, we joined with Bar Camp for its kickoff event in Besançon. The organizers there took photos and documented a bit more, so I won't repeat what they said. I presented a topic on test-driven development with a colleague (Fréd).

Jerry Weinberg's The Secrets of Consulting

This book is a collection of stories and memorable rules... it is unlike anything I've read before, and is hard to absorb in one stretch--I'll probably have to go back to the "listing of laws, rules, and principles" to jar my memory every once in a while. Yet one of the beauties of Weinberg's storytelling ability is that the names quickly bring me back to the story, then back to the lesson.

So, this book says it's about consulting, but he has a very loose definition of the word--consulting is giving advice. The most important thing I got from Weinberg is to never, ever give unsolicited advice. Then, even when asked for advice, it's best not to respond directly, but rather help the person discover it him/herself.

I love his names, like Rudy's Rudebega Rule, the Law of Raspberry Jam, his insistence that as a consultant, he plays more of a role of being illogical, funny, unpredictable than anything else... He seems to have great facilitation skills, great timing "know when pays more than know how". There have been several things I do as a coach that are supported by his rules. I'll list my favorite rules below:

• the First Law of Consulting--there always is a problem
• the Second Law of Consulting--"no matter how it looks at first, it's always a people problem"
• the Third Law of Consulting--if you solve the problem too fast, it's going to be embarrassing
• the Fourth Law of Consulting--"if they didn't hire you, don't fix their problem"
• the Orange Juice test--"we can do it, and here is how much it will cost"
• Brown's Brilliant Bequest--listen to the music and the words
• the Buffalo Bridle--you can make 'em go anywhere, as long as they want to be there
• the Credit Rule--don't worry about who gets the credit
• the Duncan Hines Difference--it tastes better if you add your own egg
• the First Law of Trust--"no one but you cares about the reason you let them down"
• the Fourth Law of Trust--"the trick of earning trust is to avoid all tricks"
• the Five Minute Rule--"clients reveal the answer to their own problem in the first five minutes"
• the Ten Percent Solution Law--"if you happen to achieve more than ten percent improvement, make sure it isn't noticed"

corollary to the Law of Rasberry Jam

Weinberg's Law of Raspberry Jam states that the thinner you spread it, the thinner it gets... it's hard enough to change oneself, harder to influence a team, harder still to influence a class, and yet harder to influence readers of the book. I'd say that a corollary to this is that pop culture, which as whole doesn't respect the source of the ideas, is condemned to keep re-inventing the wheel. It's funny, because one would hope that a really good idea would spread like wildfire, but it can't--it spreads like raspberry jam instead. By the time the masses catch wind of it, it's been reduced to a jingle or technical buzz word.

where the Agile Skills Project needs to go next

There's something new happing in the agile community, despite the fact that some celebrities in our field are waiting for innovation in a post-agilist era, or saying that there's nothing new at the conferences. The transformation is subtle, but very important. In short, it's the creation of local agile implementations that value people over process, community over employers, dedication to the craft and cooperative relationships.

A lot of practitioners are getting experienced enough that they can exploit self-organization to reach out to people in contexts different from their own. Mostly these practitioners are lower profile than the signers of the agile manifesto, but they're not typical early-late majority adopters either, because they're innovating in the wake of the first wave of agilists. They're running their own open-spaces, creating local user groups and conferences, networking internationally, and doing the best they can to learn from one another. Some might call this massive adoption 'crossing the chasm', but in fact they are creating their own flavors of agile at home, based on the learning that comes from participating in the agile community, from previous experience, from corporate and government requirements, and local cultural needs. The agile conferences have been key to building this community, but they're still spread out in time and space in ways that aren't sufficiently accessible for the masses of people that are trying to do agile these days. In addition, the face-to-face conferences have provided sufficient context for people to start working together remotely. The open source world has long leveraged collaborative work at a distance--the agile community, not so much.

So here's what I see...

There are currently over 700 subscribed to the Agile Developer Skills list, which in my mind is the core of the Agile Skills Project. To me it shows that practitioners are coming together in unprecedented numbers to talk about how we might better learn from each other, to define standards by which we will hold each other, and how we'll acknowledge each other's discoveries and hard work. This is low bandwidth collaborative work and can't compare to what we learn at conferences or with consultants, but there's something new afoot.

Next we need these people to take ownership of various places on the wiki, talking about quests, or certifications, or courses; building on the skills inventory, etc. We'll need people who want to build the web application that logs quests and qualifies certifications and course material our classes.

Mostly what we need is people who are willing to tell stories about their development practices, their conclusions on what works and what doesn't, and then peer-reviewed comments on these stories. I hope to see that soon!

deliberate reflection and the Agile Skills Project

Recently I read something from Robert C Martin suggesting that it's only through deliberate efforts that we improve our craft (hence his series of Katas)... today I bumped on the following from Alistair Cockburn.

In The Reflective Practitioner, Schön follows the working habits of architects and engineers. In that book, we see people making predictions as to what their situation will support; then they do some of their work and watch what the situation actually produces, and from that, they alter their understanding. They update their understanding of the problem and the proposed solution according to the changed situation and their new learning. This “reflective conversation with the situation” is just what the Wright brothers did in designing their airfoil.

Craft implies skill in working in a medium, mental or physical. There are many materials in an engineering project and therefore many skills or crafts to become adept at. Some people need people management skills, others need mathematical skills, others need visual design skills, and so on.

Each skill and material brings its own specialized vocabulary. Ceramicists “wedge” clay and study the shrink rate of different glazes compared to clays. Civil engineers work with the tensile strength, fatigue rates, and thermal expansion of their materials. Writers look for flow and development in their texts. Programmers look at cohesion and coupling, testability, clarity of expression, and computational complexity in their algorithms. Testers work with test coverage and probabilities of occurrences. User interface (UI) designers work with cognitive-motor task switching times, recognition times, color scales, and user work patterns. Project managers work with people and are concerned with what builds or tears down trust, community, and initiative.

In each case, craft practice requires practitioners to have a reflective conversation with the material, using the specialized vocabulary. They work with the constraints offered by the materials, the vocabulary, and the project.

It is this deliberate, reflective, intentional improvement that we're trying to support with the Agile Skills Project. Do you have something you'd like to contribute? What can we create together? Sign up for the Agile Developer Skills (http://groups.google.com/group/agile-developer-skills) group, and let's talk!

Domain-Driven Design

It's been a while since a colleague (thanks, Nolan) recommended this book, but I finally read it: Domain-Driven Design by Eric Evans. The author talks about a kind of code debt I'd intuited a long time ago, but could never describe in words--a semantical mismatch between the mental model used to explain the code and the language used by domain experts. This book is important because with an alignment between the code and the domain, we can automate at higher and higher levels of abstraction, and therefore reap the benefits of rapidly increasing productivity. This is the greatest value of custom software--the domain-specific objects that reflect a team's understanding.
In Philadelphia, our team focused our code by naming projects, classes, and methods in ways that business stakeholders would recognize. This made it so we shared a ubiquitous language, as Evans calls it, a clear set of names that make sense to both developers and stakeholders. Something we didn't do enough of, though, is refactoring as the terminology evolved. We did practice merciless refactoring, but it was driven primarily by technical needs. Evans also mentions that the natural language of domain experts will be imprecise and self-contradictory, so it's important to be able to create, together, a new language that is unambiguous. Humans are especially adept at creating language, and the process of using our new shared vocabulary will propel us to simplification--we naturally find easier ways to say things. By implementing these verbal shortcuts in the code, it is simplified as well. The resulting deep model will constantly evolve as our understanding of the domain improves, and our communication about the domain will become more and more precise. In fact, the communication can become so precise that Evans reports an end of the "mystifyingly unexpected requirement changes". The new language used to describe the domain model can be so powerful that it's a selling point for marketing purposes, it's a market differentiator!

The following are points I underlined in the book, but may not make much sense to anyone else:

When we're working on a domain model, name things to reflect intention, rather than implementation. Evans also likes "closure of operations" because they perform operations that bring along no other dependencies (closure means input/output are of the same type).
Evans presents many ways to simplify the domain model, for example:

• by constraining many-to-many associations with a clarifying attribute
• minimizing the number of associations
• making associations uni-directional

If the code is in need of significant refactoring, prioritize by clarifying the core domain first.
He also discusses entity objects, value objects, and services, the last should optimally be an operation that does not fit in either an entity or object, it takes some entity or object as a parameter, and it's stateless.
The Repository pattern is a way to keep caching/data store and retrieval from polluting the domain model. Essentially, the repository objects will act as if they are a permanent in-memory collection of persist-able objects, with even some helper methods for quick retrieval of often-run queries. Repositories are made to retrieve existing objects, while factories create new.

Agile Besançon

So tonight we held the first meeting of what I’m calling Agile Besançon… it builds upon some organizing work that Ludovic, Olivier, and Regis have done in the past—going back as far as the coding parties that Olivier held at his house.  Tonight’s meeting was held in a conference room at Temis Innovation, the incubator for the startup I work for, Smartesting.

Ludovic and I facilitated a discussion on Managing Multiple Projects at Once. Conventional Agile wisdom recommends against multi-tasking, and against running multiple projects with the same team, because task-switching incurs a heavy performance cost.  Still, some teams cannot get their management or their customers to focus—so how can they cope?

We started the meeting with a brief check-in, describing how we hope to have monthly meetings where we can play, practice, and discuss topics/skills that we don’t normally address during our work day.  Then we showed how we planned to use the time for the evening—check-in until 7:15pm, game until 8:15pm, and retrospective until 8:30.  We all introduced ourselves with name, job title, and company affiliation, 11 in total, 3 companies represented. 

Ludovic and I had invented a group exercise to help people warm up to the ideas we’d be presenting—the object of the game was to use an assembly-line of workers to build paper airplanes—15 copies each of 2 different models.  We started with a 5-minute prototype phase—and the Acceptance Test for completion was that the plane had to be able to fly across the room.  After a brief pause, we gave each team (of 4) 5 minutes to build their planes—but they were forced into a Taylorist production model—one person rips out a page from an old magazine, next person puts one fold into the sheet, next two people are plane builders—of the kind of plane they had prototyped.  In 5 minutes each team had built about 6 planes—and we then talked for 5 or 10 minutes about what we noticed.  Then each team had a 5-minute huddle on how to improve the assembly line, followed by another 5 minutes of production.  This time each team produced 16 planes—but one team focused on model A, while the other team built both types.  Only one team noticed a hidden requirement written on the whiteboard—that the customers only pay for completed batches of 15 planes.  Afterwards, we talked about the strategies the teams used to speed up (moving more people to the plane-building role, thanks to Theory of Constraints), and we talked about what might help them reach the goal of selling both plane types.  Someone suggested re-negotiating the batch size requirement—and we said that is an excellent way to deal with multiple projects—that as soon as we can get to small releases (minimally marketable features), it’s not as penalizing to switch off to another project—but to switch before releasing means shelving the unfinished investment and therefore indicates waste.  We followed this discussion with a perfection game on the game itself:

The notes, translated from French, indicate that we should keep the:

• short iterations
• brief reflection after each iteration
• simple materials
• prototype phase

For next time we might consider changing:

• construction targets—different objects, like a boat and plane, or simple folds instead of more precise objects
• don’t run an acceptance test for everything?
• the number of projects (have more than 2), and find a way to get people more actively involved in decision-making/collaborating
• making different objects worth different prices, maybe depending on the construction cost

Points of confusion, open questions:

• what was the overall goal?
• how can we help people be more collaboratively involved?
• deliver airplanes?

We ended the night with a quick Blond-ROTI chart (Return-On-Investment):

   

Translated, on a scale of 1-10, people rated the following:

• Worth it to come to the meeting tonight:  8
• I learned something: 5-8
• I will change something tomorrow: 1-7
• I’m ready to lead a discussion for the next Agile Besak: 2s and 8s
• I’ve encountered this problem: 1s and 9s
• Would it be interesting to have more of us: 8-10
• I will invite someone the next time: 9-10
• I’m ready to come the next time: 10
• There should have been more experience reports [tonight]: 10