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.

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.

In the the world of Scrum & agile there is an ongoing discussion about contracts. Main problem is clash between agile approach of flexibility based on adaptation and the world of RFPs, RFIs and fixed contracts. I’ve seen many good talks and presentations about this, including also on the last Scrum Gathering. One thing I don’t agree with is the way the problem of risk is being handled almost in all of them.

People usually start their talks with the notion that in the basic time&materials contract (the only truly agile contract if you ask me) all the project risk is on the client’s side and other contract types somehow move some of the risk to the supplier. Some go as far as to say that in a fixed bid contract (fixed time, scope & cost) all the risk is on the supplier side.

First time I heard this I thought this is clever, but over time it dawned on me that this “risk sharing” is as much illusory as is the security of the fixed bid contract. Here is why.

The single biggest risk anyone faces when they build something is that this something won’t fit the purpose it was intended for. Causes for this can be numerous: the needs might have been not understood properly or the idea doesn’t fit the market, the needs have changed or the thing built can’t be used because of defects. Finally, the thing being built may be delivered too late for it to be used as intended.

No matter how hard you try the biggest share of this risk is always on the client’s side, because it is the client who won’t get expected benefits in the end. You may add as many penalties and harshly sounding clauses to a very fixed and rigid contract as you want, you still won’t get away from this risk.

Imagine you’ve spent 3 months writing the initial spec, then next two months on RFP/bidding process, then contract negotiation, then two years on developing your complex software system only to discover at the end of all this that the product is not exactly what you intended, is full of bugs and is irrelevant because in the meantime the world moved on (the usual, flawed, waterfall process). What then? Yeah, you can sue the unhappy supplier all the way, but how much good will it do to your business? You can not pay them and even bankrupt them if they were not careful – will that repay all the lost opportunity? Make up for lost time? No way!

This risk is like a boomerang. I’ve heard someone define a boomerang as a piece of wood that no matter how hard you throw away from you will come back and smack you in the face. Very fitting. The harder you try to move away from this risk with complex contracts the more you will be hurt in the end. You don’t need rigid relationship based on distrust to tame this risk, you need an adaptive relationship with people you trust but can check all the time.

That’s exactly what agile offers: tight control of the product being developed in short inspect&adapt cycles. Instead of trying to write clever penalty clauses and waste time on lawyers clients can closely monitor the progress of the team(s) that build their software. They can spot any problems early on and correct them. Or readjust the backlog to changing situation keeping their product relevant. Or change the team.

I’d say there is way way less risk here. What clients pay with for this is their time and involvement – they have to see test builds at least every sprint, they have to speak to the team, readjust the backlog and overall stay on top of their project. But all the time they have all the tools and controls to navigate the project to a successful end. A fixed contract just kills all the outset.

So, next time when people will again define contract negotiation as risk pushing I’ll definitely interrupt them with my little boomerang analogy, because I feel we must all realize this is yet another (paper) illusion.