Programmer’s Rorschach test

The picture above, I recently added this picture to Continuous Digital for a discussion of teams. When you look at it what do you see:

An old style structure chart, or an organization chart?

It could be either and anyone who knows of Conway’s Law shouldn’t be surprised.

When I was taught Modula-2 at college these sort of structure charts were considered superior to the older flow charts. This is functional decomposition, take a problem, break it down to smaller parts and implement them.

And that is the same idea behind traditional hierarchical organizational structure. An executive heads a division, he has a number of managers under him who manage work, each one of these manage several people who actually do the work (or perhaps manage more manager who manage the people who do the work!)

Most organizations are still set up this way. It is probably unsurprising that 50 years ago computer programmers copied this model when designing their systems – Conway’s Law, the system is a copy of the organization.

Fast forward to today, we use object oriented languages and design but most of our organizations are still constrained by hierarchical structure, that creates a conflict. The company is structurally decomposed but our code is object oriented.

The result is conflict and in many cases the organization wins – who hasn’t seen an object oriented system that is designed in layers?

While the conflict exists both system and organization under perform because time and energy are spent living the conflict, managing the conflict, overcoming the conflict.

What would the object-oriented company look like?

If we accept that object oriented design and programming are superior to procedural programming (and in general I do although I miss Modula-2) then it becomes necessary to change the organization to match the software design – reverse Conway’s Law or Yawnoc. That means we need teams which look and behave like objects:

  • Teams are highly cohesive (staffed with various skills) and lightly coupled (dependencies are minimised and the team take responsibility)
  • Teams are responsible for a discrete part of the system end-to-end
  • Teams add value in their own right
  • Teams are free to vary organizational implementation behind well defined interface
  • Teams are tested, debugged and maintained: they have been through the storming phase, are now performing and are kept together

There are probably some more attributes I could add here, please make your own suggestions in the comments below.

To regular readers this should all sound familiar, I’ve been exposing these ideas for a while, they draw on software design and Amoeba management, I discuss them at greater length Xanpan, The Xanpan Appendix and now Continuous Digital – actually, Continuous Digital directly updates some chapters from the Appendix.

And like so many programmers have found over the years, classes which are named “Manager” are more than likely poorly named and poorly designed. Manager is a catch all name, the class might well be doing something very useful but it can be named better. If it isn’t doing anything useful, then maybe it should be refactored into something that is. Most likely the ManagerClass is doing a lot of useful stuff but it is far from clear that it all belongs together. (See the management mini-series.)

Sometimes managers or manager classes  make sense, however both deserve closer examination. Are they vestige from the hierarchal world? Do they perform specialist functions which could be packaged and named better? Perhaps they are necessary, perhaps they are necessary for smoothing the conflict between the hierarchal organization and object oriented world.

Transaction costs can explain both managers and manager classes. There are various tasks which require knowledge of other tasks, or access to the same data. It is cheaper, and perhaps simpler, to put these diverse things together rather than pay the cost of spreading access out.

Of course if you accept the symbiosis of organization and code design then one should ask: what should the organization look like when the code is functional? What does the Lisp, Clojure or F# organization look like?

And, for that matter, what does the organization look like when you program in Prolog? What does a declarative organization look like?

Finally, I was about to ask about SQL, what does the relational organization look like, but I think you’ve already guessed the answer to this one: a matrix, probably a dysfunctional matrix.

Why do devs hate Agile?

Someone asked me this the other day: “Why do devs hate agile?” and as I worked through my answer I thought it worth writing down. There are three reasons I can think of but before we get to them…

First off, I don’t think all “devs do hate Agile”. Or rather, I don’t think the vast majority of them hate it – and hate is a very strong word. Sure some do, no doubt but all? A blanket “all devs hate” ? No.

I do think its is fashionable to slag agile off, and few do this better than the agile community themselves. And unfortunately like a lot of fashions once it gets started it catches on. Once dev A says “I hate Agile” then dev B thinks its cool to say it too, and dev C sees A and B doing it so joins in.

The ironic thing about all this is that Agile is the product of developers. In the beginning it was developers – like me – who saw that the classical way of doing things (write down what the customer wants, design it, plan it, code, it, etc.) didn’t work very well but noticed that the way most work actually happens (quick, code foo… O foo is not quite right change it, quick) was actually better.

I was inspired by Jim McCathy’s book Dynamics of Software Development. Jim was a developer, albeit a developer who had started managing other developers. It was that book that made me think “alternative ways are valid.”

Similar insights were occurring with developers all over the world – as they raced to fix Y2K using heavy weight processes. Some of these coders went on to become mildly famous: Kent Beck, Ward Cunningham and Martin Fowler for example.

And here in lies number #1 why “devs hate agile.”

Theft and imposition.

Agile was all about dev in the early days – especially XP. Just 10 years ago coders would say “I’d love to work Agile by my (project) manager won’t let me.” So we set about making Agile manager friendly, we expanded the business arguments for why Agile was good, and managers got it. Now you hear developers saying things like “My manager wants me to work agile but he doesn’t understand” or “My manager wants me to work agile but does’t help.”

In the beginning Agile was a bottom up movement. Now it is a top-down movement, change is imposed on people rather than people wanting to change.

That is wrong.

Making it worse is the fact that many of those imposing the change frequently fail to understand the change they are imposing or do not question their own thinking. Management thinking needs to change too – start with Software Development is Upside Down.

Reason #1: Agile is now an imposed change.

In my experience developers want to work Agile because true Agile allows them – no, demands – they do a quality job. Agile doesn’t deliver half the benefits it promises if organizations don’t pay attention to quality, that means their technical practices, thats what we used to call technical excellence. That means developers doing work that are proud of.

Namely “technical practices from XP”, specifically: simple design, relentless refactoring, test driven development (plus behaviour driven development), pair programming and things like face-to-face conversations and “story is a placeholder for a conversation.”

I’ll point the finger specifically at Scrum, and later Kanban, for not mandating these practices – something I did with Xanpan. Part of making agile acceptable to management was removing the words extreme and programming, and down playing the difference high quality can make.

Without these practices teams are driven harder to deliver something sooner and quality drops. As quality drops it gets more difficult to deliver anything in a short amount of time. Consequently more is demanded of coders, stress and tension rise and it is not fun.

Reason #2: Agile without technical quality makes developers lives worse.

I remember meeting some coders in Cambridge, almost the first thing they told me was “We hate Agile, our managers went on a Scrum course and have insisted we do it for months.” I quickly discovered that they were not doing any technical practices, as a result they were racking up more and more technical liabilities and making their own lives harder. Once I explained that they were missing the technical practices their attitude changed.

Now to the final reason, perhaps the big reason…

The Agile toolset is intended to help teams organize themselves, it is intended to make problems visible so they can be addressed and fixed. In the hands of people with the right attitude this is brilliant.

Teams don’t need a manager (although one may still be useful).

Teams can see problems.

And teams can fix problems.

But… the very same tools used by someone with the wrong attitude are a micro-managers dream.

Which micro-managers wouldn’t want everyone to give a status report at 9.00am every day?

Who wouldn’t want to see all work broken down to pieces for which NAMED individuals could be held accountable?

And why wouldn’t they want to make a shocked face and send a very clear “that is not acceptable” message every time an estimate was high?

Visibility becomes a tool of blame.

I once helped a team at an airline set up a Kanban board, instead of using it to see bottlenecks, problems and find opportunities to improve the managers concerned used it to assign blame, point fingers and demonstrate that nothing was happening because someone else wasn’t doing their job.

Reason #3: In the wrong hands the same Agile tools are very effective micromanagement tools.

Requirements, User Stories and Backlogs

User Stories, half of me hates them, that half of me wonders “What is all the fuss about?” and that half wonders “How did Mike Cohn write 200 pages about something so simple?”

The other half of me see that people find them useful. They fill a need. They contain the key elements of requirements “Who What Why.” And over the years I’ve built up a lot of advice I give to people and teams. Some of it is User Story specific, some is about requirements in general and some is about backlogs and Agile.

A couple of months ago I was flying to Dallas to see a client. Its a long flight from London so I took the opportunity to write down my standard advice. The other passengers must have thought me strange, for over half the flight I was tapping into my laptop. By the time we landed I had about 25 pages – yes 25! – of raw, unedited, material.

I’m in the process of turning this material into a series of articles for Agile Connection – and benefiting from the advice of Johanna Rothman as I do it. The first pieces are already online:

  1. User Story Heuristics: Understanding Agile Requirements
  2. Relieving Agile Tension: How to Write Small Stories That Still Have Value
  3. Know Your Customers: They Can Help You Write Better User Stories

This series will stray into requirements and backlogs.

Now as it happens, about the time of Dallas flight the nice people form Libero in Romania asked me if I could give a day seminar on, yes, Agile Requirements. So, if you are in Romania, or fancy a trip to Romania in September check it out:

Agile on the Beach voting procedure

Nothing exciting but to save me from explaining this again and again….

Yesterday the Agile on the Beach conference committee finalised the speaker lineup. I’ve just this morning sent the acceptances and the “Sorry” e-mails. Since there were about 150 submissions and only 41 slots to speak in we cold only accept less than a third of the submissions – even fewer actually because some sessions are doubles.

Here is how we came to our decisions.

We have five committee members – you can see who on the website. Each of these was given electronic copies of all the submissions – including long and short synopsis, speaker bio, travel origin (implying how expensive it might be for us to bring someone in) and other details.

Each committee member independently scored each submission on a scale from -2 (I don’t think this should be at the conference) to +2 (I really want to see this myself.) By making Zero the default any reviewer who didn’t review a session or felt they did not have the knowledge to pass judgement didn’t bias the results. Sometimes reviewers made a comment as to why they had given this score but not always.

I took these scores and added them together. In the first review meeting (two weeks ago) we reviewed the total scores, debated a few sessions and the top scoring sessions were short listed.

In the product track 17 were shortlisted, business 13 and for the team track 27 made the shortlist. Again each reviewer independently reviewed the shortlist. Software was slightly different because we again decided to make extra space to keep our technical side, more to follow. Since Product expanded from one day to two days this year it means the conference has grown again.

But this time instead of scoring the sessions reviewers ranked them. Each track has 9 sessions (if all are single) and each reviewer ranked the sessions knowing this.

For the second meeting I took these rankings and averaged them for each session then in each tack ordered the track. At this point we had some clear accepts. At the 9 mark things became fuzzy, in one track we had a double in position 9, in another track one person had three slots in the top 9 and so on. So some manual adjustments were made. We also made a call on some things we thought should be in the conference or developed mini-themes.

In the end a lot of sessions didn’t make the cut simply because they were out competed. Everything that made the shortlist was strong, a lot that didn’t make the shortlist was strong too. We just don’t have space for everything we would like and can’t expand the conference every time, sorry.

Anyway, I hope that explanations helps.

Do you know the way to Falmouth? (Agile on the Beach)

The Agile on the Beach 2014 conference is fast approaching and there is every sign that it will, again, be sold out. Which means, in the days and weeks before the conference I’m going to have several people asking me for my advice on how to get to Falmouth. So here is some advice on getting to Falmouth and the conference, not everything you could know, but the main points I tell people when they ask. (If you want a quick summary skip to the end.)

Firstly even some English people are stumped when they stop and consider how to get to Falmouth. Its in Cornwall, its not as far west as it could be (thats Penzance) but it is part of the country that many people have never been to. And if you are coming from outside the UK its even more likely that you need to stop and think.

So the first piece of advice is: plan in advance. Don’t leave it to a few days before hand. You probably need a day just to get the Falmouth.

And that leads to the second piece of advice: if you can plan to extend your stay it is well worth it. The conference is Thursday and Friday, if you can plan to stay longer. I know speakers and attendees who have brought their significant other with them, or arranged for the significant person to arrive on the Friday.

Falmouth is a great little town to spend a day or two in. Better still St Ives is close by, I have been known to go all the way to St Ives just for an exhibition at The Tate gallery there. Then there is the rest of Cornwall to explore. And, if you look carefully there are great places to eat.

Lets start with the most common case…

Falmouth by car

You can drive from London to Falmouth, its about 300 miles and five hours driving – before you take any breaks. Personally I don’t recommend it. I’ve done it a couple of times and its not my idea of fun. Especially once you leave the M5, the A30 seems to go on and on and on… If you do drive allow plenty of time and plan on a couple of breaks.

Also, you are likely to be charged for car parking at the conference itself. The conference is held at Falmouth University and despite lots of talks with the University people they refuse to remove the car parking fee. As I recall this was £3 a day but I might be wrong. Hopefully they will relent but there you go.

Flying – from London or elsewhere

You can also fly. Actually you fly to Newquay (NQY) airport from where you need to get the 25 miles or so to Falmouth. You are probably looking at a taxi which adds to the cost. Also adding to the cost is the third-world like £5 “Airport Improvement Taxi” which you need to pay on departure.

I don’t like NQY. Of all the airports I’ve been to I find the security staff the most intrusive. I know they have a job to do. I know they have to screen you. I know there are bad people in the world. But… of all the airports in the world I find the security here to be the biggest infringers of my personal space.

I once saw the security staff send once send a lady back to the checkin desk because she had a boarding pass issued by a code-share partner of the airline. The demanded a genuine FlyBe boarding pass and not a self-printed BA boarding pass. Maybe this is common but I’ve never seen it elsewhere.

Anyhow nobody flies for fun these days so maybe I’m being an grumpy old man.

If you want to fly you probably want FlyBe from Gatwick, although FlyBe also have daily flights from Manchester. FlyBe also have some flights from other places but these don’t happen everyday. At the time of writing EasyJet also list a flight from Liverpool and have operated from Southend before now but again its not everyday.

Internationally

If you are travelling internationally you may well be getting on a plane anyhow. Although Lufthansa has an occasional flight to Newquary you are probably going to have to connect somewhere. Gatwick is the obvious place but Manchester is just as good an option.

One thing to be aware of: if you are flying into Heathrow and need to get from there to Falmouth I recommend you switch to trains. Transferring between Heathrow and Gatwick is better avoided. On the other hand, getting from Heathrow to Paddington and picking up a train is really easy.

One minute please, I’ll talk about trains in a moment.

Another option is Exeter airport – Exeter also has an airport with some flights to Amsterdam and other locations in the UK and Europe. Since Amsterdam is a hub this is a viable option for anyone coming from further a field.

From Exeter airport you could continue by train. I’m not sure how you get from the airport to Exeter train station, bus or taxi is my guess.

Last year some Dutch speakers flew to Exeter and hired a car to drive the second leg.

Train

Personally I always take the train. I live in London so this means getting to London Paddington and picking up a train to Penzance. But you don’t ride all the way, a few stops before Penzance is Truro where you need to change.

Paddington to Truro is about 4.5 hours, then change for Falmouth at Truro for a little train but get off at Penryn station (Penryn live departure boards), from there it is a short walk up the hill to the University campus.

I always take the train. Once I’m on the train at Paddington I can work, read, sleep, what ever I like. Unlike the plane where you are queuing to get through security, queuing for coffee, queuing to get on the plan, squeeze in flight for 40 minutes, queuing to get off the plane you sit on the train.

If you are coming from somewhere else in the country you can pick up the Cross Country train that also goes to Penzance or pick up the train from Paddington at Reading.

If you’ve never done the journey before pay special attention to the Dawlish section after you leave Exeter, the scenery is beautiful – and yes it has been rebuilt after last winter.

My big piece of advice here is: book your train tickets in advance. If you leave it until the last minute you could end up paying £300 for Second Class. If you book in advance you can get First Class for as little as £100. The extra’s in First Class aren’t up to much but you do get free water, tea and coffee (compared to first class on East Coast Mainline or Virgin West Coast the FGW First Class is poor).

Note also: FGW don’t have wifi onboard yet and 3G reception is poor after Exeter. The further west you go the weaker it is.

Some of the First Great Western trains have a “Travelling Chef” who does a good bacon sandwich. But, determining which trains have travelling Chef’s is hard, FGW’s website makes you work hard. Second: sometimes the Chef doesn’t turn up. I’ve planned on a bacon butty before now only to find the Chef didn’t turn up for work that day.

Next advice: going home look at the sleeper – especially if you live in London. You leave Cornwall about 10pm and get to Paddington about 5am the next morning. I’ve done it for the last three year – although I’m probably not doing it this year. Again FGW don’t make the sleeper that easy to find or book (no Cross Country this time).

The sleeper isn’t really that much more expensive – I think it cost me £100 last year – and it is fun. You don’t sleep all the way but you will sleep. Its an experience.

A warning: The same trains which have the sleeper cars have regular cars where you can sit -airline style – and try and sleep. If you don’t explicitly book the sleeper you have a seat not a bed.

There you go, that is pretty much the advice I give to anyone who asks: How do I get to Agile on the Beach?

  1. Avoid driving
  2. Only fly if you are coming from international (or Scotland) and then try to connection somewhere other than Heathrow
  3. Take the train if you possibly can
  4. Book early and pay the extra for first class
  5. Think about getting the sleeper back

Events! – Speaking and training

With the impromptu Quality mini-series out of the way normal blog-service will now be resumed!
First up a bit of self-publicity! I’ve got a busy few months coming up and I thought I’d post a list of the events and public training courses I’m giving…

  • Skills Matter In the Brain, “Xanpan – not a methodology, a personal take on Agile”, London, 16 September 2013, this is a free evening (6.30pm event) – registration required at Skills Matter site – THATS THIS MONDAY
  • Skills Matter, Essential Agile for Business Analysts, this is a 3-day course at Skills Matter in London, 16-18 September (booking essential – with Skills Matter). Its called “for Business Analysis” but anyone concerned with the requirements side will benefit. I’m also thinking of renaming it and tweaking to to “Agile for Business Analysts and Project Managers”
  • IIBA Business Analysis Conference, 23-25 September, 2013, “Patterns and Pattern Thinking for Analysis and Innovation – when I’m not preaching about agile, or wishing I’m an Economist, I’m a patterns guy, its my dirty little secret
  • Agile Cambridge conference: “Requirements: Whose job are they anyway?” – 25-27 September 2013
  • Program Utvikling, Kanban Software Development 101, Oslo, 21-22 October 2013: A semi-new 2-day course, some tried and tester material bundled into a new format and focused on Kanban
  • Agile Tour London, “Xanpan (What do you get if you cross XP with Kanban?)”, London mini-conference, 1 November 2013, a chance to hear me outline Xanpan (and save on reading the book)

Looking further ahead, I’m taking on a challenge by speaking to the BCS PROMS-G group (thats the project management group) on “The End Of Projects – and what happens next” (5 February 2014) free, register with the BCS.

Xanpan – now available

A bit over two years ago I started using the term Xanpan to describe the style of agile I advocate and help teams implement. If it isn’t obvious Xanpan – pronounced “Zan-pan” – is a cross between Kent Beck’s Extreme Programming (XP) and David Anderson’s Kanban.

At first I used the term Xanpan to myself, then I started using it in public, then people started telling me they wanted to know more. While I’ve mentioned Xanpan in this blog a few times I’ve never really described it as a whole. That has now changed.

A few days ago I made “Xanpan – reflections on Agile and Software Development” available on LeanPub. This is a short e-book which described Xanpan. In the best traditions of LeanPub publishing the book is going to evolve and change.

Right now I’m reading it end-to-end and fixing a few small things. After this I’d like to write a section on requirements/need/product ownership and another on management. Plus – and this is one of the advantages of LeanPub – I want to get feedback on what I’ve written.

A few people have already seen drafts and given me some feedback but I’m hoping to get more. I’m also hoping for a special type of feedback which is very meaningful: money.

On LeanPub the book is available for a small sum of money. If people are prepared to pay then I know its an endeavour worth continuing.

In addition, I’ve added a Xanpan page to my own website which provides some other links about Xanpan – mainly pieces in this blog.

Please buy Xanpan today! That will give me immediate feedback in dollars, then send me your comments – feedback tomorrow.

10 pieces of advice for teams

I have started to write up a more useful description of Xanpan. In doing so two things have happened. First I’ve realised that I have an awful lot I would like to say about it, I’m terrified it will become another book. Second, I’m becoming more and more aware of how Xanpan differs from Scrum, XP and Kanban.

As a result I expect this blog will get a little quieter. But before the end of the year I’d like to get a few entries finished and published which have been languishing for a while.

So without further ado here are 10 tips for teams and those who manage, administer or simply organise teams. Of course, if you are a self-managing team you should all read this list.

  1. Don’t load overload teams – consider 76% utilisation about the max
  2. Keep teams together – bring the work to the teams, don’t form teams around pieces of work and then break them up when it is finished (https://www.allankellyassociates.co.uk/archives/690/corporate-psychopathy/Corporate Psychopathy)
  3. Minimise disruption to the team, if the team needs to be regularly interruptible and responsive then set processes and expectations accordingly
  4. The more self-standing, free of dependencies, the team the more effective they will be
  5. The team should own the process and methods of working as well as the things they work on. By “own” I mean: they are allowed to change the process and methods.
  6. Make the boundaries and responsibilities of the team clear
  7. The team needs a full skills set to fill 4,5 and 6; and those with the skills need to be on the team full time
  8. Aim for an MVT (Minimally Viable Team) so put slightly fewer people and skills on than you initially think, expand the team as they show success but always keep them minimal
  9. Aim to recruit slowly and regularly, avoid foie gras recruitment, i.e. stuffing the team full of new people in the hope of increasing quantity in the near future (you won’t, you’ll cripple yourself in the short term)
  10. Give the team as much authority and power as possible to do their work, the more decentralised the organisation the more effective this will be
  11. </ol style=”text-align: left”>Looking at that list two things strike me. First is how many of my older blog entries are linked. Second about three of those items are things not to do. Simply not doing bad/mad/stupid things can deliver benefits.

Xanpan

For a little while now I’ve been quietly talking about my new Agile method. The clue is in the name: Xanpan – pronounced “Zanpan”. Most obviously Kanban and XP (Extreme Programming), its a fusion.

Its not so much than Xanpan has any new radical ideas in it, its more than it is a synthesis of ideas from several Agile methods plus my own. It contains a fair chunk of what I would call “product management ideas”.


Xanpan is a little more than that, in takes from Scrum as well as XP, and from Lean as well as Kanban, plus there are other ideas in too.

I’ll write more about Xanpan in future but for now here are the essential features, and where it steals them from. A little rough and ready but I wanted to share this and get some feedback.

From Extreme Programming: The technical practices

  • Test Driven Development plus Automated Test Driven Development. If you want to adopt BDD then go right ahead
  • Lightweight, near time code review, better still pair programming if developers are happy with it
  • Continuous integration: with tests and static analysis tools as part of the build system
  • Rough up front design: no up front design is wrong, but so too is design that takes weeks or months. If you need a design session it is probably part of the planning meeting with all the developers around the whiteboard for an hour or maybe two
  • Refactoring to keep the code soft – its software, emphasis the soft
  • Shared code ownership
  • Minimise documentation, accept tacit knowledge as part of the development process.
  • Velocity measurement and “yesterday’s weather” approach to deciding what to put in the next iteration

From Kanban: Process flow

  • Have a visual board to track progress
  • Divide the board into columns which represent you process – probably more than just: Todo, In Progress and Done. Columns are usually come in pairs: a queue then a action which draws from the queue. Work to improve the flow and change the columns as you go
  • Work in progress limits – usually on action queues, occasionally queues may be limited too
  • Improvement comes from improving flow
  • Minimise the time spent estimating, if possible abolish estimates and use statistically derived approximations, i.e. averages
  • Cumulative flow charts

From XP / Scrum: Process rhythm

  • Use iterations to establish a regular rhythm to the team
  • Iterations start with closing the previous one: review work done, update statistics, conduct a retrospective. This is followed by a planning meeting: work is presented, estimated (if need be) and scheduled
  • Stand-up meetings where appropriate
  • Burn-down/up charts where appropriate
  • User Stories are the default requirements capture tool although Use Cases, Planguage and more informal approaches are acceptable too. If using User Stories then do not use more than three levels of division

For task management Xanpan builds on Blue-White-Red, which is itself a XP/Scrum fusion.

From Lean: Culture of improvement, Kaizen and Learning

  • Retrospectives are not enough: Leaders should undertake personal reflection
  • Rehearsal: Teams should undertake formal and informal training together; deliberate practice as Kevlin Henney and Jon Jagger like to say
  • Team Coach: Each team should have a coach, different coaches may focus on different things so there may be more than one coach. Except in large teams (over 12 people) and in the early days of adoption the coach is usually not full time on a team. The team is there to help the team adopt practices, learn and reflect.
  • Individuals have multiple skills and should all muck in, but there are specialists in some areas.

Somethings Xanpan doesn’t take:

  • Kanban’s stop the line quality control: sometimes it is appropriate, sometimes it isn’t. Keep regular retrospectives, part of your rhythm
  • Scrum Master: teams will have a Manager or Project Managers, or may be lead by an non-commissioned manager, e.g. Team Leader, Technical Lead, or similar
  • Anti-manager ethos: Management is part of the solution, not the problem. Unfortunately the quality of IT and development managers is general is poor; good management can be really powerful

Something Xanpan doesn’t like but doesn’t outlaw (because it can’t):

  • Matrix management
  • Distributed teams, particularly teams in different timezones

Something I find missing in all Agile methods to date is the right balance between engineering and requirements. Therefore….

Xanpan broadly follows the 10 Step Requirements Model but recognises this model is not broad enough to cope with all scenarios. No model ever will be.

On requirements Xanpan believes:

  • There should be a dedicated requirements role staffed by a trained/experienced Product Manager or Business Analyst; both is probably overkill
  • There should be a clear business case setting out why a team or project exists. The business case is not a shopping list of features, nor is it a large document but it should allow someone to decide the work is finished
  • Customers are not the only stakeholders. Each stakeholder will make their own judgement about the success or failure of work therefore each stakeholder needs to be considered
  • Evaluating the benefits of completed work is as important as deciding what work should be undertaken next. There is no point to developing more software if the software that has been delivered so far is not valuable.

And some more:

  • If the team has an architect they should also code; the architects role is to help create a shared understanding of the architecture and educate less experienced team members.
  • Teams should be kept together and not broken up when work finishes or changes; bring the work to the team, not the team to the work
  • Block and impediments should be tracked to see which ones occur repeatedly. If a team cannot resolve an impediment themselves then the leader or manager steps in, in effect it is the start of an escalation
  • There are three version of Xanpan: Evolutionary, Incremental and Iterative – these build on the ideas in my Agile Spectrum article. Iterative is the most compatible with existing corporate culture and project management methods – salami slice requirements; Evolutionary is the extreme – goal directed working
  • Xanpan adopts the three planning layers described in my Three Plans for Agile article and encourages Goal Driven Projects.
  • Xanpan believe management has an important role to play in the development process (but a lot of development managers are not up to the job)
  • Whenever possible put bug-fixing in a separate stream of work; but staff it with the same people, rotate people
  • Keep teams together: bring the work to the team, rather than the team to the work

Underlying it the Xanpan philosophy is about:

    • Quality is free: automate as much testing as you can, although you probably can’t automate 100%

 

    • Prioritisation is vital and omnipresent: there is no such thing as too little time, just mis-understood priorities

 

    • People are key to good software development but there aren’t enough good people to go around, so we need to improve the people we have and help them work more effectively. And we need to grow more good people

 

    • Agile is not about what you do but what you achieve; measure outputs not inputs

 

    • You can always improve

 

    • Customer/End user involvement is key to building a successful system.

 

    • Xanpan is a pick-n-mix of bits of various development methods and adopters are encouraged to continue the approach

 

    • No process or Methodology can cope with all situations, and if it could it would be too big to write down or learn, there adaptation is always required and people need to think

 

  • The process should be changing, if you are doing Xanpan the same in six months as you do today you aren’t doing Xanpan

Notes on a Kanban software development experience

I’ve mentioned the Kanban software development method in this blog before. For those who don’t know its “the new kid on the block” in Agile circles – although the originator (David Anderson) would be quick to point out it is designed to be a Lean development method.

Last year I did some consulting with a large online travel agency. I was involved with helping five teams “get Agile.” This presented an opportunity to try out Kanban in the wild. What I found was: it works, and I feel it is a better models of my own approach to software development than other methods.

What made this engagement more interesting was that I was able to start one team using the Blue-White-Red Agile (BWR) development method I’ve described before and two teams using Kanban so making for an interesting comparison.

The BWR team had been tasked with a project for which a large functional specification had been written. The spec wasn’t perfect but the organization expected them to complete it. BWR allowed the team to break the spec down and attempt it piecemeal. Some upfront estimates were made and a burn-down chart created.

(It almost looked Scrum like, that is, if you ignored the Project Manager, Development Manager, Team Leader, Architect and second Project Manager who joined the project later – and lets not forget me as Agile Coach. Its hard for a team of five developers (and a Product Mmanager) to be self-organizing when there is an equal number of self-organizers.)

This worked well. In the first few weeks I took a lot of heat because I refused to let a completion date for the work be given. Simply we did not have enough date to go on. Once the data started to come through I could do that.

The two Kanban teams were in a different position. Although they had “projects” to do most of their work was sustaining work. There were systems in place and issues needed fixing. Many of the things the company called “projects” were really to small to be worthy of the name – but that’s another story.

As a result the teams had more diversity in their work and more variability. Work would just appear – and disappear. They would have been hard pressed to keep to an unchanged task list (backlog) for a one week iteration, let alone a four week sprint.

This is the first good point about Kanban: its easier to handle changing work loads.

The teams still did “iterations” but the planning meetings quickly changed. Some work would be planned out but this could be usurped at any time. The iteration became the basic unit of comparison, allowing two periods to be compared. This meant that the start/end of iterations meetings were rather more of a review and retrospective session than planning session.

In future I think I would nominally keep iterations for this reason. They are useful time periods to review work and provide a regular review/retrospective point.

Second good point about Kanban: its easier to pick up.

On the whole I found the two Kanban teams needed less training, instruction and coaching than the BWR team (some of whom had been on Scrum training courses.) However, there was some work needed to map out the correct process flow for the Kanban teams to have on their boards.

For anyone creating a Kanban board some advice: big boards a better, involve the team and use coloured tape – insulation tape works well. In the past I’ve just drawn lines on the white board, with Kanban there is more movement and the lines are lost so I used insulation tape to create hard barriers.

A Kanban board

I expected the work in progress (WIP) limits in Kanban to pose a problem. I was expecting managers and others to want to break the WIP limit. This didn’t happen but I found developers breaking the WIP limits.

Developers broke the limits not because they disagreed but because they were accustomed to starting new work when they hit a problem. For example, a developer is working on item X, they come to a block on X so start on Y. In the extreme they block on Y and start on Z. You now have three partially done pieces of work. Trying to instil a “resolve the block” approach was difficult – largely because this organization was overloaded with managers and developers had been “taught” not to resolve these type of issues themselves.

In this organization lots of things blocked. Blocked on other teams. Blocked on IT support. Blocked on administration, etc. etc. I didn’t like it but I added a “blocked” column to the Kanban board. I also added a tally sheet to identify the biggest reoccurring blocks. I then tried to have the managers feel responsible for resolving the blocks. This was only partially successful because managers were themselves blocked because there were so many other “managers” who wanted their time. (The organization used talk as a substitute for action.)

All the teams held daily stand-up (Scrum) meetings and I encouraged the team manager, product manager and BAs to have their own pre-meeting to ensure the prioritisation queue was full and correct. This worked well.

I had the teams tracking cards by making a note on the back of the date as it progressed across the board. The date when it entered the priority queue, the date when work started and stopped, the date when it went for sign-off or test and the date when it was “done.” This data (when complete) was fascinating and started to reveal issues and opportunities, and give an idea of flow. In fact there was so much date I was overwhelmed.

In conclusion I find myself remembering Karl Scotland’s comment from a few months back. Karl had a quote which was something like: “The emphasis in Scrum is on being Agile and improvement follows; the emphasis in Kanban is on improving and being Agile follows.”

In the past I’ve shied away from labelling a team as doing “Scrum” or “XP” because I was aware they were not going it completely and we weren’t seeing all the benefits. I don’t feel that about Kanban, I’m happy to call these teams Kanban. Yes they had problems but we were resolving them. The teams were on a journey.

As anyone who has read Changing Software Development will know, I’m an advocate for incremental improvement. While Scrum (and XP, etc.) hold out the promise of overnight Agile – one big bang and your there – I see Agile as a journey not a destination.