Yearly Archives: 2012

The spirit of Scrum

Posted on by
Reply

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, comraderie, 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 comraderie, 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.

Posted on by
Reply

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.

Summarizing Scrum (a list)

Posted on by
Reply

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?

Posted on by
Reply

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 a reasonable 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?

Posted on by
Reply

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 has 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.

Joe’s Agile Release Planning

Posted on by
Reply

I have written a new booklet that I want you to have (I think you will find it useful) and also to comment on.
E-BookIt is about Agile Release Planning.

It proposes that agile release planning consists of these major steps (at least):

  1. Assemble the Team and some business stakeholders
  2. Agree on the Vision (of the release or maybe more)
  3. Create the Product Backlog
  4. Determine the Business Value
  5. Estimate the Effort
  6. Consider Risks, Dependencies, Learning, MMFS and other factors
  7. Order the Work
  8. Do the scope-date trade-off
  9. Finalize the initial plan
  10. Consider the ‘communication plan’

Note that the purpose of the work is not focused on the release plan itself. The most important purpose is the Team together with the business stakeholders start seeing the same elephant.

So, I wrote a booklet to show and explain how I teach teams to do each of these steps. And to address some of the ‘lessons learned’ in doing this approach in the real world.

I hope you will read it and comment. Please download it here. It is 28 pages.

Two Levels of (Agile) Planning

Posted on by
Reply

Almost all firms that I work with have at least two levels of planning.  We can call them “high level” and “team level”.

Planning

High Level

At the high level, project or product ideas come in.  Someone has to prioritize these opportunities initially, to see which ones make the cut.  Often this is formally done once a year (not our recommendation).  Often this is done by a small group, sometimes called a committee.

Depending on the size of the organization, high level could be for the firm, for the division, or for the department.

The committee considers the benefits and the costs and maybe some other factors. Sometimes the benefits and costs are formally calculated, and sometimes they are just ‘discussed’.

But usually, the committee comes up with a 1 to N list of projects that should be done ‘soon’ (again, often this means in the next calendar year).

Some recommendations to make this more agile:

  • Do it with greater frequency (eg, every month for the Top X projects)
  • Expect the numbers to change over time
  • Make the numbers explicit
  • Do as ‘team knowledge creation’
  • Get feedback
  • Consider how accurate it is, can be, and needs to be

Team Level

We believe every project should go through ‘release planning’ after it has been assigned to a Team.

The Team should do release planning again (it is like what the committee did) for the following reasons:

  • it is being done at a lower level of detail, on only high priority work
  • time has past, so information is likely to have changed
  • the Team needs the detailed information
  • it affects Team motivation
  • it enables everyone on the extended Team to get on the same page

We also recommend that the high level results of the Team release planning should be given as feedback to the committee.  The committee may have questions and may raise issues that the Team neglected to consider.  But more likely, the committee will learn more about how badly they mis-estimated or mis-understood the work.  And this is useful feedback for them.

 

Something unexpected

Posted on by
Reply
Unexpected Gift

What do we do when something unexpected happens?

“The readiness is all”, said Hamlet.

And so must we be ready. Not ready to be fools and become silly. But ready to meet that new thing, that innovation, that crazy idea, that new person…more than half-way.

Yes, we may be skeptical. Yes, as Polonius says (careful grandmother that he may be)…we must try our friends well before we truly take them in. [Note below.] And so we must also for innovative ideas.

But first we must be open to them.  We must take a risk. And try.

As many a Zen Master has tried to open many a student’s mind to satori.

This all comes to me by way of a new friend made last night, rather unexpectedly.  Well, completely unexpectedly. We were forced together, sitting beside each other.  Rather than sit in stony silence (as they say) we talked.  Exactly why or how it happened, I cannot explain.  And, while I deserve little credit for it, it was an amazing and far-reaching conversation.  Very satisfying on many levels.  I will take some credit that I let it happen. And in part it happened because I had no expectations. I asked and said what I wanted to say at the moment…but I was not trying to win or convince or do or accomplish anything.  Well, occasionally I wished to be polite and kind and teasing (as some of you know, I like to tease my friends). But mostly I had no big goal, except to learn and discover.

And later, I was sad. Not sad to have had the conversation, but sad that it had ended.

So, I give myself that credit. And I take it away too. I did not follow up well. The friendship made, the conversation started…  But it may never happen again because I probably have lost contact.  I was too polite.

And this is true of our ideas about innovation as well. We must have the idea, let it in, remember it, and then do something about it.  See if it will fly.

So here and now. A moment to imagine in your mind the blue birds of your happiness. May they fly. Wonderfully.

***

Note: The reference above is to the famous speech by Polonius to his son Laertes, which I have copied here.  Polonius is of course proposing that his son be far more careful than I am suggesting in this post.  I am suggesting more openness, more readiness.  But I am not proposing that we be careless, either.

3 Methods to increase Business Value

Posted on by
Reply

Business Value IncreaseYesterday I enjoyed talking to Southern Fried Agile, the local one-day agile conference.  My topic was this: Three steps toward greater business value.

I was also pleased to see that many participants said they wanted to talk about this subject. So much so that the organizers decided to run the session twice. I am happy that this is considered an important subject. Certainly I think it is.

Some things we already do in Scrum to increase Business Value (or should do):

  1. Better partnership between Business and Technology
  2. Improve the Product Owner (and give him or her this job)
  3. Use a prioritized Product Backlog
  4. Order the Product Backlog to maximize the release of Business Value (over your chosen time frame)
  5. Build working product each sprint (if we get cut short, at least we can field what we have so far)
  6. Demo working product and get feedback from business stakeholders each sprint. Ex: “Did we build for you the most value stuff this sprint?”
  7. Release more frequently

Could we be doing each of those better?  (Ok, sorry for the rhetorical question.)

In the presentation, I suggested three “big” additional things we could do.

A. Business Value Engineering…

This is a framework for continuously getting better at delivering business value. By mapping the process, by articulating the underlying assumptions, by taking a fact-based approach to proving which improvements would be better.

B. Priority Poker

This is an easy thing to add to Release Planning or to Release Plan Refactoring. Or relatively easy. You enable the “5″ best people on business value (in your specific domain) to learn from each other more about business value. By voting “business value points” on each user story.  And the rest of the group learns too.

C. The Pareto Idea

This is classic, and in some sense, almost everyone does it already.  Except they don’t do it enough. And they don’t take it as a basic, everyday, mindset.  So, we fight every day to separate more the gold-platinum-diamonds from the silver-copper from the dirt.

This is a lot of hard work, every day, that we do while we break down the stories into small sprint-sized ones. (I like about 8 stories in a 2 week sprint.)

***

There is much more to all 3 of these ideas.  To be discussed later.  But they attendees seemed to like the ideas. But the real question is whether they got enough to start taking action (if only to learn more).  We shall see, I hope.