Andy's Mind

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.

To wrap up my coverage of the last Scrum Gathering in Munich a couple of words about the last day and then some general comments.

After the lame keynote session on Tuesday I decided to sleep in on Wednesday and I missed Harvey Wheaton’s talk. It didn’t appear particularly interesting on the mini-agenda we were given, looked like another boring life story. My friend Tomek went in, and thanks to him I know I’ve missed a very interesting talk, a real world experience of implementing agile & Scrum in a startup company run by Harvey. Well, next time I’ll be in for Harvey’s talk.

Another session I attended was supposed to be about agile contracts by Peter Stevens. To the surprise of both speakers this talk was squeezed into the same room and time slot with Regina Mullen’s talk. In effect both had time to speak, but not to take many questions from the audience (crowded, as usually, on chairs and in between). Peter’s talk was a mild disappointment for me. I had a chance to talk to him a few times and I read his blog, so I know he knows a lot more about agile contracting. Maybe he just decided to cut his talk to leave some time for Regina. In any case, I didn’t learn much stuff that I would not know before, but I think it must have been a good introduction for the first-time attendees. One thing I’ll remember from this talk is his story about Zurich trams contract. And it also reinforced my resolution to finally write about my take on risk in client-vendor relationships.

Regina’s talk was, on the other hand, an unexpected, entertaining diversion for me. Though she did include her life story into it (like way too many speakers at the Gathering), she did it in a gracious and humorous way and her thoughts on making lawyers use agile were quite interesting, even though I’m clearly not in her target group (IANAL). Nice talk, I just hope she has a chance to present this to lawyers and indeed change their ways. Part of the challenge throughout my career in the IT world, especially as a manager in the last couple of years, has been finding lawyers that would really understand what we are trying to do before helping us draft contracts, user agreement, licenses and so forth. We need more people like Regina there – I definitely would love to talk to a lawyer who does know outright what a sprint is.

After lunch the best regular talk to attend was probably one led by Nigel Baker (I suppose so, as I know Nigel – it’s not possible to get bored when he talks), but tired of all the Scrum politics over lunch I decided to go to the haiku workshop led by Liz Keogh. I was amazed by the results. I really did learn something new I didn’t know before, and it was really easy. It took Liz a couple of minutes to get us to write haikus, and since then they keep on popping up in my mind on their own. Two examples of the ones I did and really like:

Worn green carpet
carries us all patiently.
Thunderstorm!

Engulfed in our own little worlds
between iPod earbuds.
Autumn leaves.

(Haikus composed during the workshop and sent in afterward can be read here).

I resolved to try and write at least one per day. I think they are more than a diversion – they are a great tool to awaken our pattern-matching R-mode processing (read Andy Hunt’s book for more on L&R-modes). Haikus being by definition based on surprising matches can increase creativity by encouraging the R-mode “search engine” to produce more unexpected matches, useful not only for more haikus.

The event ending session was a big surprise. I expected some energizing talk, so I took out my camera to record it. Instead what happened was that after some small talk and a round of due thanks to different people by Tom Mellor a “wave” exercise was performed. It was so jawdroppingly stupid I thanked God I had my camera out so I had a good excuse not to participate in this idiocy without attracting attention. I kept on recording though and I wonder now whether I should put up this video or not, as I’m afraid it could only damage the reputation of the Scrum Alliance.

Interestingly, most people I talked with afterwards agreed it was stupid, but during the round after the “wave” they said BS like “powerful” or “energizing” – only me and one other guy were honest enough to say it was “silly”. To me it was a clear example that whoever was supposed to lead this session just didn’t have anything meaningful to say, so came up with this thing instead.

I think this failure illustrates a deeper problem Scrum & Scrum Alliance has. Scrum is part of the IT industry’s response to the failure of traditional, waterfall based project management in software development that that is called “Agile”. Scrum is a simple framework for managing requirements, work and team during software development projects. Yes, it doesn’t say anything about “software” as such, but this is where its roots are. In other words – it is a way to manage projects (because, I’d argue, Scrum projects are still managed, even if there is no Project Manager as such) created in our industry.

Now we have to decide – is Scrum just that or is it something more? Should we focus on merging Scrum with technical practices in teams and keep focus on software (which is what Ken Schwaber seems to be doing with his new training program aimed at developers)? Or should it be treated as a industry-agnostic project management methodology that could take on PMBOK, Prince-2 and other heavy methodologies everywhere? Or maybe should it be part of the soft-skills portfolio for coaches, HR etc. together with “waves”, collaborative drawing etc.?

The problem here is that traditional management methods work quite well in heavy industries they evolved in, and there are lots of very good people in the soft-skills department – usually better than ex-software developers discovering their “emotional intelligence”.

In any case a choice must be made before Scrum dissolves into mist. Ken, Jeff and Mike did agile movement a great service by laying out Scrum as a clearly defined, tangible thing as opposed to agile’s vagueness. Scrum was something anyone could start using and derive benefit from following its simple rules – because even ScrumButt was giving more productivity than waterfall. That’s why it was so successful – exactly because of its sharply defined edges and simple clarity. Now this clarity can be lost amidst empty motivational talks and silly exercises lifted out of kindergarten.

I know what I wrote will be harsh for some, but well, that’s what I think. And being a nobody in this movement, a nobody living in a place most of you never heard of I can afford the luxury of being honest. And of course one thing will stand: Scrum itself and other agile methods and practices. No matter which Alliance trademarks what you can use them and be better off in your projects.

To close on a more optimistic note some appreciations:

• Thanks to Boris Gloger and his team: they not only provided real, freshly pressed juice and real, freshly brewed coffee but also filled in where organizers couldn’t in a truly agile fashion. Their idea of just copying the materials on pen drives and handing them to people at the end was brilliant. Plus he paid for the beer on Monday.
• Tobias Mayer: another true agilst, when everyone complained about the lack of Open Spaces and the board said they will make them next time Tobias singlehandedly organized “guerrilla Open Spaces” the very same day greatly enhancing the Gathering experience for many. Also, it is Tobias who told me to go to the haiku session instead of political discussions – thank you!
• Howard Sublett and Cory Foy: Scrum Alliance needs more of you guys, not just 5 hours / month.
• Stefan, Robert and other German friends who helped me find my way around Munich and explained some customs during the beer evening.
  Everyone I talked with during the breaks.

Overall, I liked the event as a whole, I hope next one will be way better – and that clouds over Scrum Alliance’s future will be gone by the time we meet again “somewhere in Europe”.

(There will be one more post in the Scrum Gathering series – about Scrum Alliance as such).