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

Agile Developer Skills Workshop--Day Three

Today is the culmination of the three-day workshop... I think the team has really gelled with a common purpose and shared values. I had to leave early, so will only report on the morning--but stay tuned because soon we'll have something sufficiently well polished that we don't have to hide our candle under a basket.

So, with the caveat that the group may quickly change direction (we're all agile, right?), I'm happy to report on where I think we're going. We'll be creating the Agile Skills Project, an ongoing, open, and not-for-profit entity that will do the following. But first--who is the "we" that follows? Assuming that you're at an experienced practitioner level, it probably includes you:

• create an "agile skills inventory"--a list of skills that are important to being a good agile team member (note, this is not just for coders), a definition of those skills, and even links to existing learning materials (books, web sites, courses, classes) that may help one acquire these skills. These skills will be mapped to the Seven Pillars, and specific ones will be selected as fundamentals that every well-rounded agilist should know


• provide a way for individuals/teams/orgs to self assess against the inventory--this can be an index into where they should focus self improvement efforts, or what kind of help to seek, paid or unpaid.


• recognize progression along the agile skills inventory--the intent here is to celebrate the successes we make in our life-long learning; the risk would be that people could misconstrue this as an endorsement of a particular competency, which it is not. We see several levels of progression through a skill: exposure/awareness, attempted, successful execution, refined execution, advanced the state-of-the-art. From the "successful execution" level and up, there would be third party verification that the skill was indeed performed correctly.


• characterize learning materials--we'll be able to map existing courses, certifications, conference sessions, books, etc. back to how much they cover the agile skills inventory. This will give a nice "nutritional content" to these learning materials, and help people see the objective value these materials provide


• collect experience narratives--at some point, all this work should tie back to the correlation between delivery and skills. This will provide data that correlates successes and failures to how we do the work.


• review experience narratives--With experience narratives, we'll be learning from practitioners in the field, and be able to improve the Agile Sklls Inventory accordingly. As a nice byproduct of experience narratives, we'll have a paper trail of what progress individuals have made in their learning journey.
  

Agile Developer Skills Workshop--Day Two

So imagine an organization, run by the agile community (or a large subset of it--at least the people that have shown a trustworthy commitment), that is in charge of defining the set of skills we find useful in being a member of an Agile Team. This group would be involved in:
-defining an Agile Skills Inventory (e.g., Active Listening, Story Splitting, Test-driven development)
- providing a repository for reference courses
- defining self/peer assessments
- defining a quest ecosystem
- experience reports
- characterization of external courses (for a fee?)
- rating of trainers for a particular course

Well, this is what we're trying to imagine, and here's how we attacked it today--in several sessions. The group asked me to help facilitate (thanks, Pat, it was a great honor! though I'm not sure if I did in fact keep us on task):



We pondered what value this system would produce, so we talked a bit about supply and demand:




Then we talked about the idea of "a quest ecosystem", or points, or merit badges, or achievements, and ultimately thought it could be called tokens. Basically, we'd like to acknowledge the work people do to improve their developer skills:




Then we tried to clarify what this Agile Skills Project would be all about:




Essentially, what we see right now is that the community would own and maintain the ever-evolving definition of agility, then certify training organizations/courses/study material against the standard. To help developers, these 'certifications' would characterize the courses; alternative free methods would also get characterized as well--so then it's up to the developer to take a course or teach oneself.

To further help the community, we'd have a 'token' system, by which team members could go on learning 'quests' or exercises, which would be recorded in a web site as an experience report. This report would be rated by peers and generate points for both the reviewer and reporter. These points would not be fungible, would have no external worth, but could be used to help people categorize their own strengths and weaknesses, to prioritize further learning quests.

One of our group members took some of the initial 7 pillars work (technical excellence, collaboration, product understanding, supportive culture, business value, confidence, continuous self improvement) and made a wordle picture:

Agile Developer Skills Workshop--Day One

Today a group of interested and interesting folk (I'll get a list of the 14 attendees soon) met in Ann Arbor to discuss the Agile Developer Skills idea. We started with a quick outline that I hoped would move us from a group to a team--a list of what motivated us to show up at the meeting, a reality check on what our goals were and if our sphere of influence was sufficient to make it happen, a list of customers, and then a discussion of a business model that could sustain this system.











We soon moved into a mindmap of our various motivations:

























Then we brainstormed on a list of personas that may be our "customers" or stakeholders.

Then we discussed possible goals / to-do items / outcomes of this workshop.

The next steps are to filter the list of proposed outcomes and to review, in detail, potential "generally accepted curricula" that could be used in various courses.