Thursday, 22 December 2011

A Charity Day of Agile Coaching

Bradford to London, aboard The James Herriot

The magnificent Grand Central swept me to London last week for my first .

Bradford to London, aboard The James Herriot

Thanks to Rob Dyke for inviting me to visit and for generously pledging £250 to The Woodland Trust, and to the team for such a warm welcome in this cold weather.

Bradford to London, aboard The James Herriot
sustains the community, so we share interests in the open source health space (as well as ). Rob and I met through the oss-uk-health group. Exciting times, with doors starting to open.

Table in King's Cross Hub
, King's Cross is a funky space, a stones throw from the famous station.
Grand Central HST London Kings Cross
Stairs in King's Cross Hub
00_hub kings x_panoramic view ground floor

We were booked into the board room — an interesting space with plenty of glass for drawing on.

0063_HKX_detail_glass writing
The board table filled most of the space, imposing some physical limits on our activities. We improvised and adapted to this physicality.

The team are just starting Scrum. Our morning focused on building skills and knowledge. The inaugural followed, after lunch.

For the morning, I brought along pick-n-mix. Before each session, we played decision poker to pick one from five themes:

Thumb voting then picked one activity from the themed mix. One red card session on user stories was included.

We hit our timeboxes, squeezing in five sessions each structured as {5m plan, 20m do, 5m reflect}, with time for breaks. The physicality of my ladybird timer proved popular: personal, quirky and fun.

After lunch, I observed the meeting, and offered some feedback, before we all left tied but happy.

Some Testing


Optimism is an occupational hazard of programming. Feedback is the treatment.

Kent Beck

TDD seemed so revolutionary when it test infected Jakarta (and most of the rest of Apache). This test automation proved a notable factor in the later success of Tomcat, Struts, Ant, Maven, Commons (and all the rest).

Tests bridge the gap between the language of the customer and the languages of software. encourages alignment by starting with the customer then working inwards towards code.

Fine-grain unit tests execute fast, exercising a unit in isolation. Loosely coupled, cohesive designs are easier to unit test, so unit testing rewards good object-scale design.

Coarse-grain tests, exercising integrated components execute much more slowly, even with appropriate techniques (for example, switching to an in-memory store). Component-scale integration tests encourage cleaner, more reusable API designs.

The outermost layer exercises assembled applications. Fidelity to customer configuration is essential, and often means filling heavyweight stores with data. Set up and tear down costs are almost always high for enterprise applications.

Reasonable coverage using slow running integration and application layer tests costs. Avoid disrupting development flow: separate integration and application suites, and run them outside this flow. Consider triggering after each . To avoid maintenance issues, integration test selectively, invest in good fixtures and use the language of the customer.

A wide variety of open source tools continue to emerge, with sweet spots spanning the space. So spike.

Tools like and Fitness use the language of the customer, a fine match for outer (application and integration) layers. Mocking frameworks efficiently create test doubles to isolate the unit from its environment, and to efficiently verify behaviour (but not at the same time as state).

Efficient tools for special topics abound, for example web applications, load testing, performance testing, Swing, data access, JavaScript and so on...



Daresbury Workshop: IT in Health Care

In early December, I took the train to
Runcorn and a cab to the SIC for the workshop on organised by . The doors are closing on a decade of failure, and starting to for , lean and ideas. I went to raise awareness that change is coming.

Health sector IT is hot here in England, as our NHS starts to open up. I had a great time, hearing about exciting innovations and meeting some interesting people.

Friday, 16 December 2011

Some Evolutionary Design


The best architectures, requirements, and designs emerge from self-organizing teams.

A Principle, The Agile Manifesto

Good design — perhaps a loosely coupled, appropriate blend of expressive, cohesive components — speaks for itself.

When XP arrived, democratising designempowering the developer crowd — seemed radical. To some it still does.

Agile design bubbles up, just-in-time. Complementary practices, tools and techniques facilitate design evolution and mitigate risks.



Tuesday, 13 December 2011

Some Emergent Architecture


Architecture is about the important stuff. Whatever that is.

Ralph Johnson

Just-in-time approaches to design fit well into agile development.

Evolutionary design reduces waste from over-engineering and design stock-piling; at the cost of some future reworking — a traditional focus of software architects.

Just-in-time approaches to architecture blend harmoniously with agile.

Let architecture emerge incrementally with no big upfront process.
Pay off pressing technical design debts before they become critical.

Architecture is the decisions that you wish you could get right early in a project.

Ralph Johnson



Some Story Points


velocity is a useful long-term predictor but is not a useful short-term predictor

Mike Cohn

Story points are an artificial, relative unit of measure for development effort, often combined with to .

Story points are coarse and atomic, arising from intuitive inductive judgement. Trade accuracy for speed, at the possible cost of future rework.

may use tools — such as planning poker — to reach collective valuations.

Estimates for
epics — supersized stories not yet decomposed — are almost always inaccurate.

So avoid unfounded perceptions of precision by limiting point values to a sequence — often inspired by Fibonacci.



Some Continuous Delivery


Release Early, Release Often

Eric Steven Raymond

Agile development finishes features to a regular cadence, a rhythmic flow of potentially releasable versions.

The DevOps movement seeks a stronger but more dynamic relationship between upstream teams and downstream consumers in operations.

Continuous delivery engineers a pipeline for the last mile, extending from integration through proof to delivery.

move from delivering services using projects to delivering them as products

Jez Humble



Some Open Design


Open source is chaotic. With its special magic comes a different reality.

James Duncan Davidson

Issuing open source an license is not enough. The benefits ascribed arise from opening the development process to a broad community.

Open design extends domain driven, consensual, emergent design beyond the agile team to engage a wider ecosystem.

Community building is non-trivial.
Sustainable communication and cooperation needs space to build and maintain relationships.

Walking the fine balance between technical leadership and openness to crowdsourced design ideas is an art.



Some Planning Poker


The estimates are a useful by-product, if your organisation values such things, but actually the most important benefit you get from planning poker is the conversation.

Matt Wynne

Playing planning poker exploits physicality, and team collaboration to improve agile estimates.

And it's a fun way to get the work done.

Buy, make or take a set of cards.

Numbered each with story points, Fibonacci sequenced or not.

Each player is dealt cards with every number for each hand.

To play a hand, all reveal a card with their private estimate then discuss

Until consensus - or timebox - repeat.



Some Kanban


All kanban systems are designed to limit work-in-progress, because the more work-in-progress, the slower the flow.

Leading Lean Software Development

Kanban exploits physicality and pull scheduling to improve flow, and so throughput.

Downstream consumer demand pulls through the stages of a processing pipeline.

Progress may be visualised through a grid, visible to all players, showing the work in progress.

To improve flow, limit work in progress by focussing on bottlenecks. Eliminate waste.

A good solution for complicated processes, and a useful tool for complex problems.



Saturday, 10 December 2011

Some Velocity

Responding to change over following a plan

The Agile Manifesto

Software development is , are not an interchangeable commodity and scale .
Domains with these flavours favour
techniques, such as .

This technique extrapolates estimates from historic team velocitystory points done per unit .



Some Scrum


Scrum is an , iterative and incremental framework for teams developing complex products, that is simple to describe but hard to master.

A scrum team has one product owner, one scrum master and 6±3 cross-functional self-organising developers.

Each sprint begins with one planning ceremony and ends with one review and one . Every day begins with one daily scrum. These events encourage inspection and adaptation.

Product and sprint backlogs are recorded. The orthodox school insists on burndown charts that are optional in the reformed school.
Rules relate these roles, events and artifacts into a prescriptive but extensible framework.

Of course, this description captures the mechanics but not the spirit.



Monday, 28 November 2011

Charity Days: Spiking, Coaching, Mentoring, Training, Facilitation, Knowledge Transfer And Whatnot...

As 2011 draws to its close, I offer a limited number of opportunities for businesses (or people) to book a day (or half) of (well) me for charity. My is broad and deep, filled up with (development and ), open sourcery at and (not just coding: community, licensing and organisational stuff too), plus cool academic topics (machine learning, semantic web, reasoning, concurrency and more) fresh from the . It's been a long road back since injury forced me to drop out; hard core 24/7 coding may still be in the distant future but I'm just about ready now to start adding occasional days of pair programming, training, coaching, mentoring, facilitation or knowledge sharing to my recovery mix. See below for illustrative samples doable in a day...

Sound good? Interested? Then get in touch.

So: What's The Deal?

Cover my train (or air) tickets (as appropriate). Agree a task for me but nothing longer than just one full day at this stage.

If you're pleased, donate something suitable to charity. Suggested donations are £100 (full day) or £50 (half day). My charitable suggestions are Literacy Bridge (innovative, technological hope for poor rural villages in developing countries), The Woodland Trust (creating a more green and pleasant land in England, Scotland, Wales and Northern Ireland too) and The Free Software Foundation Europe (for digital freedom on this rainy side of the pond). More details below...

I'll blog (here) about my experiences and even throw in some link love (if you like).

Want To Know More...?

About The Injury...

In mid 2010, nerve and tendon issues in my hand and wrist forced me to drop out from (the at) the . Since then, my life has arranged itself around physiotherapy and building computer time. From zero, I now have over 8 hours a day (excluding regular breaks). The tendons are fine now, the nerves okay in normal use and the muscles stronger. The next stage is to prove my progress by taking on some isolated days in the field.

About Ideas Doable In A Day...

(some illustrative examples to get those creative juices flowing)

Agile Workshops

Want to give or a go? Need new ideas on for the New Year? Do your team's need just a little more polish? Need more comfort and confidence when creating ? Or just want to learn the basics of Agile development? Each doable in a day...

Agile Coaching And Mentoring

Way back in the '90s, my masters dissertation featured qualitative research examining the way mathematicians learn mathematics. Qualitative and observational methods from anthropology and sociology fascinate me, and I've found this perspective surprisingly relevant for subjects Agile. It's tough to step back from day-to-day performance, and take time to observe and reflect. Mastering observation may take a lifetime but just a day of one-on-one coaching or mentoring is enough to take the first steps.

Talkin' About Agile Quality Assurance

One myth too often repeated holds incompatible with QA management; but quantity is not quality. Lightweight methods focus attention on quality by pruning back unnecessary process and documentation. Back in the '90, I coded VB in a company in transition: committed to recovering certification and rebuilding their development team from nearly nothing. DSDM achieved both goals. Maybe we could talk about where your business is, continuous improvement and how to move towards building higher quality software the Toyota Way.

Open Source: An Inside Track

Whether incoming (building new products from open source components) or outgoing (open source engagement as business tactic or strategy), open source is now a distinctive feature of the technological landscape relevant to most enterprises. All the noisy openness sometimes obscures more subtle stances adopted by corporate players using development, licensing and business models for tactical and strategic advantage. I've contributed at Apache for over a decade (elected a committer first in 2001 and a Member in 2005; served since 2006 on the Incubator PMC and on the Legal Affairs committee from 2007 to 2010), am ranked in the top 500 by Ohloh and (through the Apache Commons) contributed to some of the top 50 most widely installed libraries. I have interests in incoming and outgoing license wrangling and in community building. Whether one-on-one mentoring, a team workshop or freestyle, finding the inside track is doable in a day.

Tech Spikes

Like the idea of big data but want a gentle introduction to Hadoop, MapReduce, BigTable, HBase, Mahout and the rest of the family? Need to get up to speed on techniques for concurrent Java, from locking to non-blocking and beyond to transaction memory? Need a fast track to enterprise Java? Heard about NoSQL, REST and document centric storage but are waiting for an excuse to get up close and personal with CouchDB? Need an introduction to machine learning in the enterprise or to the science behind the semantic web? Maven and Ant? OSGi? Subversion, Git and controlling versions? Enterprise mail with James? Cryptography? Micro libraries, the Commons way? Take a look for more ideas. Either a workshop for the team, or pairing up for a series of one-on-one dojos would be doable in a day.

About The Charities...

Literacy Bridge is just about the most innovative charity I know. The project uses cheap, sustainable, viral technology to connect poor, rural villages without electricity in the developing world. The pilot has great results. Not quite 5 years old, but I'm not the only one to have great expectations for the future of Literacy Bridge.

The Woodland Trust works towards a country rich in native woods. Help to
  • create the largest new native forest in England near St Albans
  • plant 86,000 native tree and engage 3000 children at Low Burnhall, Co Durham
  • (much closer to my home) improve paths and access in Skipton Woods, Yorkshire

The FSFE fights for freedom in this emerging information age. The Free Software Foundation's younger European cousin.

Tuesday, 15 November 2011

Timeboxing And The Pomodoro Technique

Thanks to everyone who made so special, and my particular thanks to all those who arrived early enough to get involved with my lightning talks on and . More links and information may be found here.

Saturday, 21 May 2011

Apache Retreat, Knockree 2011

The Lip, Eas Chúirt an Phaoraigh
Trees, Sky and Sun
Flags In The Sky
Knockree Hostel
The Hostel, Knockree
Room, Knockree Hostel
The Hostel, Knockree
Sun and Shade at Knockree Hostel
The Gate, Knockree Hostel
Looking West, Knockree Hostel
Looking West, Knockree Hostel
Clouds over Great Sugar Loaf
The Drop, Eas Chúirt an Phaoraigh
The Lip, Eas Chúirt an Phaoraigh
Eas Chúirt an Phaoraigh
Great Sugar Loaf
The Great Sugar Loaf
Trees And Sky
Sun sets over Glencree


Thanks to the staff for friendly smiles and hard work. Kudos to everyone who made it happen.

Saturday, 7 May 2011

Had lots of fun co-hosting An Evening On Retrospectives last month at with Mark. Thanks to everyone there: it's the people make or break participatory sessions like this.

I've updated a 10 slide introduction to Retrospectives, complete with notes (at the end). It's CC-By-3.0 so feel free to remix and share :-)

Tuesday, 12 April 2011


(Or Avoiding The Blame Game)

A Brief Introduction

Do Reflect Repeat

A positive feedback loop lies at the heart of the iterative methods popularized by the movement. Millions of words must have been expended on the do. Effective reflection is equally essential but often seems to be neglected. Retrospectives are a tool for reflection advocated by agilists, helping teams to build and bond, and to continuously improve their technique.

Do, Reflect, Repeat

A Longer Introduction

The Blame Game

Teams bond and learn by doing together. If the only time that a team reflects together happens after things have gone so wrong that something must be done, then the team is likely to lack the collective experience required to succeed under pressure with this review. So reflect regularly and work hard to continuously improve.

Are All Retrospectives Agile?

When failure is both likely and costly, individuals start to think about themselves first and the team last. Post-mortems (and related forms) applied after failure risk reduction of team morale and reinforcement of failure, substituting blame for reflection. Retrospectives (by contrast) are concerned with positive collective reflective, not negative individual blame. If you must play the blame game, use different tools (for example, semi-structured interviews with individuals).

Developers Have Feelings Too

Retrospectives verses Reviews

An emphasis on the emotional is a distinctive aspect of retrospectives, and sets them apart from more conventional review methods. Given popular beliefs surrounding technologists, encouraging them to talk about feelings might seem - at first - an unintuitive tactic but it's time to stop reinforcing these stereotypes by acknowledging that developers have feelings too.

Making Good Teams Great!

Modern tools popular with agile developers present plentiful information about what happened: version control systems track (in a finely grained and irrefutable manner) individual contributions to the collective work; build plugins exercise and assess the code; continuous integration servers collect, collate and correlate these metrics; every issue pulled from a task tracker creates a record. By contrast, review meetings seem a wasteful substitute.

San Francisco Agile User Group

Agile techniques specify the process side of why: stories recorded in the language of the customer domain are translated to statements in course grain controlled vocabularies; harnesses bind and automate empirical validation of these statements; finely grained tests close to the code in the language of development discover regression.

Use The Language Of The Customer

Agile tools and techniques reduce waste by automatically creating a quantitative record of the iterative. This allows more time to be devoted to reflecting on the qualitative, human aspects. So agile approaches are a better match for reflective tools which play well with the emotional side - such as retrospectives - than more conventional reviews.

All this adds up to an increased emphasis on maintaining and continuously improving the health of the team.

Form Follows Substance

Bringing Structure To A Retrospective

Collective ownership is critical for successful agile retrospectives. Retrospectives should be by the team, for the team, and so should be structured by facilitation (and never directly managed). Always appoint a facilitator early, allowing plenty of preparation time. Teams with retrospective experience often find that rotating the facilitation role helps to build confidence and knowledge, as well as keeping retrospectives fresh.

Facilitation Basics

The form taken by a retrospective should be flexible, and should follow from the expected substance. Think about the aims of the retrospective, and about expectations. Then choose an appropriate form.

Stand Up Meetings

I find stand up retrospectives are surprisingly successful, especially when learning, building teams, or using short iterations. When time is short, or when the project is progressing well, I find it better to use this form than to skip the retrospective.

Learning Using Stand Ups

When the content is expected to be more substantial (for example, at the end of long sprint), prepare a more structure form. Use physical exercises to gather data, generate insights and move forward. But prepare to be flexible, and adapt the form to the emergent substance.

A Minimal Structure

Regardless of form, a minimal lightweight structure helps a meeting to flow and the team to focus. A good patten is for the facilitator to start the retrospective by setting the stage, establishing the tone and engaging the team; to stand back (metaphorically and physically) and observe, measuring interventions carefully; and to close the meeting at the end of the timebox, bringing everyone together to create a clear collective memory.

Space Physicality Location

Retrospectives benefit from a less directed, participatory style. For those with less confidence and experience in this style, the loss of direct managerial control may seem intimidating. So, I'd like to close by considering how direct control can be traded for influence.

Cafes In Space

I like to think of facilitation acting at the meta-level. Direct control over the proceedings is traded for the ability to step back from participation and observe. The psychological distance created between the facilitator and the group of participants creates a separation of concerns. The facilitator deals with process layer aspects (such as timeboxing, flow and engagement) whilst participants deal with the substantive content.

Meetings With Tables

But a key influence on the health of a retrospective is the environment - the space, ongoing physicality and the location chosen. And this is within the control of a facilitator. Consider location and choose appropriately. Prepare the space carefully. Observe team physicality during the meeting, and step in quickly to remove impediments.

And Finally...

Some Agile Humour

Tuesday, 15 February 2011

Saturday, 1 January 2011

Agile Development Masters


Thanks to Mark for asking me to contribute to development content in the at the earlier this year.

And thanks to Dave, Chiara, Giles, Far, Mandi, Shamim, Sadia, Yuanjing and all the students for making this such an interesting experience for me. Good luck to one and all, and hopes for a happy new year.


And some feedback...

Student Concepts - Confusion

Search This Blog