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?

Sadface-2017-05-13-08-40.jpg

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.

Software has diseconomies of scale – not economies of scale

MilkCartons.png

“Practical men, who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct economist.” John Maynard Keynes

Most of you are not only familiar with the idea of economies of scale but you expect economies of scale. Much of our market economy operates on the assumption that when you buy/spend more you get more per unit of spending.

At some stage in our education – even if you never studied economies or operational research – you have assimilated the idea that if Henry Ford builds 1,000,000 identical, black, cars and sells 1 million cars, than each car will cost less than if Henry Ford manufactures one car, sells one car, builds another very similar car, sells that car and thus continues. The net result is that Henry Ford produces cars more cheaply and sells more cars more cheaply so buyers benefit.

(Indeed the idea and history of mass production and economies of scale are intertwined. Today I’m not discussing mass production, I’m talking Economies of Scale.)

You expect that if you go to your local supermarket to buy milk then buying one, large – carton of milk – say 4 pints in one go, will be cheaper than buying 4 cartons of milk each holding one pint of milk.

In my #NoProjects talk I use this slide, it always gets a laugh:

Yesterday I put this theory to a test in my local Sainsbury’s, here is the proof:

  • 1 pint of milk costs 49p (marginal cost of one more pint 49p)
  • 2 pints of milk cost 85p, or 42.5p per pint (marginal cost of one more pint 36p)
  • 4 pints of milk cost £1, or 25p per pint (marginal cost of one more pint 7.5p)

(And if you don’t know, the UK is a proudly bi-measurement country. Countries like Canada, The Netherlands and Switzerland teach their people to speak two languages. In the UK we teach our people to use two systems of measurement!)

So ingrained is this idea that when it supermarkets don’t charge less for buying more, complaints are made (see The Guardian from a few months back.)

Buying milk from Sainsbury’s isn’t just about the milk: Sainsbury’s needs the store there, the store needs staffing, it needs products to sell, and they need to get me into the store. That costs the same for one pint as for four. Thats why the marginal costs fall.

Economies of scale are often cited as the reason for corporate mergers: to extract concessions from suppliers, to manufacture more items for lower overall costs. Purchasing departments expect economies of scale.

But…. and this is a big BUT…. get ready….

Software development does not have economies of scale.

In all sorts of ways software development has diseconomies of scale.

If software was sold by the pint then a four pint carton of software would not just cost four times the price of a one pint carton it would cost far far more.

The diseconomies are all around us:

  • Small teams frequently outperform large team, five people working as a tight team will be far more productive per person than a team of 50, or even 15. (The Quattro Pro development team in the early 1990s is probably the best documented example of this.)
  • The more lines of code a piece of software has the more difficult it is to add an enhancement or fix a bug. Putting a fix into a system with 1 million lines can easily be more than 10 times harder than fixing a system with 100,000 lines.
  • Projects which set out to be BIG have far higher costs and lower productivity (per unit of deliverable) than small systems. (Capers Jones’ 2008 book contains some tables of productivity per function point which illustrate this. It is worth noting that the biggest systems are usually military and they have an atrocious productivity rate – an F35 or A400 anyone?)
  • Waiting longer – and probably writing more code – before you ask for feedback or user validation causes more problems than asking for it sooner when the product is smaller.

The examples could go on.

But the other thing is: working in the large increases risk.

Suppose 100ml of milk is off. If the 100ml is in one small carton then you have lost 1 pint of milk. If the 100ml is in a 4 pint carton you have lost 4 pints.

Suppose your developers write one bug a year which will slip through test and crash the users’ machine. Suppose you know this, so in an effort to catch the bug you do more testing. In order to keep costs low on testing you need to test more software, so you do a bigger release with more changes – economies of scale thinking. That actually makes the testing harder but… Suppose you do one release a year. That release blue screens the machine. The user now sees every release you do crashes his machine. 100% of your releases screw up.

If instead you release weekly, one release a year still crashes the machine but the user sees 51 releases a year which don’t. Less than 2% of your releases screw up.

Yes I’m talking about batch size. Software development works best in small batch sizes. (Don Reinertsen has some figures on batch size The Principles of Product Development Flow which also support the diseconomies of scale argument.)

Ok, there are a few places where software development does exhibit economies of scale but on most occasions diseconomies of scale are the norm.

This happens because each time you add to software software work the marginal cost per unit increases:

  • Add a fourth team member to a team of three and the communication paths increase from 3 to 6.
  • Add one feature to a release and you have one feature to test, add two features and you have 3 tests to run: two features to test plus the interaction between the two.

In part this is because human minds can only hold so much complexity. As the complexity increases (more changes, more code) our cognitive load increases, we slow down, we make mistakes, we take longer.

(Economies of scope and specialisation are also closely related to economies of scale and again on the whole, software development has diseconomies of scope (be more specific) and diseconomies of specialisation (generalists are usually preferable to specialists).)

However be careful: once the software is developed then economies of scale are rampant. The world switches. Software which has been built probably exhibits more economies of scale than any other product known to man. (In economic terms the marginal cost of producing the first instance are extremely high but the marginal costs of producing an identical copy (production) is so close to zero as to be zero, Ctrl-C Ctrl-V.)

What does this all mean?

Firstly you need to rewire your brain, almost everyone in the advanced world has been brought up with economies of scale since school. You need to start thinking diseconomies of scale.

Second, whenever faced with a problem where you feel the urge to go bigger run in the opposite direction, go smaller.

Third, take each and every opportunity to go small.

Four, get good at working in the small, optimise your processes, tools, approaches to do lots of small things rather than a few big things.

Fifth, and this is the killer: know that most people don’t get this at all. In fact it’s worse…

In any existing organization, particularly a large corporation, the majority of people who make decisions are out and out economies of scale people. They expect that going big is cheaper than going small and they force this view on others – especially software technology people. (Hence Large companies trying to be Agile remind me of middle aged men buying sports cars.)

Many of these people got to where they are today because of economies of scale, many of these companies exist because of economies of scale; if they are good at economies of scale they are good at doing what they do.

But in the world of software development this mindset is a recipe for failure and under performance. The conflict between economies of scale thinking and diseconomies of scale working will create tension and conflict.

Have I convinced you?

Get small.

Finally, I increasingly wonder where else diseconomies of scale rule? They can’t be unique to software development. In my more fanciful moments I wonder if diseconomies of scale are the norm in all knowledge work.

Even if they aren’t, as more and more work comes to resemble software development – because of the central role of individual knowledge and the use of software tools – then I would expect to see more and more example of diseconomies of scale.

(PS, if you didn’t see my last post I’ve started a newsletter list, please subscribe.)

Requirements, User Stories and Backlogs

Better user stories

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

Agile on the Beach on the Beach

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)

Train to Cornwall

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 (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

</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.

Scrum, Scrum & Scrum

I’ve come to believe there are three different meanings of the term “Scrum” – well, three inside the software development community at least, if we consider sport we can probably add a fourth.

Even if nobody else does I differentiate between:

Scrum as a synonym of Agile

“Scrum” means “Agile” like “Hoover” means “Vaccum Cleaner” in English English, or like “QTips” means “Cotton Bugs” in American English, or increasingly “Google” means “Internet Search” whether you are using Google, Bing, Yahoo or some other search engine.

This is the way I believe a lot of software people use the term Scrum. Although Agile is more than Scrum alone often (mostly?) when people say Scrum they mean some a general form of Agile, something with iterations, stand-up meetings, perhaps User Stories, perhaps some technical practices, etc. etc.

Hard Core Scrum, ScrumTM

This is Scrum without Project Manager or Architects, maybe even without Testers. This is Scrum of Commitment and Abnormal Termination of Sprints.

I once heard Craig Larman say “If you have a project manager on a Scrum team you aren’t doing Scrum.” Only last week Christin Gorman Tweeted saying: “If you want to use managers and architects, you won’t be doing scrum. And that’s ok.”

I’ve written before about how this hard-core Scrum might actually conflict with Scrum (When did Scrum start loving Project Managers) and XP (Two ways to fill an iteration).

This view sees Scrum as a kind of Communist Manifesto but with Managers as the Bourgeoisie. It would be funny if this weren’t so serious. I believe that if you take this interpretation you will soon run into opposition from a layer of managers. The paradox is that Scrum is as popular as it is because those manager don’t like Extreme Programming and saw Scrum as the management friendly alternative (The Three Advantages of Scrum).

Common-Scrum or Scrum-Lite

This is Scrum but without the anti-manager zeal. Of course for many people this strips Scrum of its primary asset – and they might be right. It might be that if you neuter Scrum you get a less effective result.

In this form of Scrum Project Managers still exist – assuming you had them to start with, a lot of places don’t. However they have been renamed Scrum Masters – see my example from 2008.

In Scrum-lite the word commitment really means “agreement” because the team are probably using velocity to judge how much work they can do. Architects and other ranks, sorry, roles, still exists. And companies still kill teams – corporate psychiatry is rampant.

In other words: it is full of compromises. It works for some companies, it doesn’t work for others and ScrumTM purists will hate it.

Anyway, I find it useful to distinguish between these three uses of the term “Scrum”. If you know any more please add them to the list.