SOA is software equivalent of a fast breeder reactor

A fast breeder nuclear reactor is a wonderful idea. Basically, you put in used nuclear fuel from a conventional reactor, burn it, produce useful electricity and at the end of the process the used fuel has changed into a form you can put back into a conventional reactor.

Alternatively, another use for the final product is put in nuclear bombs but we don’t like to mention that.

Fast breeders have been shown to work but have failed to take over the world. They are very expensive to build and operate, pose security dangers and are hideously complex to operate – as you might imagine of a device cooled by liquid sodium, lead or mercury.

In other words: they are not commercially viable.

They aren’t even sensible to Governments.

I have come to the conclusion that in the software world Service Oriented Architecture, SOA for short, is the equivalent of a fast breeder.

SOA works in the laboratory. The technology can be shown to work by big service companies – IBM, Accenture and co. It seems like a great idea.

But… SOA doesn’t make commercial sense.

Let me explain why I believe this.

SOA is all about Reuse. Reusable code and systems.

Reuse does not come for free, you have to write code for reuse. Figures on cost of reuse v. cost of single use are not common. As a general rule I refer to Fred Brooks 1974 observation that it costs about 3 times more. Admittedly not a solid reference but the best I know.

The first problem is: do you know it is going to be reused?

If you write an SOA system and then find it is used once then it is very expensive.

In order to know it will be used more than once you need to accept requirements from multiple sources.

Which means your requirements costs go up, response times go up, responsiveness goes down. Which means you loose time and money.

Worse still, the loss of focus leads to distracted teams, complicated stakeholder management and competing interests. You risk producing a camel rather than a horse.

There is also an assumption here that there is enough commonality that can be factored out for reuse to make the whole thing viable.

Now SOA, and reuse, are sexy. Its something all developers want to do. And they want to do it properly. And such projects tend to be technically driven.

So they loose their business focus and get absorbed in details.

Then there is the matter of testing. Testing costs also go up.

Add in maintenance: fixing a bug in one system is going to hit other systems, all of them need testing. (“Write once, test many” as we used to say in the early days of Java.)

And who pays for this?

If it comes out of the IT budget we again loose business drivers and increase technical focus. But if one group pays for it they are paying far more than they would need to for single use. And if you apportion costs you are going to spend a lot of time arguing.

In other words: SOA works in the lab but not in commercial environments.

My advice, as is with any type of reuse: write it for the problem in hand, get something that works, have plenty of automated tests. And wait. When someone comes along with a problem that looks similar, a real candidate for “reuse” modify the thing you have just enough to cope with this, with tests. Then wait and repeat.

This way you only pay the cost of reuse when someone actually wants it.

SOA and Fast Breeder reactors both belong to the class of technologies which while possible, even fascinating, don’t stake up commercially. Actually, come to think of it that covers most forms of software reuse and nuclear power.

What is Agile?

Two weeks into 2013 and I’ve not blogged, in fact my last blog entry was a month ago. What’s happening? Well partly Christmas, New Year and then flu took a lot of my time. Plus, pre-Christmas my writing energies have been going into writing up Xanpan.

At first I thought my notes on Xanpan would be similar to my “Agile Reader” mini-book, then I thought Xanpan would be a replacement for the Agile Reader series, now I’m seeing it as a book format collection of writing that goes beyond Agile Reader and includes new material on Xanpan specifically. At the moment my working title is “Xanpan – and other notes on Agile & Lean Software Development”.

If you are interested in seeing this project complete please goto the LeanPub Xanpan page and register your interest. Otherwise its likely to be pushed to the bottom of my to do list.

One of the things I’d like to do in Xanpan is define what Agile is, and maybe what Agile is not. In other words, I’d like to answer the question: “What is Agile?”

After much thinking I have concluded there there is no single, short, concise, answer to this question. Rather how you define Agile depends a lot on who you are and why you are asking. With that in mind there are several perspectives you might take in answering the question. The perspectives I see are….

The Historic perspective: Agile is defined by the a manifesto and 12 principles written in 2001. As I’ve said before, the manifesto is now a historic document, it was written at a time when heavy-weight development processes (e.g. SSADM and V-Model, and most things which were ISO-9001 or CMM approved) ruled software thinking. The term “Agile” was coined to group the “light weight” methodologies.

The manifesto is like the US Constitution, and like the constitution we can read all sorts of meaning into it, depending on who you are you read different things. But there is no Supreme Court to arbitrate on whats-what. So Agile is what I say it is – or maybe, like art (“art is what artists do”), Agile is what Agile advocates say it is.

The Not the Waterfall perspective: traditional software development was largely rooted in a mindset which said “Define what you want, design it, build it, testing it and deliver it, in sequence with little or no feedback from later stages.” While (in my experience) we didn’t usually manage to follow that model we tried and when we didn’t we considered it a failure.

I think a lot of the time “Agile” is defined colloquially as “anything other than the waterfall model” but Agile is more than “not not the waterfall”. Indeed, as Laurent Bossavit described in The Leprechauns of Software Engineering, Royce’s Waterfall model wasn’t even discussed in literature much until Barry Boehm started using it as a counter example to his Spiral Model.

The Agile as Better Perspective: Similar to the The Not the Waterfall Perspective, people who hold this view want a improvement over their current (usually poor) development processes and techniques. The motivation is simply to have fewer late projects, fewer unhappy users, fewer bugs and so on.

On the one hand this view is cynical, it holds limited promise; on the other hand this is perhaps the most work-a-day view. People holding this view are looking to make their lives better and their company’s use of IT better.

In some cases Agile as Better links the Historical perspective and the Not the Waterfall perspective. I’ve seen companies that have tried hard to apply traditional waterfall based heavy-weight development approaches. In doing so companies tie themselves in knots trying to enforce a development model which doesn’t match the problems they are trying to address. For these companies the year is still 2001; just adopting a mindset which is not Waterfall based is itself a massive improvement.

The next three perspectives are best explained together, in this diagram: The State of Agile Perspective, The Methods Perspective and The Toolkit Perspective

I often find that when I talk to developers and testers in an company they implicitly view Agile as a toolkit of techniques which might be applied – The Toolkit Perspective. Ask them “Are you Agile?” and they will answer by referencing the practices which they use or don’t use.

Conversely, talk to managers – especially senior managers – and they are concerned with company Agility. Their perspective is the end result, – The State of Agile Perspective – they don’t care whether a team do stand-up meetings, iterations or not, they care about the Agility of the company. Indeed, some Agile practices – e.g. Test Driven Development – may appear downright unAgile to them.

How you define the “state of Agile” depends on what the company is trying to do. In general it is something about being responsive to customers – which implies you actually know what customers want in the first place so that must be included too. It is something about delivering fast and generally being quick on your feet.

Talk to another group of people – middle managers mainly – and The Method Perspective appears. Those who take the Methods view are concerned with which Agile Method (Scrum, XP, DSDM, etc.) the company is following. These methods are largely composition from the toolkit, ready made combinations of tools. According to this view following one of the methods will deliver the state of Agile.

(I touched on the these three themes in my Objective Agility presentation (PDF) (Objective Agility on SlideShare) a few years ago and a piece of the same name in Modern Analyst – Objective Agility: What does it take to be an Agile company?)

Almost last but definitely not least there is The Learning Perspective of Agile: I continue to believe that Agile is fundamentally an implementation of Organizational Learning concepts. The idea that all teams, departments, companies learn and those who are able to harness positive learning and change in technology/solution, problem/business and process domains will succeed. He who learns fastest wins.

Organizational Learning is present in one form or another in all Agile and Lean approaches but it is seldom front of stage. Indeed to bring it too far forward would be self-defeating. In working with clients I find that taking the learning perspective of Agile allows me understand and approach the most difficult issues.

For me organisational learning provides the theory and underpinnings of Agile. I should stop there, I could carry on but I’d need a book to do this perspective justice – fortunately I wrote just such a book a few years ago: Changing Software Development: Learning to be Agile.

Given these different perspectives the question we need to ask is: “what is not Agile?”

In many ways this is a more difficult question to answer because while any self-appointed authority can define what is Agile nobody has the authority to declare things unAgile, there is no Supreme Court of Agile. Personally I find it hard to see how business process re-engineering, CRM and ERP systems, virtualisation technology and domain specific languages can be regard as Agile but I have seen all of these cited as Agile tools or enablers.

Which perhaps leads us to the final and most cynical perspective on Agile: The Marketing Perspective.

Agile has grown and changed since it first appeared nearly 12 years ago. It has grown and changed in that time, and with no-one to police the brand it has become all encompassing. Come up with a good idea now and marketing demands you brand it Agile and put it under the umbrella.

There is no one right answer to the question “What is Agile?”. Each of these seven perspectives are good answers and they are not, on the whole, incompatible.

My advice is: when someone says they want to “be Agile” or “adopt Agile” or anything else “Agile” it pays to look beyond the label and ask: “what is Agile to you?” and “what are you looking to achieve?” Unless you know the context “Agile” is meaningless.

What is the right size for a User Story?

A question that comes up again and again from teams is “What is the right size for a User Story?” – a day? a week? three weeks? – 1 point? 5 points? 10 points? 37? 100? 5 words? 20 words?

Short answer: there isn’t a universal right size for a User Story, it depends on your team, their skills and their level of domain knowledge.

Long answer: for some teams a User Story is Big, several days or weeks of work. On other teams they are small – maybe a day’s work. Both are possible, both are the right answer. Although, as a general rule smaller is better.

For me there are criteria that a User Story should meet:

  • It should be small enough for the technical team to understand it and create in in a short time period
  • It is small enough to move on the board sometime soon
  • It should be big enough to represent business value in its own right – it might build on something that has been done before (e.g. a lower fidelity version of the same story, the new one increasing fidelity)
  • It is big enough to be deliverable in its own right – you might not want to do so but if you needed to you could
In an ideal environment: the story would be developed in a few days, would be released on its own right and the business value measured directly. (For those who know about Minimally Marketable Features (MMFs), also sometimes called Business Value Increments (BVI) or Quantum of Value (QoV), I casually consider a User Story to be a MMF.)

When a team are dedicated to a particular product, and have worked on it for several years, and have learned about the domain – as I would expect in for in-house development operations – I expect to see larger stories. Conversely, when a team don’t know the domain – as is common with outsourced development – I expect to see small stories, and more knowledge pull from the client.

Taking a step back, a few basics:

  • A User Story is not in and of itself a requirement; I like to call them “Tokens for Work to be Done”, others like to say they are “A placeholder for a conversation” both are true
  • Don’t feel that you must use User Stories: if the format doesn’t fit your need then don’t use it! You can still have a “token for work to be done” and a “placeholder for a conversation” using any words you like, they don’t have to be “As a… I can … So that…”
  • The User Story format does capture three very important elements: Who, What, Why so they make a good starting point and are easy to understand but if they don’t work for a particular need then don’t force it into the format
Small stories are better – they can be developed more quickly, delivered more quickly and return value more quickly. But there comes a point were stories become too small to return any business value at which point they, well, loose value. Plus, when you have a lot of small stories they become a headache to manage.

One common problem I see is teams who create really small stories in order to get them to fit within one sprint. These means large stories don’t get scheduled or teams split large stories into many small ones which have no business value themselves.

People say this is a Scrum thing, I’m not sure. Scrum doesn’t mandate User Stories, the story format came along after Scrum. True the format is widely used they has become part of Common Scrum.

What Hard Core Scrum does say is that all the work the team commit to should be done by the end of the Sprint. Which would imply a story has to be small enough to fit I the Sprint. The problem then comes: what else do you put in the Sprint? If one story is going to take more than half the Sprint you need one or more stories to use the rest of it up. Plus you hit the commitment problem – developers have an incentive to under commit and the business/custom has an incentive to over demand.

My solution – one which I’m baking into my description of Xanpan – is:

  • Stories are split into Tasks during the planning meeting
  • Tasks do not follow any particular format, nor do tasks have any business value
  • Tasks are for the team – the developers, testers, analysts and anyone else
  • Tasks should be small, a day or two at most.
  • A story is not done until all the tasks are done. Stories can therefore flow across iterations, the chances of tasks flowing across iterations is low (because they are small) but they can and do.
However – and this is the key point – in counting the points (velocity) of a team only the completed Tasks are counted. Partially done tasks are not. The only states that matter are Done and Not Done.

As I’ve written before, the breakdown of stories to tasks fills (at least) three purposes:

  • It is superficially an estimation exercise
  • It is also a requirements elicitation process (I like the Requirements Engineer, BA, Product Owner/Manager to be present)
  • It is a design activity.
You know a task is too big because it is difficult to finish. If it is difficult to finish it needed more thought up front, to define and understand it, to bound it, to understand it. (See the mini-series on Story Points earlier this year, and specifically the Story Breakdown entry.)

So there you have it: there is no right size of a User Story.

That said, they may still be “too big” or “too small”. But what constitutes right it dependent on you, your team and how you play the game.

Downside of Dialogue Sheets

Something I’m very conscious of is that I don’t hear much about the downside of Dialogue Sheet Retrospectives. As much as I’d like to believe that this is because there is no downside I can’t honestly say I think that is the case.

There must be downsides.

I have had several suggestions for improvement and some of these have been incorporated into some sheets. There are also a couple of pending improvements which I’ve yet to action. Because there are several sheets and because not all of them are for retrospectives some improvements get incorporated into some sheets but not others. In part I’m happy with this because it increases the differences between sheets.

At XP Day this week I had several conversations about the sheets and I now think its worth listing some reasons people choose not to use the sheets or negatives that emerge. Some of these I’ve known about for a while and may have mentioned before, some are new.

In no particular order, and in my words summarise what I’ve heard….

“The team looked at the sheet and don’t see how they would be an improvement on the current retrospective format”

This reason has been given by several people/teams and while I respect it as a team’s decision to make I can’t help feeling that it pre-judges the sheets. Surely the “Agile” way of doing it would be to try a sheet and see what happens. After all, what have you got to loose? One or two hours, one retrospective.

“We need a facilitator”

Almost a continuation of the previous one another reoccurring comment is from people who can’t imagine not having a facilitator. Again I would suggest try it and see.

I have observed many retrospective dialogue sheet sessions and I find them very interesting. If a facilitator wants a role I have several suggestions:

  • Take off the facilitator hat and join the retrospective, you will get insights for the next time you facilitator
  • Observe silently from the sidelines: you will learn things just from observing
  • Use the sheets from one retrospective as input to the next, go back and pick up items, delve deeper into issues
  • Use the sheets as first exercise in a longer retrospective; do a sheet then go back over issues that arise
You might not need a facilitator but that does not mean you must not have one.

“Facilitator would go deeper”

I am convinced there are issues and times where having a facilitator will produce a better outcome. For example, some issues benefit from talking about in depth. That is why I always thing the sheets are one tool amount many. However I don’t think you always need to go deep. As with the first two items in this list i encourage you to try it and see.

Cross training retrospective facilitators

This might be a rare reason for not using the sheets but is quite valid. One company wanted to train a number of people to under take retrospectives so each retrospective was used as a training exercise for a facilitator.

“We have a company mandated retrospective format and we cannot change it”

This has to be the worst reason for not trying any new technique in a retrospective. If a team cannot change the retrospective format what chance have they got of acting on any findings from the retrospective? Actually I think this suggests a bigger problem.

Mechanical sheet filling

I only have a second hand account of this and I’d like to know more. It appears a team at a large media company in Salford do not engage in conversation in doing the sheet. It appears filling in the sheet has become something of a chore and they simply “do it”.

With out knowing more about this team (anyone know them?) it is hard to say what is going on. It sound like the sheet has been imposed on the team and they are completing it like another piece of administrative paperwork.

Fear of team dynamics

Some people are worried that personality issues on a team will disrupt the dialogue sheet process – conflicts, arguments, etc. I think this is a valid concern. Although I then immediately think of two things.

First: this is an example of a bigger issue – if these people can’t spend an hour together on a collaborative exercise then working together must be very difficult.

Second could this type of exercise actually help with those dynamics? I would guess the answer is sometimes Yes and sometimes No.

Bored by repetition

There are a few teams that have tried the sheets used the them regularly and then they have fallen into disuse. I suspect this is true of any retrospective format that is used too much. The trick is to find whats to keep the retrospectives fresh and keep them generating new insights.

If you know of any downsides or problems with dialogue sheet retrospective then please let me know. I might be able to correct it in a sheet, if I can’t then we can at least understand their use better.

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

Hard-Core Scrum, Common Scrum and Scrum (continued)

Since I published Scrum, Scrum and Scrum on this blog last week the piece has received a lot of attention and I’ve had a lot of feedback: comments on the blog, comments on Twitter and comments to me in person at Oredev last week.

On the whole these comments have been in agreement. My impression is that people find the posting a useful distinction between Synonym-Scrum, Hard-Core-Scrum (or ScrumTM as I’ve also called it) and Scrum-Lite (or Common-Scrum as it might better be called). In this blog entry I’d like to clear a few things up and reply to one particular comment from Kurt Häusler which I think deserves more attention.

Just to be clear: I’m not attacking Scrum here. I’m discussing difference in how it is perceived, what people call Scrum, and where I think “Scrum” is inconsistent (OK, that might be criticism.)

First terminology.

In using the term ScrumTM I am being sarcastic. Nobody owns a trade-mark on Scrum, anyone can use the term Scrum and the ideas in it. So lets stick with Hard-Core Scrum.

Scrum-Lite also seems to upset people, this name was meant to designate a form of Scrum which is not Hard-Core-Scrum. Lets use the term Common-Scrum because this is the way I most typically see the Scrum ideas implemented.

Next the issue of Project Managers, and to a lesser degree Architects and other specific roles on Scrum. Kurt wrote:

‘Anyway, anyone saying project managers and architects are not allowed in Scrum is simply wrong. Are they really saying that though? And are people saying that really representing a different meaning of the term “Scrum”?’

Taking it in reverse order: I am the one who says there are two-forms of Scrum. I think this makes a useful distinction which helps me, and I think others, understand the world we live in.

Kurt’s first question is the more interesting one, if the answer was “No”, if the world did have a homogenous view of what Scrum is the second question, and the distinction would be unnecessary.

So Kurt, the answer to the first question is a most definite Yes. I think the point is well made by Christin Gorman in her 10 minute video on Vimeo from the Roots conference – “Putting an architect in a Scrum team is like putting mayonnaise in a cake.”

Let me say straight away I’m not picking on Christin here, I actually agree with much of what she says and she is not alone in this view. There are other – better known – names who say the same thing:

  • In The Scrum Primer Deemer, Benefield and Larman say “there is no role of project manager in Scrum.” These words are in version 1.1, there is a Version 2.0 on the Scrum Foundation website which adds Bas Vodde to the author list and contains the same words. I haven’t read v2 in detail so maybe in contains more advice for project managers.
  • The Scrum Handbook on Jeff Sutherland’s website contains the same words – in fact the biggest difference to The Scrum Primer seems to be the author list.
  • I personally heard, several years ago, Craig Larman answer the question “What does a project manager do in Scrum?” by saying “If you have a project manager in a Scrum Team you are not doing Scrum.”
The important point is: Christin understands Scrum to mean “No project managers” and Kurt understands Scrum to allow project managers.

I sympathise deeply Christin’s point at the end of the video, if I may paraphrase: “lets save Scrum to mean what it was meant to mean”. I just happen to think this particular cat is out of the bag. Rather than trying to “save” or “reclaim” the name “Scrum” I prefer to differentiate.

Interestingly, as I have commented before (“When did Scrum start loving project managers?”) Ken Schwaber hasn’t always shared this point of view:

  • In Agile Software Development with Scrum Schwaber says “The Scrum Master is a new management role introduced by Scrum” and a little later “The team leader, project leader or project manager often assume the Scrum Master role.”
  • In Agile Project Management with Scrum Schwaber says “The Scrum Master fills the position normally occupied by the project manager. I’ve taken the liberty of redefining the role.”
Now perhaps I’m guilty of not checking my facts. I haven’t e-mailed any of these people to ask where they stand on Project Managers and perhaps I should have. (If any of you are reading this please feel free to comment.)

However, I don’t believe a definitive statement would make much difference. What if I had a statement from one of these people saying “Project Managers are in” (or out) ? There would still be people out there interpreting Scrum the other way. It is too late to change this now.

Personally I believe that overtime those who define what Scrum is – those named here plus a wider community – have changed their position on Project Managers. I suspect that in the beginning there was no anti-Project Manager bias. Then is crept in, and now it is less, or perhaps gone altogether.

The points I want to make are:

  • there is are different understandings of what Scrum is
  • I, and I think others people, find it useful to make a distinction
I really don’t care if you want to say “Common Scrum is not Scrum because…” or “Hard-Core Scrum because…” is not Scrum, because I’m not describing what should be, or not be. What I am describing here is how I find the world.

Comments please?

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.

Unspoken Cultural differences in Agile & Scrum

For a while now I’ve been convinced that a lot of “Agile” is about cultural differences. In particular I believe the canonical version of Scrum, which I often refer to as Hard Core Scrum or Scrum™ is rooted in 1990’s American software management culture.

Unfortunately the role of culture behind many Agile techniques and methods isn’t really stated. This make it even more important to work out what Agile means to you and which tools work in your environment and culture.

I first started paying attention to the cultural differences around teams and Agile after Steve Freeman said something along the lines of “Scandinavian teams just do this, they don’t see much new.” The teams I’ve seen in Scandinavia, and to a lesser degree Holland and the UK, don’t need big lectures in self-organization, left to themselves they do most of it.

I’ve pondered on this for some time and at Agile Cambridge last month I got the chance to talk a little about this with Dave Snowden. We only had a few minutes to talk about this – I was about to present – but it was clear we could have talked for hours.

Take stand-up meetings for example.

When I worked in Silicon Valley I worked in a cube. I hated it. I didn’t even know if my neighbours were in the office, let alone what they were working on or if they had achieved anything that say.

Working in the UK, in open plan offices, usually sitting opposite my co-workers we would certainly know who was in, most likely they would tell me when they had done something.

I believe that stand-up meetings are a good thing in all teams. However I believe they make a much bigger difference in cube and office dwelling environments than in open plan offices. In other words: stand-up meetings have greater benefit in US offices than they do in European offices.

In the original book of Extreme Programming Kent Beck talked of a “sustainable pace” and “40 hour work week”. Beck talks about his experience in Switzerland and contrasts it with the US norm. Although European workers – particularly in the UK – frequently work more than the 40, 37.5 or 35 hours they are contracted for they work hours don’t get excessive for too long. I’m not sure that is the same in the US. Sustainable pace means different things.

Personally I’ve always found “sustainable pace” does not fit well with the Scrum idea of “commitment”. I’ve written before – Two Ways to Fill an Iteration – about the contractions I see. Culturally it isn’t hard to see how “sustainable pace” is easier to do in Europe than the US.

(By the way, I’m limiting myself to the US and European, specifically UK, cultures because these are the ones I have some experience of.)

Now lets talk about the big one: Self-Organizing teams and evil managers.

(Apologies if this comes across as Scrum bashing, I believe Scrum works, or at least Scrum-lite works, and I believe self-organization is best. I just don’t believe hype.)

Some Scrum courses and advocates make a big thing out of self-organization. Personally I don’t. In my courses I I talk about it a little, more if people want to, but I focus on giving people experience of how it works. My style of Agile – yes I’m slowly writing up Xanpan – believes that self-organization is the result of the right approach not a stating point.

Self-organization goes hand-in-hand with an attack on Managers, and in particular Project Managers. Again this theme runs through all Agile but in Scrum is particularly strong. Hard-core Scrum really has it in for Project Managers but then replaces them with Scrum Masters which most companies think is just the same job with a different name. I’ve written about Scrum’s contradictions with Project Managers before so I won’t repeat myself, When did Scrum start loving project managers?

But Scrum’s dislike of managers only goes so far. After all, Scrum is the management friendly version of XP – see Scrum has 3 advantages over XP.

Now I’m not a big fan of Project Managers, in my programming days I too suffered a few managers who tried to hand out tasks and impose their way of doing thing. And I’ve been told No when I want to spend a little money – I once threatened to leave the company if they didn’t buy more RAM for my development box.

When I look back over my career I have to say most of the (project) managers who behaved like this made themselves irrelevant. We worked around them. Certainly removing them would have made us more effective.

But, most of my experience is that managers, even project managers, didn’t behave like this. They may not have been the most empowering of people but generally they left me, and programmers I worked with, to get on and do it. We worked out what needed doing, we divided the work up amount ourselves, we scheduled at the micro-level.

In other words: we did self-organization on a day-to-day level.

Again I think there is a cultural difference here. In my experience America is a more hierarchical culture than Europe (with the possible exception of Germany). Please, I’m not talking class systems here, I’m talking command and control.

I think Europeans are more likely to question their managers to their faces – perhaps it was the 1914-18 experience – or just plain ignore them.

National characteristics are not the only basis for culture. Industries have cultures too. Here again I’ve written before: Agile will never work in investment banking – one reason being that investment banks are very hierarchical.

Most of the managers, even project managers, I meet when delivering Agile training courses and consulting, like the Agile approach and want to work with it for the benefit of their teams. Few seems to be the whip-cracking project managers of folk lore.

Jon Jagger tells a story about one of his clients in Norway. The company was bought by an American competitor. When the engineers started to work together they would convene a teleconference. The American programmers would arrive with their managers while the Norwegians would arrive by themselves. The American’s would ask “Where is your manager?” The idea that the Norwegian could talk and make decisions by themselves was a new idea.

I had a manager in California – Irish as it happened – who used to practice “management by walking around.” Every morning he would appear in my cube and chat. Took me months to realise he was my manager and when I did I wished I had been more guarded with some of my remarks.

This all begs the question, why would American management be such a hinderance to software development? (Note I’m not saying European management is better, that has its own faults, I’m just exploring different cultures.)

For many years the USA was the world foremost manufacturing nature. Part of this success was the superior management practise implemented by the Americans. Such practices made a difference on the factory floor but even here they have been .

I can, and should, write more about managers and their role in the software team. Suffice to say for now: there is an awful lot of bad management out there. I believe good managers, good management practices, can be help companies massively. But on the whole, in the IT industry, there is a lot of poor management.

Bringing this back to Agile.

I think Agile’s anti-management slant is really a reaction to bad management. Hard-core Scrum is the Extreme in this respect. Scrum-Lite, as practiced by most teams, is less so.

Agile, and particularly Scrum, is the product of 1990’s culture, and particularly American work/management culture. Since American culture spreads the fact that Europe never suffered from quite these ills may down to the fact that we were not that good at copying American ways.

There may be a silver lining here: if America adopt Agile, Scrum, self-organization, etc. then we should see it spread out to the rest of the world.

If you disagree with me I’d love to have your comments on this blog. And if you agree I’d love to hear your stories to. Please, leave a comment.

Dialogue Sheets feedback and stories

Retrospective Dialogue Sheets continue to be a popular download, and I’m off to Sweden in a couple of weeks to present the sheets at Oredev. Unfortunately I haven’t had time to review the downloads to extract any useful information from the several thousand downloader details but I do continue to get some interesting feedback.

A few months ago Gail from Siemens Healthcare e-mailed me to tell me how she had used the sheets to conduct a distributed retrospective. The team in India had one sheet and conducted their retrospective in their work hours. Several hours later when the US team arrived at work conducted their own retrospective using another sheet. Gail then gathered the findings and reviewed the two sheets and conclusions which were complementary.

More recently I heard from a Scrum Master at Stattnett in Norway about their use of the sheets. What follows is a (slightly edited) account which nicely describes why many people like the sheets:

“thank you for the sheets! We’ve now used them in two retrospectives, and we will continue to use this technique for the future.

My main reasons for applauding their use:

  • The sheet stimulates equality among team members during the discussions, by the fact that all must be seated around a table (no one standing up and facilitating the discussions).
  • The sheet rules demand at least some contribution to the process from each team member during the session, by reading out questions loud – and also decide for themselves what is needed to read (and not to read).
  • The sheet is very physical and with few/no barriers for participants to express themselves on the sheet for everyone to see – even if it is only by drawing “stick men” on the edge (next time, maybe even the stick-man-painter will write some words on the sheet).
  • The sheet and rules (when followed) prevent the Scrum Master from falling into a “team leaderish” role when the rest of the team gets lazy and wont’t bother to involve in the process – they all have to take their part of a common responsibility for getting through the questions and to the end of the “game”.
…and there are more.

These characteristics make our retrospective sessions less bureaucratic and more inspiring than with our old technique. We have been using the more traditional technique for several years, with each team member preparing notes before the meeting, writing successes and suggested improvements (often as complaints…) on green and pink paper memos.

The notes were then collected on a whiteboard and discussed and voted on at the end – with the Scrum Master (me) as facilitator. This preparation of notes [was rushed] and no one really likes to do this. Going through each and every note was time-consuming duty with debatable value. [In the end] the retrospective meetings became quite uninspiring form for all of us.

But with the dialog sheet, we now have a better, more inclusive and more constructive climate in the meetings. We spend our time on issues of real value to the team instead of ceremony parts no one really likes, and more in line with the original intentions for this session.

The sheet can be put directly on a wall after the meeting, for everyone to see. I don’t have to make any kind of additional summaries anymore (as I did, even if core scrum doesn’t prescribe this). I can instead take a photo of the sheet for the record, if needed.”

I regularly hear that of teams who hang the completed sheet on the wall as a reminder of the discussion and conclusions. I have also heard of a team who hung a blank sheet on the wall at the start of an iteration and team members filled in the timeline as they did the work.

Finally, I recently discovered a blog posting from University College Dublin which used the Dialogue Sheets as part of student retrospective exercise. I don’t believe these are the first College to do so, University of Central Lancashire might have that honour.

Since I learned about the sheets from Cass Business School in London I like the idea that the sheets are going back to college!

Correction: Business Analysts & C3 project

In a couple of blog post, and on other occasions in other places I have talked about there being a Business Analyst working on the original Extreme Programming (XP) Chrysler C3 project.

I’m not sure where I picked this piece of information up but I was wrong. One, Chet Hendrickson of the original team read my post and the team actually had direct access to the payroll team to understand what was needed, agree acceptance criteria, etc.

The Wikipedia entry on C3 discusses a “customer representative” on C3 and indeed Extreme Programme suggests you have a onsite “customer”. Somewhere along the line I read, was told, or just got the impression that this person was, on the C3 project a Business Analyst. Now I see I was wrong.

Having set that, I would still suggest that a Business Analyst can fill the role of customer representative and often have experience and training in doing this. I will accept that sometimes a BA doing this might become a block and it would be better for the team to talk directly to the customers.