Liz Keogh's blog

I’ve been reading Dan North’s post on programming as a craft, and Adewale Oshineye’s response. I also don’t view programming as a craft. I believe that programming is merely the vocabulary in which we express our craft or trade (and I’m ambivalent about the difference between craft and trade). Focusing exclusively on programming is like learning how to write excellent essays, poetry and email, when 70% of our communication is non-verbal. However, within that limited sphere, I do care about being fluent in our vocabulary, and I think that the people involved in the SC movement and I pursue many of the same goals. I would be surprised if any of us pursued those goals exclusively.

This post is more about the Software Craftsmanship manifesto, whose existence discomforts me.

I dislike the wording of the manifesto’s points because I don’t think they differentiate between programmers who genuinely care about the value they deliver, programmers who care about the beauty of their code, and programmers who hold a mistaken belief in their own abilities. Any software developer – even the naive, straight-out-of-college engineer with no knowledge of design and little knowledge of incremental delivery – could sign up to that manifesto in the mistaken belief that they were doing the things it espouses. I used to be one such developer, so I speak from experience.

I dislike the statement, “That is, in pursuit of the items on the left we have found the items on the right to be indispensable.” Indispensible? Absolutely necessary and requisite? Plenty of valuable code has been delivered by individuals trying out a new idea on their own; by coders like my dad who can’t make a maintainable product to save their lives, but who can rewrite it if they need to; by parties who started out on a basis of distrust and only learnt collaboration later on, let alone partnership; by people who couldn’t find the software they needed so wrote it themselves, or discovered unintentional value and responded to the change. If that phrase read, “That is, the items on the left are a good start and we would like to help you pursue the items on the right too,” it would be a less elitist message. For those developers who would like to be better, and who are aware that they’re learning, the manifesto casts them into the role of the “others” which Software Craftsmen are “helping to learn” the craft. I guess I’m one of those “others”, because I’m still learning about the items on the right, and I certainly can’t see myself as one of the craftsmen with the manifesto phrased in the form it currently takes.

Ade has outlined a number of mistakes which proponents – and I believe opponents – make regarding the software craftsmanship movement. I think supporters of the manifesto are doing exactly the same thing; failing to look at the background of the movement, and jumping on a bandwagon which lets them concentrate on the things they find stimulating while ignoring the bigger picture. “The glamour is overtaking the intent”, as Dan North put it. If Dan’s post does nothing but address the glamour and steer developers away from indulgence in the technical intricacies of their work – refactoring to oblivion while failing to deliver, focusing on test coverage while the company continues to leak money, worrying about the latest testing tool while failing to talk to stakeholders, or insisting that no one can interrupt their two-week sprint once they’ve made a commitment, for instance – then I applaud it.

I particularly liked the conversation between Dan, Aviv Ben-Yosef and Jason Gormand over Twitter, in which they concluded that Software Craftsman is a status you should be awarded by someone else. If nothing else, Dan’s post has let us have a conversation about what craftsmanship really means; a conversation which should be at least as public as the manifesto itself.

Ade, a further reading section attached to the manifesto is an excellent idea. Without it, that manifesto is the face of the Software Craftsmanship movement. I don’t much care for the expression on that face.

I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

• reflect and honor the practitioners who make its existence possible;
• provide an excellent experience for its members;
• support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
• exemplify, as a body, the professional and humane behavior of its members;
• engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
• embrace newcomers to the community openly and to celebrate ongoing journeys; and
• thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.

Jean, Eric and I got together in Denver last week. We didn’t start with any particular goal in mind – I was excited to be there because I knew I’d learn something, regardless of what we did. Jean has strong skills in facilitation and collaboration, and Eric’s heavily involved in Lean and Kanban, both of which are currently areas in which I’m focused and learning.

I’ve already seen a small slice of Rally’s culture at their Chiswick offices in London. Jean was kind enough to show us around the Boulder headquarters, where we were warmly welcomed. The layout of the Rally offices is the most effective I’ve seen – large, partitioned project areas with sliding doors, allowing collaboration while avoiding the problem of noise common to open-plan spaces. Jean managed to book us an entire room for the day, complete with a huge jug of coffee.

We started with the idea that we’d produce something for the Lean and Kanban community. Particularly, we expressed a desire to see the LSSC learn from some of the trials that other communities and community-leading organisations have undergone. Ryan Martens, the CTO and a founder of Rally, also provided extensive input. We talked about what communities meant to us, how leaders and leadership manifest within them, and the influence of factors like money, certification, vendor sponsorship, etc. on the community landscape. At the same time I learnt more about facilitation, appreciative enquiry, group psychology, constructive language, the power of well-formed outcomes and the history of the Lean and Kanban movements in and outside of software.

As we talked, we became less convinced that the LSSC actually needed to be challenged, and more concerned with software communities generally. We started writing phrases that we felt represented our views on post-its, and constructed the above challenge by piecing them together. For me, this is a personal statement and commitment – if it’s exactly the same as the copies on Eric or Jean’s sites, it’s only because their arguments were sound and convincing. We were heavily influenced by conversations with Chris Matts and his call for “fewer leaders, more leadership”.

Because of that personal nature, we wanted to avoid putting this up as some kind of centralised manifesto that people can sign. If you feel strongly enough about it that you want to sign up, copy it. Post it on your own site. Attribute it to wherever you got your copy from – the act of sharing is more important to us than the act of creation – and feel free to change it so that it reflects your own values. I don’t think that any statement like this can ever be perfect, nor will we perfectly live up to it.

I am a member of a community of thinkers. So are you.

What’s a Cargo Cult?

Once upon a time, during World War II, there was an island on which planes landed. The islanders loved the planes landing, because they brought goods that the islanders couldn’t normally get. The soldiers shared the goods with the islanders, and the islanders considered themselves wealthy, lucky, and blessed by the gods.

When the planes stopped landing, the islanders missed the cargo that the planes had brought, and decided they’d try to bring them back.

They did the same things that they’d seen the soldiers do to make the planes land. They created signal fires, waved at the sky, wore coconut-headphones on their ears and made replica planes from wood and straw. The cult which surrounded this sympathetic magic came to be known as a cargo cult.

What’s Cargo-Cult Agile?

As the Wikipedia author says, the islanders mistook a necessary condition for the planes arriving as being a sufficient condition for the planes arriving.

Teams and individuals sometimes make this same mistake with Agile. They believe that by following the practices of XP, Scrum or some other methodology, they’ll be successful in creating a culture which allows them to succeed.

Unfortunately, the islanders hadn’t realised that the soldiers created the airstrips because there were planes that wanted to land. The planes caused the airstrips – not the other way round! Without the planes, there would have been no desire for control towers or signal fires, for radios or waving arms, or for headphones, coconut or otherwise. And although these artifacts made it easier for the planes to land, the soldiers could have experienced some success with just a bare strip of earth and a little caution.

Agile values

In World War II, the leaders who wanted to win the war realised that planes were necessary. The air-strips helped them to use the planes effectively.

In Agile, the Agile practices that we know have emerged from teams that wanted to deliver valuable, working software, and who had discovered certain personal values that were effective in delivery. The practices they used allowed them to leverage those personal values effectively, but really, a bare strip of dirt – or any kind of process that reminded them what they were trying to achieve – would have enabled them to experience some kind of success.

I’ve found lots of different names for the values that allow teams to be successful – collaboration, trust, responsibility, innovation, camaraderie, rapport, honesty, transparency, helpfulness, forthrightness, motivation, responsiveness, agility, idealism, pragmatism, curiosity… the list goes on. They’re all wonderful ways of expressing those personal values, and I’ve seen or heard of teams succeeding with these values, regardless of which methodology they use. Partly this is because the values they’ve adopted allow them to try things out, to feel safe in questioning the processes they follow, to recognise better ways, and to be pragmatic in balancing the adoption of new ways of doing things with the responsibility for delivery.

I’ve also found that the following five values encompass pretty much everything that I’ve written in the list above, either alone or in combination:

• respect – the belief that other people are valuable, able to teach you something and amaze you, able to succeed given experience and support, interested in others’ well-being and success, and motivated by the desire to make the world a better place; and that any behaviour to the contrary is caused by external pressures or ordinary, forgivable human frailty
• courage – willingness to try new things which might not work, to accept personal risk for professional gain, to make oneself vulnerable in order to learn, and to lead others to do the same
• communication – the art of making oneself clearly understood, understanding others and feeding back any lack of understanding so that it can be corrected, listening and imagining, being aware of the impact of communications (verbal and otherwise), and finding other ways to communicate when required.
• simplicity – the ability and desire to reduce complexity, mitigate or isolate it where it’s inevitable, and avoid introducing it; to start, where it’s possible to start, without worrying about how or where it will end.
• feedback – knowing that our perception of our world and the ways in which we model it may be inaccurate, actively seeking out those inaccuracies (which may require courage!), trusting any existing mechanisms which can inform us of those inaccuracies, and listening to them when they do.

These are the five values of Extreme Programming, as outlined by Kent Beck (the poor definitions are my own).

As a coach, I’ve run competitive workshops in which these values formed the basis of the point-scoring. I’ve seen companies, especially Screwfix, adopt Agile using these values as a backbone, and seen them successfully release projects with previously unimagined scope and resource constraints. I’ve seen Scrum adoptions that were failing take on these values and begin working out the kinks, and XP adoptions that were rigidly bound by their processes, but whose employees lived by these values, become more fluid and successful as they aligned themselves accordingly.

I’ve also seen methodologies adopted without these values, leading to rebellion and the quick return to known, established practices that don’t leverage them. I’ve seen mailing lists on Agile topics become cliques – at least, I don’t feel I can post in them because of the lack of respect shown by some participants to others. And Kent Beck himself had to add that value – Respect – because it turned out not to be as obvious as he would have liked.

Measuring values

I’ve used the Dreyfus Model of Skills Aquisition frequently to measure how well the adoption of particular practices is progressing. I’ve found it useful to map the levels to these values as well, where:

1. Novice: still shows anti-patterns, behaviours which are not aligned with the values
2. Beginner: behaves like a normal human being, and would be pleasant to work with
3. Practitioner / Competent: is a model for these values, has few “off-days” and is forgiving of others on theirs
4. Knowledgeable: maintains these values intuitively, not only as part of their work-life, and can lead others in adopting them; has become a better person as a result of adopting these values
5. Expert: maintains these values in the face of adversity and in environments where these values create vulnerability; can articulate the benefits of holding these values both personally and professionally; can teach others and provide constructive feedback to help them adopt the values and leverage them more effectively.

That “Practitioner / Competent” level, 3, is in my experience the average that a team needs to achieve in each of these values in order to successfully adopt any Agile or Lean methodology. They also appear to lead to more enriched, fulfilling lives at work.

Landing planes

The great thing about these values is that it’s hard to introduce perverse incentives when using them as a metric. One participant in a workshop asked, “What if we just pretend?” Well, you can’t pretend to communicate better without actually communicating better. You can’t pretend to make things simpler without reducing complexity. You can say that you don’t believe in these values, or that you don’t think they’re helpful – but in my experience, teams who’ve tried them have discovered that they’re so much more fun than not maintaining them, they haven’t looked back. Even pretending to value these values leads to good habits, and the reaction of co-workers has often been positive enough to cause them to be subconsciously ingrained.

So, give it a try, and if you’re thinking of adopting Agile or Lean, land those planes first. The practices will follow, and make a lot more sense.