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