What we do...

Here is an interesting post by Daniel Glyde, about what his team does at wiggle.co.uk

Scrum, and....

http://danielglyde.blogspot.com/2011/03/agile-software-development.html

Implementing Scrum when not everyone is a believer

How do you implement Scrum in an organization where not everyone is a believer?

Umm. This is a common question and a hard one. And yet also easy.

First, one misconception is that Scrum is a religion that only true believers practice. Scrum is actually empirical. Now, it should be said that Scrum (and lean-agile-scrum) has ideas that are on the surface counter-intuitive, perhaps we might even call them paradoxical. Example: "You have to go slow to go fast."

(I hope you will smile to see the picture of the waterfall model true believer.)

But mainly, we want everyone practicing Scrum to do so out of free will, and with an appreciation that it can and will produce a better result. And, if, after giving it a fair trial, it does not produce a better result, then you should examine the root causes. It just might be that the root cause is that Scrum is 'wrong for us'. Scrum is empirical. We live with reality; we face the truth.

Let me be honest. I do think there are some people in a few of the Myers-Briggs categories who should not be doing Scrum. Because it has too much relative 'chaos' for their personality type....but indeed, for that personality type, there is in reality too much chaos in new product development in general. They also should not be doing new product development.

Still, for most people, if 'scrum' seems to fail, I have never been convinced that it was really Scrum that failed. Typically, at least in my opinion based on what I knew, they did not do it well enough, fully enough or professionally enough. So, it was not truly Scrum that failed. But I might be wrong; I certainly have a limited data set; I have not seen anything close to every Scrum implementation.

Next: Most people who start Scrum are not really all that familiar with lean-agile-scrum ideas when they start Scrum. So, we are asking them to willingly suspend disbelief for some trial period. They are welcome to remain skeptical in a sense, but should make every effort to give it a fair trial. And they will do it 'ugly', as any beginner will. What is quite remarkable, in fact very very remarkable, is that even after only three 2-week Sprints, the Scrum that the beginning team plays is already better than what they were doing before (which they had practiced and used for some years, typically). This is really extraordinary!

Let me emphasize this again, another way. Many of the ideas of lean-agile-scrum are counter-intuitive and for many people will appear to be 'wrong' in many common situations. It is only with experience that the ideas will start to be regularly obvious and intuitive. This is not because the ideas are wrong, but simply because our minds are so used to (wrongly) another paradigm of looking at our work.

Now, sometimes, especially if they feel forced to do Scrum, the team cannot help but sabotage it. They can indeed, in my opinion, make it fail.

So, before the trial project, we should make reasonable efforts to get them to a place where they can give it a fair trial. And feel somewhat comfortable doing so. (Change is always somewhat uncomfortable, so expecting every team to start with 'excitement' is not realistic.)

Some suggestions in this area:

1. Give them training. Example: A Scrum course.

2. Give them a workshop. Example: To do release planning and sprint planning as a team.

3. Give them coaching. Example: Coaching for 3 consecutive days at the beginning of the first Sprint. And then 3 more days at the end of the first Sprint and the beginning of the 2nd Sprint.

4. Talk to them about lean-agile-scrum principles, so they start to understand the music behind the Scrum dance steps. Reinforce this as they experience 'issues' in the real-world implementation of Scrum. ("Talk" can include books and articles.)

5. Do not expect that they will fully understand it immediately. (Did you fully understand baseball when you first started playing it?) Expect them to forget even some of the basics that you told them or they were taught. All lessons, for all humans, must be repeated. The best we can say for people good at change is that we need fewer repetitions of the basic lessons. And do not expect all your people to be good at change. (That does not mean that they will be bad team members....They are good at other things, just not good at change.)

6. Do not let them feel Scrum is the idea of one person. It is not owned by you. It is not 'owned' by one trainer. It is not just Jeff Sutherland's or Ken Schwaber's idea. Many, many, many people have contributed to the idea set. Many, many, many different teams have used it with success. In almost every conceivable environment.

7. Find out what they might propose instead of Scrum. If it is waterfall, help them to understand that even the key people who originally advocated waterfall (the US DOD and Dr. Royce, for example) no longer do so. (In the case of Dr, Royce, his son no longer advocates waterfall.)

8. There are lots and lots of techniques and an endless list of specific things you can do to influence people. See, for example, Fearless Change by Manns and Rising. The list is indeed endless; you never run out of more things you can do. You might exhaust you own patience to continue trying to change someone who seems completely unwilling to change.

9. Remember this famous adage: "People do not resist change. They resist being changed." One meaning: Be sure your 'target' does not feel you have to change him. He should feel as though you are helpfully, fairmindedly sharing ideas that might actually help him in his own life (as he values things in his life).

10. Remember to go with the flow. In Hapkido (martial arts), if the opponent resists going one way, then we use their counter-energy to flip them the other way. There is always a way you can use their energy against them. Assuming you are aligned with the source of energy and truth. Laughter is one of those paradoxically powerful forces.

Remain positive, realistic and undaunted. You are indeed helping the world be better; yet you know it will never be perfect. Be patient with those whose eagerness to change is less than yours. As Yogi Berra said: If the world were perfect, it wouldn't be.

Scrum, Sprint Zero (NO), and Prototyping

I was talking with some smart people at a client. They said: "We do a Sprint -1 where we do rapid prototyping. We do a Sprint every day, produce a new version of the GUI, etc and review it with the customer team daily. It lasts for 2 weeks, or did last time. It is mainly visuals to help us in discussions with the customer about what they really want. Generally low fidelity, generally throw-away code (to the degree it is coded)."

I am, perhaps slightly famously, against the Sprint Zero concept. I will describe that more fully elsewhere. But the basic idea is that I don't like a Sprint that results in no working software. More generally, I don't like a Sprint Zero because it includes (mostly/only) work about which the team can get no objective feedback from someone useful...did it contribute toward what the customers really want?

So, it is mainly the lack of real feedback that troubles me.

So, how does the situation presented by this client compare to this?

To me, the client is doing an excellent job, at least so far as we can tell from the conversation, in trying hard to understand what the customer really wants. In general, I find abstract conversations with customers are of low value, while conversations that include visuals, and include, where relevant, some work flow, can be much much more useful. This seems to be the case.

That they produce some 'working product' DAILY that can be usefully discussed with the customer to get feedback seems excellent. Yes, this working product is not working software as we typically have in a Sprint in Scrum. But this seems far less important in this case than that they are increasing and tightening the feedback loop with the client.

That they call the 1 or 2 week effort Sprint -1 does not thrill me, honestly. It suggests to others that a Sprint Zero concept is ok, even good. That someone speaks of doing a daily 'sprint' within the Sprint -1...well, as an English major I want to quibble about word usage. (Minor really.)

That the prototypes are throw-away does not seem, on the surface, ideal. But maybe quite appropriate.

To me, the main thing is that they are increasing rather than decreasing the feedback. And tightening (speeding up) the feedback loop. This has to be good.

What is less clear (at least from that conversation) is how well the feedback is happening through the rest of the delivery effort. Perhaps more on that later.

Net, net: Some people feel that every accommodation made between Scrum and reality is necessarily not doing Scrum 'right'...although maybe still the right thing to do. It is true that too many people are subtracting from Scrum (which we tend to call 'ScrumBut'). And in almost every case we find that to be....not good for them, really.

But adding to Scrum, and I want to call the above usage of 'Sprint -1' an addition, adding to Scrum is, in general, necessary and typically a good thing. Yes, a Sprint Zero (as described above) would be a bad addition, in our view, but in general additions to Scrum are necessary and useful.

The key is: are the additions made in the context of lean-agile-scrum values and principles. Such as, the principle of increasing the feedback so that the bad news does not get better with age.

Sometimes, two or more lean-agile-scrum principles will come into conflict in a specific case. Then the question is which principle should have precedence.