Scrum picture is quite right

by , under Uncategorized

David Harvey wrote a piece on his blog entitled “The Scrum picture is wrong” where he says that the well known, canonical even, picture of Scrum loops errs by focusing too much on the product (deliverable, “potentially shippable product increment”) and forgetting that continuous improvement of the team is another important outcome of each sprint that should be shown with another loop.[Go and read David’s piece now if you haven’t yet]

As much as I agree with David’s insight I don’t think his version of the Scrum loop should be used to “sell” Scrum outside of our community. I very much value all the focus on teams and their improvement, but it helps to understand that this is something that is important (and should be!) only for us, sitting deep in the software development community. Clients ultimately pay for products, not for our methodologies, our teams improving or our overall well being and happiness.

Let’s take the case of outsourced development, which I know firsthand. Our clients pay us for the product they get from us, but once the project is done they are gone and I don’t think my team getting better on their project is something that even crosses their minds. And why should it, anyway? Unless they would want us to extend their product or start another project with us there is no benefit there for them. What really counts is whether the product we delivered will allow them to meet their business goals, their commitments – and their bottom lines. So when I work to convince them to forget fixed bids and go with Scrum I don’t waste the attention they give me on telling them that thanks to Scrum my team will get better.

But also if you have your own, in-house teams, building your product then in the long term it is that product that counts more than the teams. Why? Well, because not only your clients don’t pay for your teams, but for the product – you also don’t really own your teams. People change jobs (one call from Google’s recruiters to your best people can make your life very hard, believe me), get sick, even die – that’s inevitable. And (as I have learned the hard way) pampering your best people won’t prevent them from quitting – so is probably not worth it. In the long run – measured in years – it counts how much value your clients get from your product, not how perfect your team has become. If your team is getting better with every sprint but your product doesn’t sell you will hit the bottom hard sooner or later. Yes, your company may be then one of those legendary places that excelled technologically but are no longer around (Commodore, SGI etc.) which may be fine for the employees – they will just change jobs – but is not fine for owners and/or investors who will have to cover the loses.

So, team getting better is a tool, a mean, to get a better product, not the other way around (unless you run a monastery – there indeed work is just a tool for monks to perfect themselves spiritually).

Just to make sure no one misunderstands me: I’m not saying we should forget about team improvement, not care about our workers’ well being, career development etc. Yes, we should do all that and more, help everyone excel in what they do, make sure as much as we can people like what they do, heck, do it with passion and care, using fully their potential. All that is important and valuable. But we should not forget that in the end it is the client paying for a product who makes it all happen. And all our methodologies, frameworks and diagrams, all our “management science”, all techniques and research is aimed at improving efficiency – and that means, sorry to be blunt, getting better products faster and cheaper.

So I think the current Scrum picture is quite right in its focus on the product. And the message is spot on. It should be still used to “sell” Scrum to managers, clients and businessmen. David’s diagram is insightful and fine, but let’s keep it within our world of process freaks, agile activists and scrum preachers.

  1. Marcin Raczkowski

    Problem is, you can’t have good product without having good team, it’s simply impossible for a bad team to produce good product, and I think at least some people know it, so showing that methodology is making team better can actually be quite good selling point.
    People are creatures of habit, and they usually they need very strong incentive to change job, clients are also very rarely change subcontractors, every freelancer knows that 80% of job comes from returning clients or referals. Most clients sooner or later want to extend product, or create next one, so in their vital interest is for team they hire to get better (especially if hourly rate doesn’t change).

    Getting better products faster and cheaper is a directly corelated to skills of your team, and I’m talking about team as a whole, you an easily survive 1 person from team of 5 quiting (even if it was leader), but when 3 quits, you’re screwed, you’ll have to rebuild a team, and that always takes time and resources – sorry to be blunt, it’s much cheaper to pamper programmers then to pay them as much as microsoft does.

  2. Andy

    Hi Marcin! Thanks for the comment, but I see that (as it has happened before) you simply didn’t understand my point.

  3. streser

    IMHO people often changing their job because sometimes they need change something in their life, they are unsatisfied, sometimes they have long term plans or dreams which they need to realize. If they are really determined no one and nothing can’t stop them. It is natural employee evolution. Almost everyone (especially in IT) strive for perfection, and changing job is (should be) natural step forward on our way to success/satisfaction. Money isn’t everything, self improvement, low pressure, confidence, safety are important too.
    We should see difference between pampering and motivating employee. If you mean “motivating” when say “pampering” you are wrong, cause unmotivated team never supply good product, They will work 8 hours per day and no more, when their are not motivated they wouldn’t be productive. When team is motivated they spending more time at work and/or their are more productive.

    Off course you have right when you say that frameworks and methodologies themselves not upgrading product quality. But you should remember that their had been invented to help PEOPLE to improve their products quality, to make them work faster and easier. At the end behind all this thing we see people (clients, employers, boss, users etc.) and relations between them are most important.

    When you working with scrum or another methodology you need remember that you selling product not methodology as you said, but you also should remember that you selling people to.

  4. David Harvey

    Hi Andy,
    Thanks for your thoughtful and well-considered comments. A couple of comments in reply.

    Firstly, I think we make life difficult for ourselves if we misrepresent the organisational challenges to adopting agile. It’s like the old joke about how many psychotherapists it takes to change a lightbulb* – if your organisation isn’t ready to respond to the pressures for change generated by a well-functioning agile team, you’re storing up problems for your teams and organisation both. I’ve seen the friction generated when an executive decision to adopt (say) Scrum wasn’t followed up with effective action to resolve the issues exposed when agile teams rubbed up against parts of the organisation that weren’t.

    Secondly, one of the main points I was trying to make is that the Scrum picture, because of its ubiquity, is how we represent Scrum to _ourselves_. We may “know” and “say” that we value team and individual growth but the picture – when we stick it on our walls, put it in slides, draw it on whiteboards – subliminally reinforces the message that all that’s important is the product. That message changes our expectations and behaviour. Psychologists call this “priming”: it’s a surprising and well-documented effect.

    Once again, thanks, for the thoughts. I’ve put a link to this in the comments to the original entry.

    (* I really don’t believe you don’t know the answer, but: one, but the lightbulb must really want to change)

  5. Andy

    Hi David! It is good to be understood. 🙂
    I think we have to draw a line between how we present Scrum (and Agile in general) within our community/industry and outside of it. So, as I wrote, you’re 100% right about team getting better being an important product of Scrum but I wouldn’t use it (in most cases) to sell Scrum to a client or a corporate boss.


Leave a Reply