The Spirit of Scrum

In the US, where I am, we speak of the spirit of Christmas. And while some people are a bit cynical about it, we think we actually see it sometimes.  It is meaningful.  And people do know what you are talking about.

In a roughly similar way, the spirit of Scrum is also real.

Some people think, it seems, that Scrum is mainly a set of practices.  And that is true, as far as it goes.

But the values and principles behind Scrum are probably more important.  This is related to how we coaches and trainers talk about how a person or a team or a company ‘gets it’.  When we say that, we mean more a real understanding of the values and principles.  Of the spirit of Scrum.

So, today I want to focus on three words: love, camaraderie, and adventure. I think all 3 of these feelings are key to successful Scrum.

By love, I mean the real but hard and tough affection and respect for people.  A willingness to accept both the good and bad about their full humanity.  A kind of love for the people in your team. (Not the ‘I love you, man’ of that famous commercial.)  And a kind of love for the customers.  That, for example, the Team deeply wants their lives to be better.

By camaraderie, I mean the feeling that, as Shakespeare put it, we are a happy band of brothers in war.  (Yes, the ladies are not excluded, of course, and might, in general, prefer a metaphor not so like war.  …a different metaphor for a different day.)  I mean helping each other, working together. And I mean a willingness to be honest with each other (‘I just can’t figure this dang thing out.’)

By adventure I mean the willingness to charge into the unknown of innovation. To try new things (a way of fixing an impediment).  To fail, and learn from it.  And, ultimately, a passion to overcome all the hard realities of life, and still get to the goal successfully.  In all the dimensions of success that are important.  Including treating all teammates as comrades and respecting what the customers really want and need. (For example, not sacrificing quality in a way seen as stupid by the customer.)

Wipe your glasses again, and see and feel the spirit of Scrum. It is in those 3 words; it is more than any 3 words.  It will make you and your team better.

Please try all of Scrum.

Scrum is a bare framework. It is very simple.

Scrum is not trying to be a full methodology.

Lots of people are doing Scrum-Butt.  “We do Scrum, but…”  And then they say…

…we don’t have a product owner.
…we change the length of the sprint often
…we don’t have a Scrum Master
…we don’t do a _daily_ scrum
etc.

I strongly urge you to try all of Scrum.  No Scrum-Butt.

Because I think more success will result. For you, for your team, and for your customers.

A simple definition of the bare framework can be found in the Scrum Guide or in this list.

If, because of impediments, you are doing Scrum-Butt now, this is ok.  Let me just ask two things. Try to fix the impediments.  And tell yourselves and tell others….”well, we are trying to do all of the bare framework of Scrum, but so far we are doing Scrum-Butt…”

Thanks. And I think that will help you and others.

Joe’s Agile Release Planning – New Version

I have posted a new version of the booklet.  Here:

http://agileconsortium.pbworks.com/w/page/57940361/Joe%27s%20Release%20Planning

It is free.  Hope you find it useful.

I hope you will leave comments or send me comments.

Summarizing Scrum (a list)

The more I think about Scrum, the more it becomes a Gestalt…a whole thing.  And it becomes somewhat misleading to talk about its parts.

One must do all of Scrum.  It you only take part of the medicine…well, you will not get the real benefit.

Still, we must talk about Scrum one word at a time. And, for reference and other purposes, we can simplify this into a lost.  A list as a basis for discussion.  One hopes these discussions lead to a better life for you, your Team and your customers.

Scrum was ‘co-created’ by Jeff Sutherland and Ken Schwaber.  Their definition of it, the core definition anyway, is in the Scrum Guide.

I have produced several versions of a two-page list of things that define Scrum. The link goes to my latest version (V5).

This list is based mainly in the Scrum Guide, and also discussions with Jeff Sutherland and much reading and experiences.

The first thing to note is how simple the basic framework of Scrum is.

Secondly, you will note my bias, which is that the ideas behind Scrum are at least as important as the explicit Roles, Meetings and Artifacts of Scrum.

The items in brackets [ ] are things that are not in the Scrum Guide. I believe all of  them are ‘supported’ by Jeff Sutherland if not others.  So I do not feel I am adding unfairly to Scrum. But they are not all required to be doing ‘the bare framework of Scrum’.

Is release planning worth it?

In a word: Yes, if done professionally.

How is release planning, and release plan refactoring…how are they useful?

A few ideas:

• It enables the Team to share ideas
• It allows the Team to see the same elephant
• It enables knowledge creation
• It enables cost, benefit, time trade-offs to become apparent
• It enables everyone to start to distinguish minor decisions from major decisions

Any professional also knows that planning is not and never will be perfect. So, we must put areasonable time box on doing the planning.

It is also useful to plan with good ‘agile’ people. Meaning people who will use the information developed from planning in a useful way (eg, will not do the ‘stupid waterfall manager trick’ of expecting the Team to always hit the date they planned on Day Zero).

Let’s talk about this last one (minor versus major)…

To put things simplistically, there are two types of decisions, which I will call minor and major.  Minor decisions has a minor cost if we make them incorrectly.  If we are clever, we soon learn that we are wrong, and we correct the decision.

But some decisions are major. To change the decision later, it can be very costly in terms of money or time or reputation or some other factor.  Once we identify a major decision, we want to do our best to decide it correctly.  This means first being sure we have framed the decision question correctly.  Then, assuming this is a difficult decision, we want to make the decision at the ‘last responsible moment’.

***

Can planning be useless or worse?

Well, of course.  If you have people who will not learn.  If you have people who will take longer than the current knowledge can justify.  If you too many people who want to use the information for ‘stupid waterfall tricks’.

But if done with good people, using useful concepts, the Scrum Team (and others) can learn a lot doing Release Planning, followed by Release Plan Refactoring every sprint.

It is also true that we can learn by doing ‘real work’.  This is not to say ‘do only real work’…but one balances and shortens release planning (release plan refactoring) in the knowledge that we can and will learn some things faster by doing real work.

Who is Scrum For?

A few months ago someone I know and respect in the Agile community said that they do agile to make the world safe for programmers.

This phrase as stuck with me. I don’t know how seriously the person meant it. I suspect it was partially a joke and partially a stronger statement than one might think.  I suspect it is a real driving force for that person.

And it is true that many implementers have had terrible lives, at least often, and making the world better for them is a very good thing.

But I think we should strive for more than that.

We need to make the world better for everyone.

For example, the customers do not want software (usually), they want something useful that will make their lives better.  The managers need a better life.  The project managers need a better life.  The business owners need a better life. The testers need a better life.

Everyone around or affected by Scrum should be getting a noticeably better life.  And one easily noticed, in terms of the improvement.

This is happening, although it is not happening as much and for as many people as it should. And when it is happening, it is not being noticed and celebrated as much as it should.

Why?

Well, I think one fairly important reason is that too many of us are being selfish.  For example, we are so afraid that the programmer may have to work and be modest and admit failure, that we disable the mechanisms (velocity and demos, for example) that enable the customers and business people to collaborate with the Team.

Anyway: It is an odd request. We want everyone’s life to improve at the same time. No trade offs.

Can it be true every minute?  Well, perhaps not.  But can it be true every sprint, looking back at the sprint in total?  Yes, I think so.