News from the Cornish Software Mines

My work in Cornwall, helping companies adopt Agile approaches to software development, is set to continue into the new year - so more jokey tweets about the Cornish Software Mines. I hope to write more about this work - the benefits and what we’re learning in future.

Right now there are two pieces of news I’d like to share:

• At the start of December the author of PHPUnit, Sebastian Bergmann, joined in me in Cornwall to provide training and coaching to teams using PHP. Oxford Innovation (who run the Grow Cornwall programme) have put out a press release about this.
• Oxford Innovation have also produced a Video Case Study of our work with Research Instruments in Falmouth. RI are a great success story and the case study is worth the two and a half minutes it takes to watch.

I first met the team at RI in October 2010 when I provided Agile foundations training to development team. Since then I’ve been in many times to provide follow up coaching.

About six month after the Agile foundations course Jon Jagger delivered a Test Driven Development (TDD) in C# course for the team and has also been visiting to provide follow up coaching. All in all a great success, as the video shows.

Xanpan, ToC, Guilt, plagiarism and sorry

When I was doing my Masters degree I had it hammered into me: credit your sources, don’t plagiarise. To this day I take pride in trying to credit the source of my thoughts, back-up my ideas with research and apportion credit. I won’t always succeed but I think I do a reasonable job. Heck, I’ll go further, I think I do a better job than most.

So image how I felt after my last blog post, about Xanpan, when Benjamin Mitchell tweeted:

“@allankellynet I'm unclear why you don't mention Theory of Constraints 5 Focussing Steps. What's your thinking on this?”

I was mortified because, well, he was right. My blog post discussing how to improve throughput on a Xanpan board was pretty much a Theory of Constraints description.

I had plagiarised. I had failed to credit. And I had written something that other people have written before - probably better than me.

I apologise, I give due credit: these ideas are inspired by the Theory of Constraints - or ToC for short.

So how did I come to make this mistake?

Well, I think the answer is in two parts:

First, I have ToC thinking to heart and it now seems so obvious I’d forgotten it needed crediting

Second, the blog entry was written a day after I’d had a similar conversation with a client. ToC hadn’t been mentioned in that conversation so it wasn’t mentioned here.

So maybe the plagiarism occurred in my conversation with the client. Well yes, but.... my first point still applied and second I tend to avoid crediting with clients. Now I’d better explain that second point some more.

In conversation with clients I tend to avoid saying things like “This comes from....” or “I suggest you go and read....”. Yes I do say those things but every time I say it I believe there are two ways for a client to take it: they may take it as “good, Allan is giving me the original source” or they may take it as “Hmmm, this consultant is name dropping, doesn’t have ideas himself and is very academic.” (Plus, they are paying for my time so perhaps I should just explain things to them.)

In short I don’t think it always helps.

I also remember all those Professors at Business School who uttered “Smith Smith & Smith, 1904” (or whatever) at the end of every sentence. And those turgid academic journal articles where every paragraph was credited and thus become very very boring to read.

I could go on but you get the message.

Now, one more thing, this blog entry is really really defensive. I feel a little attacked by Benjamin - I’m sure he didn’t mean to attack me, its just in 140 characters people come to the point. Maybe he feels attacked by this, don’t know we could get deeper and deeper.

For anyone still reading, I’m sorry for droning on. However I think this does raise an interesting point: in trying to explain things, in writing and in conversation making things accessible and easy to understand is - in my humble opinion - at odds with academic integrity and full disclosure.

As someone who makes a living doing this I need to be more aware of it than most.

Xanpan: refining the process

In my last blog entry I discussed a Xanpan board layout which allows for planned and unplanned work to co-exist in one workflow. Here is a picture of the board I had just put together with a team in Cornwall:



This might be the perfect board layout for the team for ever. More likely it can be improved over time - in the words of Kevlin Henney, it is a Stable Intermediary Form.

I think of Xanpan boards like the Pompido centre in Paris, they externalise the plumbing. In this case the workflow and work in progress. You can see the stuff that is normally hidden inside.

My rules are quite straight forward for Xanpan boards:

Stage 1:

1. Model the current workflow on the board: avoid changing it too much to “how it should be” but you will probably need to modify the workflow a little in order to be able to model it.
2. Make sure you talk through various scenarios for work to make sure you have a workflow that will, well, work. As I said in the original Xanpan blog post columns normally come in pairs: queue then work.
3. Operate the board for at least one iteration (several weeks) and learn from it.
4. Reflect and refine the board: in doing so you will modify the workflow, this should be an improvement.
5. Operate the board some more an start gathering data, qualitative and quantitative about the flow of work.

This alone might improve your teams performance: you have visibility of the work in progress, you can reason about it, people are better informed, you will make better decisions. But, this will not solve or your problems, nor is it the end state, it is just the beginning.

Stage 2: (Assuming you want to improve the throughput)

• Think of the board as a pipeline: there are two ways to improve throughput, make the pipe bigger or make things move through the pipe faster.

First seek to move things through the pipe faster:

1. Look at the blocks: why are they blocking or impeding? What can you do about removing them, not just on this occasion but permanently
2. Where are the queues building up? Can you rebalance the board, or rather how your people (and possibly other resources) are deployed to even this out

Continuing reviewing the board and looking for improvements for ever. But if the time comes when you want a bigger pipe:

• Add people to the team gradually over time: adding people slows down the existing team, the bigger the team the smaller the proportional slow down, above all else: avoid foie gras recruitment. Again this is likely to be a long term activity.

Finally:

1. Look to level workflow: reduce the peaks and move work to the lows.
2. Look to increase the value of the items moving through the pipeline - more and better business analysis and product management

Those are the rules of thumb. Of course there are exceptions, of course there are other issues, of course they don’t cover every eventuality.

Xanpan: planned and unplanned work

I’m on my way back from another visit to the Cornish Software Mines. I’ve been with four different companies this week, laid the first plans for Agile on the Beach 2012 conference and got to know Sebastian Bergmann who has been visiting the mines this week working with the PHP teams.

One of these companies is new to the Agile programme, we did training for the entire company last month and this week I was there to get them started for real. This meant we had to design their board layout and talk about workflow. Once again I found myself advocating Xanpan, the cross between Extreme Programming and Kanban.

The board layout - effectively workflow - is on which reoccurs in Xanpan systems and I would like to discuss here. (I’ll explain the layout here and in a second blog entry I’ll post a picture and talk about the future.)

The problem companies/teams face is: they have planned and unplanned work to do. Typically this is some project they are working to deliver but they need to work on support issues - bug fixes - too. I say that, but it is not just support issues, sometimes it is clients who shouts very loud, or managers who can’t say no, or customers who refuse to wait a few days - indeed sometimes to do so would be the wrong thing to do.

The Scrum answer to this is to stamp on the unplanned work. The team are locked - remember commitment and Sprint-goal. This unplanned work is a problem the Scrum Master should stop - or declare Abnormal Termination of Sprint. Particularly in small companies this isn’t a very useful answer, the truth is, things are more complicated than that, planet-Scrum is too simple.

The ultimate solution is to look at the reason these unplanned items are arising and try to address the root course. In time it might well be possible to do that but right now we don’t want to block the team’s transition. Even in the long term this might be the way of the world for such a team.

The Kanban answer would be to go in the other direction: run all work as “unplanned” and just restock the to-do queue as needed. However this robs the team of the rhythmic certainty of a Sprint. Many of the teams I see need to move away from seat-of-the-pants decision making and knee-jerk reactions. Adopting regular iterations builds in decision making points and helps individuals understand their roles.

So: Xanpan, keep iterations/sprints but allow for unplanned work. To do this we design a board which begins with the three columns:

• Planned
• Unplanned
• Prioritised (usually this queue is limited)

The next column is usually something like:

• WIP: In development (usually WIP limited)

The team start Springing as usual: they hold a planning meeting, review Blue Cards (Business requests, User Stories) and if necessary break them down to White Cards (tasks). These then populate the Planned column. These blues are probably drawn from a traditional product backlog.

At any time work can be added to the Unplanned column. The column is unlimited.

A few minutes before the morning stand-up meeting around the board the person with authority populated the Prioritised column reviews and populates it. This could be the Project Manager, Business Analyst, Team Leader or someone else, the role and title doesn’t matter, what is important is that this person has the authority to do this. On one team this was the joint responsibility of the Project Manager and Business Analyst.

This person looks at the work still in the Prioritised queue, and they review the Planned Work and Unplanned work. From these sources they decide the priorities for today. When the team gather they can see what the priorities are. For the sake of simplicity it normally makes sense for the Prioritised queue to be limited and for the priorities to be ordered: 1, 2, 3, up to the limit.

If need be priorities can be changed during the day: maybe something even more urgent arrives - or goes away, maybe the prioritised queue empties, or some such.

Effort estimates are normally assigned to planned work during the planning meeting. For unplanned work some teams don’t both adding estimates, some added a quick estimate from the person who picks up the card when they pick it up and some put an effort estimate on when it is complete.

Importantly, the original source (planned or unplanned) is recorded on the card - maybe a different colour card, maybe a dot, a word, whatever. At the end of the Spring the team can review how much planned and how much unplanned work was undertaken.

Thats it really: planned, unplanned and prioritised. The first two are effectively queues for the third. Somebody, or bodies, are responsible for balancing priorities.

It is possible that this workflow/board layout is actually a transitional layout. After running with this flow for a while there will be data on how much unplanned versus planned work actually occurs.

Dialogue sheets: more sheets & pricing

A quick follow up to my last two entries about Dialogue Sheets (Retrospective Dialogue Sheets: feedback & updates 1 of 2 and Retrospective Dialogue Sheets: feedback & updates 2 of 2).

Several people who provided feedback said they found the cost of the sheets to be off putting. Since the soft copies are fee the true cost of the sheets depends on where you live and what access you have to large printers, I have little control over that. However, I did set up a print-on-demand service for getting pre-printed sheets.

I’ve looked over the settings and I’ve managed to reduce the price on most of the sheets - while I was there I’ve also uploaded some new sheets - a general discussion sheet, a Sprint level retrospective sheet and a Kick-Off sheet.

The cheapest sheet is now priced at $13.75, or £8.74, €10.20. Since the printer is based in the US the exact price depends on your currency.

Unfortunately, shipping needs to be added to that. Within the US the cheapest sheet should total about $30 - if you order multiple sheets the shipping costs doesn’t rise proportionately so it gets cheaper per sheet.

Apologies to everyone in Europe - myself included, or Asia, or elsewhere - shipping something across the Atlantic costs more. Again, if you buy several sheets at once its cheaper - and is what I do, I have a stack in my office.

I would be interested to know from people who do find cost a barrier just how much they could pay. If I know the restraints I can look into other options.

However, the skeptic in me thinks that the actual price is not important: $13 might as well be $3, $30 or $300. It is the fact that any money needs to be spent that is the barrier.

Which is silly really because sitting half a dozen software developers in a room for an hour isn’t cheap: say $100,000 per developer per year means $50 x 6 = $300, the cost of the sheet is trivial. (This might be why so few teams do retrospectives in the first place.)

Look at it another way: A dialogue sheet costs about $30, which means you save $50 (at least) it would have cost for a facilitator.

Cost arguments always loose so look at it another way: if as a result of the exercise the team save more than one hour it has paid for itself.

As I said, if you have any information that can help me find the right answer please e-mail me.