Sunday, August 28, 2011

You've got to find what you love (says Steve Jobs)

There was an excellent article in the Wall Street Journal on August 24th.  About Steve Jobs. It gives the text of his commencement address at Stanford in 2005.  A quote from his talk is: "You've got to find what you love."  This is maybe the punch line of one of the three stories he tells.  Please go read the address

I think this is a wonderful idea.

I don't know much about Steve Jobs, just the obvious stuff.  Maybe he is sentimental, but I don't think so. (I do salute all he has done. Some failures, but I mostly remember all the successes.)

What I do find is this:
* life is wonderful, and a wonderful gift. (Ok, not always, eg, when Hurricane Irene has just beaten you up.)
* far, far too many people are doing things that they don't really want to do.  Things they only feel they somehow must do.
* life is short.
* why not live full-out today?  As best you know how.

None of these is a terribly original idea.  No doubt you have heard each one before. But I tell you, they are compelling to me these days. Perhaps you can see a logic, of a sort, in how they are connected.

Let me tell you a story.
The other day I was with a small group, getting ready to practice Hapkido (a Korean martial art, like Aikido roughly).  A few friends were talking. One guy was talking about how he was working with this 23 year old girl, who did not understand money and credit cards. Absolutely no understanding. She has 15 credit cards, and an enormous debt on them, compared to her earnings (which are probably meager, compared to you).

The guy who was trying to help her said: "I am trying to teach her the practical realities of life."  And my immediate thought at that instant was: "No, money is not practical. What is really practical is changing her spirit.  That is what she will live and die with. When we die, we leave all the money and stuff behind...it has no practical use then. When we die, the spirit is all we have."

Not sure I have stayed convinced, since then, that spiritual work is the most practical.  I doubt, if you are a skeptic, that my story convinces you.

But I will suggest this, perhaps more seriously.  If you work and work at something you love, you will be more successful at it than at anything else.  By whatever definition of success you give yourself.

To make this just a tad Scrum specific: Product Owners, it is for you to help them feel, if they will, that what you are proposing they do will in some important way fulfill their lives. At least for the time they will work on it. You hold their lives in your hands...well, at least their lives for those days and weeks and months of that effort. Don't waste it.

Why should a Product Owner care?  On the beautiful Sunday that I see as I write this, one can think of many reasons.  But, to deal with the skeptics, let me quote Little's Second Law: "People are remarkably good at doing what they want to do."  And the more they want to do it, the better it will be.

***

Let me end with another quote from his talk:
"The only way to do great work is to love what you do....Don't settle....Don't settle."

Thursday, August 25, 2011

Joe's Approach to Release Planning

Here's what I think Release Planning should comprise.  For a 3-6 month release, most teams could do this in about 1-3 days.  With good enough quality to then start sprinting the next day.

I want to say quickly that we don't just do the initial Release Plan.  We also do Release Plan Refactoring every Sprint. (And possibly some Sprints there are no changes.) The adaptiveness of agile release planning is perhaps its most essential aspect.

I will explain release planning more in later posts.

I do NOT guarantee that release planning is needed in all situations, nor that the approach will work in all situations.  Still, I have done this now with many many teams, and it seems to have worked with all of them.  My experience is that everyone I have done this with has liked it after they did it.  And thought it was worthwhile.  And actually did almost all of it (and almost all that it implies to me, but is not stated here).

  1. Vision
  2. Product Backlog
    • Roles
    • User Story Workshop
  3. Business Value
    • What is BV for this project?
    • Priority Poker --> BV points
  4. Effort
    • DOD
    • Planning Pokers --> Story points
  5. Risks, Dependencies, Learning, MMFS, Other
  6. ORDER THE WORK
  7. Make scope-date trade-off
  8. Calculate the budget for the release (usually a simple calculation)
(Note: MMFS stands for Minimum Marketable Feature Set. See Software by Numbers by Denne and Cleland-Huang.)

Then we have to talk about some other things, and see where we go.  For example, sometimes we find that the skill sets needed are different (now that we see the product or project more clearly).

Then we have to do Release Plan Refactoring every sprint, until the plan is more solid (sometimes it is always being improved). 

As I have said elsewhere, the real value in doing this is NOT the 'crappy' estimates that the team arrives at after the initial release planning.  It is that everyone is now 'on the same page' about what the elephant is.  At least a whole lot more than we ever had before.  And I and most others find that tremendously valuable.

Note: If they do really bad or no release planning, I think it increases the chances a lot that the stories are not small enough.  This means that lots of stories just can't get to done, done in the sprint.  So, in that and other ways, good release planning is linked to having good sprints!  Now, this problem (stories too big) can be fixed later, but god, all hell is breaking loose then. Do Scrum professionally from the beginning.

***
Other posts on Release Planning:
http://agileconsortium.blogspot.com/2011/03/scrum-and-release-planning.html
http://agileconsortium.blogspot.com/2011/07/why-release-planning.html
http://agileconsortium.blogspot.com/2010/11/release-planning.html
http://agileconsortium.blogspot.com/2010/09/release-planning-early-warning-system.html
http://agileconsortium.blogspot.com/2011/08/release-planning-with-business.html 
http://agileconsortium.blogspot.com/2011/08/joes-approach-to-release-planning.html
http://agileconsortium.blogspot.com/2011/09/release-planning-business-value-points.html
http://agileconsortium.blogspot.com/2011/06/planning-poker-1.html
http://agileconsortium.blogspot.com/2012/04/release-planning-vision.html 
http://agileconsortium.blogspot.com/2012/04/release-planning-product-backlog.html 
http://agileconsortium.blogspot.com/2012/04/release-planning-business-value.html 
http://agileconsortium.blogspot.com/2012/05/release-planning-effort.html 
http://agileconsortium.blogspot.com/2012/05/release-planning-effort-2.html
http://agileconsortium.blogspot.com/2012/05/release-planning-product-roadmap.html
http://agileconsortium.blogspot.com/2012/07/release-planning-risks-dependencies.html
http://agileconsortium.blogspot.com/2012/08/release-planning-completing-plan.html

Joe's Unofficial Scrum Checklist

Henrik Kniberg did a Scrum Checklist a while ago.

Occasionally students at courses ask me for a similar thing.

One always wonders: what are the most important questions to ask? What are the most important things to consider?

Nothing that is somewhat short can address all the issues one finds in the real world, with all the different teams one encounters.

So, with that in mind, with some thoughts about Henrik's good work, and other issues percolating in my mind, I wrote a new version.  Based partly on Henrik's work.  And purposefully not as pretty. (An admission: I used to be a Big 6 consultant and was forced to produce 'pretty' presentations. And my rule was: "The prettier the presentation is, the stupider it is." I guess in part because all the ideas are pre-digested. Anyway, that is my bias.)

Here is my version 1.1:

http://agileconsortium.pbworks.com/w/page/44303272/Joe%27s%20Unofficial%20Scrum%20Checklist

Remember that the purpose of Scrum is to make you think for yourself (well, as a team), not to lull you into not thinking.

Use common sense (the most uncommon of the senses).

I welcome your feedback.
Hope you find it useful.
Enjoy!