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!

Sunday, August 21, 2011

Release Planning with Business Stakeholders

 I just posted in the Yahoo group Agile Business the following (slightly edited):

***
The past 3 (business) days I worked with a team in Atlanta to do release planning with the Business Stakeholders.

And the business stakeholders were external customers.

I was extremely impressed with the results.  I strongly recommend it.

Situation:
* 15 people (6 pigs, 3 consultants, 6 external customers).  Plus me.
* Very beginning (well, not quite, but no prior product backlog at all....'they' had had some discussions and some ideas about a vision).  The PO had some ideas about releases, and some ideas about how his company could see a business opportunity vis-a-vis the competition.
* One day spent 'level setting' with all: what is scrum and what is agile estimating and planning. I called this a one-day 'Scrum' course.  Some were brand new to lean-agile-scrum. Some were very experienced with Scrum.

Results:
* 3 releases scoped out
* Pretty good Prod Bklog for Release 1.  Less good for R2, R3 -- but still fairly decent.
* Each story had BVP and SP (BV points and Story Points). Well, in R1.
* Vision: done
* Some good discussion about Infrastructure, Architecture and Design (as I call it). But not finalized.
* Work 'ordered', eg, including risks, dependencies and other stuff.
* Good discussions around notions of CBA (cost-benefit analysis) and Pareto (doing 20 to get 80). Everyone seemed to 'get it' in a useful way.

* Good acceptance of adaptive planning ideas (that this was the first pass, and it would evolve)

* Everyone felt fairly happy but 'brain dead' after 3 days.

Some Learnings:
* I will share if you are interested.

Questions or thoughts?
Happy to share more (up to a point) if you are interested.


***
It is a rough post. But I am excited about this and wanted to state it here also.  Comments welcome.


Saturday, August 20, 2011

Better Retrospectives

In Scrum (and in life), we have periodic retrospectives.  In Scrum, we have a time-boxed Retrospective meeting once each sprint.

Why?  Well, the main reason is to get better without working any harder.  Put another way: mainly to remove impediments.

I hear about far too many Retrospectives where we get to have a lot of fun bitching and moaning. And then the action is none or very weak. ("Ok, I agree to stop blowing my nose when we're having a conference call. Ok.")

Some suggestions:

1. Get more creative about the biggest impediment.  It can be ANYTHING that is really slowing down team velocity. 

As an aside: Velocity is something important, but not everything.  If you're going 90 mph in the wrong direction, you're still going in the wrong direction, for example.

I find it is hard for most teams to put the biggest impediments on the table. 

So, we must challenge ourselves. "If we wanted to double our velocity, what would have to change around here? Let's assume for a moment we could change anything."

2. Pick the biggest impediment.  The Team might swarm around this question for a few moments. If they are not decisive, then the ScrumMaster must be.

What is the main priority? What, if fixed or mitigated, would improve our velocity the most?  OK, then we can add cost-benefit analysis, and say: What, on a bang for the buck basis, will lift velocity the most?

3. Work out a proposal on the biggest one.  Proposal could be business case or action plan, or a few other things.  Basically: either get a good idea how to fix it, or a good idea how to convince the right manager to help fix it.  Maybe help means "give us some $".

I particularly like the Lean A3 approach to kaizen.  (Oh yeah: Removing impediments is basically kaizen.)

4. Fix only one thing at a time.  Don't get several improvements in flight.  Usually.  Too confusing.  Focus and get one over the  goal line.

5. After the Retrospective, the SM must make sure someone is always taking action. Every day.

6. Report back to the team the results from the actions.  (I think teams are generally realistic.)  Who knew the team would actually like to hear about the results.

***

Do those suggestions help?

Monday, August 15, 2011

The Biggest Problem

Jeff Sutherland believes that the biggest problem with Scrum teams, the most frequently encountered problem, is that the Team does not have working product at the end of the Sprint.

This is fundamental to Scrum.  And, in my view, fundamental to being successful.

So, why is this so important?

The first thing I want to say is that working product enables the empirical process, it allows the people to inspect.  And, having much better information, the people can then adapt far better, or are certainly more likely to.

One way of saying this is: "In theory there is no difference between theory and practice. In practice, there is."  Which, in one interpretation means: The creative people who work on new products always think they have a good idea.  It is only when one asks them to make it work in the real world, that one finds out all the problems with the ideas.  It is typically in the real world of trial and error that we learn the most.

Looked at another way, working product enables us to measure progress far more effectively than, say, the documentation deliverables that were used in the waterfall days.   One reason it is important to measure progress is to get a better prediction on when the product can be put in the field. A very important business decision (and very important to all customers, who always want it yesterday).  As we can see plainly in the tablet market just now.

Going a bit further, it is good if the Team has a better prediction of how many 'stories' it will complete with done-done product.  This enables the (mostly Technology) Team to build trust over time with the Business side.  Which means the Business side will become more willing to collaborate with Technology to solve the difficult trade-offs in new product development.

Some steps toward fixing the problem

There are other reasons for having working product at the end of each Sprint.  But let's now turn to solving the problem.  How does your team get better at doing it consistently?

First: are you convinced yet that this problem is important enough to aggressively attack?  I hope so, but maybe not.  If not, then stop and try to 'smell' how important it is.  If you cannot feel the importance, your actions will be ineffective.

None of the following suggestions is a silver bullet, but in our experience as a coach, many teams can benefit from each of them.  You will have to judge which ones will help your team the most.

  1. The Team understanding better why working product is so important. (See, for example, our comments above.)
  2. Smaller Product Backlog Items (PBIs) or user stories.  My standard is about 8+ stories in a 2 week Sprint, all of roughly equal size.
  3. "You have to go slow to go fast."  One reason: If you understand this principle, then you understand why the Team should invest the time to get to smaller stories.  Smaller stories are extra work, but the extra work is worth it.
  4. Better Release Planning.  The main reason this helps is that we have smaller PBIs coming into a Sprint.
  5. Agile Specifications.  Just enough, just in time documentation. So that the implementors don't spin during the Sprint.
  6. A clear(er) Definition of Done.  That the Team agrees to and actually follows.
  7. Faster responsiveness by the Product Owner and the business side when questions arise. (< 24 hours is ok; < 1 hour is far better)
  8. Better Release Plan refactoring. In overly simple terms, in Release Plan refactoring, we get the stories ready-ready 'one sprint ahead'.  Better defined, acceptance criteria, clear and agreed, story pointed, BV points, agile specs, etc.  And the Team agrees each one is 'ready' before Sprint Planning.
  9. Fixing a host of technical impediments around better configuration management, continuous integration and better automated testing.  IMO, the biggest problem in this area is understanding why solving these technical impediments is so important.
  10. 'Single piece flow.'  This is a standard lean idea.  In software in a 7 person Scrum team, this typically means no more than 2 stories in process at the same time.  Each story is driven to completion, and then, once completed, a new story is put in process.  Any exceptions to this are considered serious problems, and are addressed rigorously.
  11. The Team must (learn to) be realistic about how many Story Points of work it can deliver (done-done) in the Sprint period.  I see far too many teams who over-promise every time.
There is more to say, but these 11 action steps should give most of you with this problem plenty to improve on.

For most teams, the goal should be for the Team, about 9 times out of 10, to fulfill at least the commitment it makes in Sprint Planning to deliver (done-done) X number of PBIs or stories. Note:  Our work is difficult to predict and some times it will 'explode' on us; so the team cannot always fulfill its commitment in Sprint Planning.  And some teams doing 'bleeding edge' work will be less 'reliable' too. 

I welcome your advice on yet better action steps.  Please tell us.

The Michael Phelps attitude

Whatever thing we do, what is our attitude?  In work or in much of the rest of life, I think our attitude should be some interesting combination of humble and aggressive.

My business is lean-agile-scrum.  Are we ever finished learning Scrum (the simplest of the three)?

My answer: No.

Why? Well, I start talking about the Michael Phelps attitude. Some of you might remember him as the guy who won 8 medals (impossible!) in the 2008 Olympics.  Wikipedia him.

To most of us, in swimming there is nothing simpler than freestyle.  Everyone can do it.  But what is Michael Phelps' attitude?  'I have broken the world record (several times), but I know I can get better!'

This is his real attitude.  A kid no better than you or I.  A kid we can emulate (ok, he is 26 now...I guess not a kid anymore).

If he is still willing to learn (after breaking the world record so publicly and thrillingly), if he is willing to admit he is not perfect yet in that simplest of all swimming events, why can't we?

***

There is another thing that athletes know, which is the importance of relaxing and not trying too hard.

Do I speak now in contradictions?  Yes.  Winning contradictions.


Note: Doesn't he look a bit like a shark up there in the picture?

Sunday, August 14, 2011

Leaning in, Leaning back

Some of you may know of my dance theory of human relationships.  It is a simple theory, and like many simple things, true at least some of the time.

It says that if you want someone to come closer, you must move backwards.  As most any pair dancer will tell you.  That of course assumes some sort of engagement of the two 'dancers'.  (Just as pair dancers hold each other at the waist and shoulder.)

Why is this true?  Well, one creates a kind of vacuum, which the other person wants to fill.  And, since you are no longer 'in the way', the other person can actually move toward you.  Think about it a bit more.  It is true (when it is true) in several ways.

So, how should an agile manager manage?

Well, at a course recently, I noticed the people in the group, and saw some leaning forward and some leaning back.

And that led me to these thoughts.

If you are an agile advocate, I think leaning "all the way" back is generally not good.  Maybe useful in some circumstances, but not the main posture.

On the other hand, leaning forward aggressively can be off-putting.  I am not recommending this either. This might be felt by people as 'command-and-control' as well.  Seldom something we associate with Agile.

What I am suggesting is that an agile advocate or manager must lean forward in a friendly and energetic way.  The group must at least know that you 'want to go' and that you are, in a reasonable way, excited about doing agile.

And then pull back some, so that others may come forward and become engaged.  The energy of a larger group can be far more powerful than the energy of one person.

What are your thoughts on these fundamental 'attitude' issues?

***

Note: The image above is from Bloomberg BusinessWeek, here: http://www.businessweek.com//careers/content/feb2007/ca20070207_700175.htm
The related article has some of the usual good stuff about body language, and some other good images.  Thinking about management style from the viewpoint of images (eg, as others see us) maybe allows us to think in a fresh way about the subject.

Saturday, August 13, 2011

Yogi Berra quotes

As some of you may know, my sense of humor, such as it is, finds Yogi Berra quotes both entertaining and educational.  I use some of them in my classes. My hope is that the humor allows people to remember things a bit better.  Or in some other magical way, helps learning.

For those who don't know who Yogi Berra is, he was a famous catcher for the New York Yankees baseball team, and later the coach for that team.

Here is an article about him:
http://en.wikipedia.org/wiki/Yogi_Berra

And here is a collection of his quotes:
http://agileconsortium.pbworks.com/w/page/44303643/Yogi%20Berra%20Quotes

A fact checker has not ascertained whether each and every quote is a certified Yogi Berra quote.  But then, as he said "I didn't really say everything I said."

I think some of them even directly apply to Agile. But you be the judge.

In any case, enjoy.

Sunday, August 7, 2011

The Team and introverts

Thomas Edison, an introvert.
I love introverts.  Some of my best friends are introverts.

First, it may help to define the terms.  Introverts gain energy with quiet time; extraverts gain energy being with people.  See, for example: http://en.wikipedia.org/wiki/Extraversion_and_introversion   To me, neither term is in favor or out of favor.

I have been talking a lot lately about the importance of the Team.  That the team, as Alexander Dumas put it, be "all for one and one for all".  That everyone on the team is pulling for team success, and not so much for individual success.  That everyone on the team recognizes that only team success is important.  That everyone recognizes that creating and sharing knowledge is better than relying on the knowledge or ability of one person.

And then I was in a class last week, and I tried to describe this to an introvert.  With the idea of pairing, with, to him, the implicit idea that he had to work with someone else 6 to 8 hours per day.  He was visibly upset.  I am guessing that he is an introvert.

So, I do think that creating knowledge together as a team is the most important thing the team does.

But we still must respect the introverts.  This is not so hard, usually.  First, once introverts bring other team members within their tighter universe, then they can actually work with them at some length.  Second, we do not need to do knowledge creation in a group of 7 or even a group of 2 during all hours of the working day.  We have to respect that each person is unique.  So, we have to respect the introverts' needs, just as we expect them to respect the needs of the other team members, and of the overall team.

I think many a ScrumMaster would do well to help assure that introverts, and their needs, are respected better in our firms and by the managers.  Done well, this will enable the team to become more effective (eg, for the customers and for the firm).