Andy's Mind

Scrum community is now debating – how Scrum Alliance and Ken Schwaber and certification programs and trainers and all kinds of related stuff will play out or should look like. In the meantime Scrum is in a real danger, which I don’t think is being noticed.

This danger for Scrum and community that grew around it over the years is not in the politics and debates, but in their fallout and the “me-too” frenzy (everyone desperately wanting to write and speak about Scrum and contribute or – more frequently – appear to): Scrum risks being diluted in the babbling of multiple voices each presenting his own version. If anything can be called Scrum and if things ranging from metrics to back rubs can be claimed to be part of Scrum, then Scrum ceases to mean anything.

Why it is a danger? Because Scrum’s biggest advantage over the years has been that it was a very definite, distinct method. Scrum meant three defined roles, three defined meetings (later expanded to four by adding retrospectives), two artifacts and a bunch of rules. There were Ken and Jeff and the organization they created defining what it is, there were trainings available and certificates (no matter how weak) backing them. It was therefore a “product”, something you could take, apply in your company and even check if it was done right.

Figuratively speaking Scrum was standing out like a rock in the cloud of “agile”. Agile is a philosophy, an approach – Scrum is something that is rooted in this philosophy you can take and use without becoming a philosopher.

And that clarity was, I think, the important part of Scrum’s success – the reason why most agile teams use Scrum now (or at least try to). If Scrum looses its focused clarity it would slide back into obscurity and irrelevance, back into the agile “cloud”.

Ken was trying to fight Scrum being diluted with his campaign against ScrumBut, and he is still doing it. Scrum Alliance is, as far as I can see from the lineup for the last Scrum Gathering, sliding towards doing everything agile, even everything “soft skill”. This is what community seems to like, maybe being bored with “pure” Scrum. But it is not what businesses will like when looking for methods to use to improve their processes. Businesses need solutions delivering results, philosophies they are less keen about.

In the meantime PMI is still the winner in the business world because it is still seen as a respectable provider of serious, business centered methodologies – and “fad boys” of the Internet Web 2.0 community are already abandoning Scrum in favor of Kanban or Lean. This may be good in the grand scheme of things, but if Scrum community wants to stay relevant it should refocus on providing the clear cut “product” Scrum was until recently.

To that end healing internal animosities, abandoning “soft skills” (including pure nonsense like my “favorite”: back rubs on daily scrums) and shelving dreams about conquering other industries would definitely help. Scrum practitioners and trainers should focus on helping teams deliver great software using Scrum – focus on what we should be able to do best, on our “core” and make sure we really succeed there.

Someone has sent me a link to a quite emotional but interesting article by Tim Bray on why the world of enterprise systems delivers so many failed projects and sucky software while the world of web startups excels at producing great software fast. Tim makes some very valid points about technology, culture and approach to running projects. It is true that huge upfront specs, fixed bid contracts and overall waterfall approach are indeed culprits behind most failed IT projects, and that agile, XP and other key trends of recent years can help.

However, I don’t think they can really cure the problem, because we are facing a deeper issue here: the overall overcomplexity in our civilization.

Main drivers of this overcomplexity are bloated states and economy dominated by corporations. Both states and corporations have IT systems today – and the complexity of those IT systems has to reflect the complexity of organisms and processes they try to cover.

The IT system for a national health care system or a state run compulsory social security “insurance” is a very good example. It must be a complex mess because what it is trying to model and run is a complex, overbloated mess – in most cases a constantly changing mess. And it can’t be launched early because it is useless unless it covers the whole scope of what it is supposed to do: because most of what it covers is regulations and laws you can’t deliver a system that meets half of the regulations or 10% – it can’t be used. By the very nature of the domain the system has to be launched as a finished whole.

Plus, on top of all that, comes the scale. If you can imagine a completely privatized health care no system will ever cover all citizens – each doctor, hospital, insurer etc. will cover just its clients, a subset of the population. A system like NHS has to handle all of the UK’s population by design.

Same problem with corporations, especially those that have been around for long (by long I mean decades, not years): scale and mentality. You just can’t manage 75 thousand people easily, especially if they are spread around the globe, in a simple and agile way.

Just think of all accounting requirements global corporations have to handle with their IT systems – but this is just the tip of the iceberg. Whole world economy floats in a sea of legislation – legislative diarrhea of the last decades produced a legal swamp which is a nightmare to understand let alone model a system to comply with it. For a global corporation multiply that by all the countries it is in and stick some international regulations on top of this. This is something corporate systems have to cope with.

What is also important – much of that overcomplexity is computer driven: it would not have been possible if not for the existence of IT systems and computers that run them.

Take VAT tax – it is so complex I always wonder what idiots gave the Nobel prize to the moron who invented it (well, I used to wonder about that when Nobel prize had any credibility). Clearly, implementing it is completely impossible without computers & systems everywhere.

Same about the legal diarrhea I mentioned – I think it can be largely attributed to Microsoft Word. Ever wondered why the EU Constitution (now disguised as “Lisbon Treaty”) has hundreds of pages while the US Constitution is simple and elegant? Well, they couldn’t have possibly written a couple hundred page document with a quill pen which forced them to produce something concise.

But going back to the key issue of whether the corporate IT systems can be better: they can, but a deeper shift in thinking is needed. Instead of creating huge, complex systems corporate IT should rather be a cloud of simple, small systems built and maintained to provide just one simple service (exactly what web startups are doing – each of them provides simple a service, together they create a complex ecosystem). However, this shift would have to occur on the organizational level too – large organizations with complex rules should be replaced with small, focused entities with simple rules for interaction between them.

But to get there we would need a world-wide “agile adoption” reaching well beyond IT. But that means a huge political change, that is nowhere on the horizon. Unless, of course, one other enabler of our civilization’s overcomplexity fades: cheap, abundant energy.

As agile software developers providing outsourcing services we are frequently asked to sign different NDAs and MNDAs. After over two years and dozens of NDAs I noticed a certain pattern which I will call “The Law of NDAs”.

It goes like this:

“The originality and value of the idea protected by an NDA is inversely proportional to said NDA’s length, penalties involved and insistence on signing it.”

In other words, on average, the more harsh and menacing the NDA is the less original and innovative the idea supposedly protected by it turns out to be.

Interestingly, not only average NDAs and ideas fall under this law, but also do extreme cases. For example, I remember one guy who had a 7 (seven) page long NDA to protect his revolutionary idea that turned out to be yet another social network (which, as far as I know, didn’t in the end see the light of day). Conversely, we had a group of high-profile European entrepreneurs who shared with us their truly revolutionary idea (related to multimedia) without even asking us to sign anything.

One may wonder why it is so, but for now I’m satisfied with having observed the pattern. Has anyone else noticed it?

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.