New CSP Process

The Scrum Alliance has announced a new CSP Process.  That is, a new process for becoming a Certified Scrum Professional.  See here.
This is mostly good. We recommend it.
And some discussion.
First, the main changes are:
(a) 3 years of experience (not well defined by S.A. – sorry)
(b) 60 SEUs (same as the PDU concept) (also not as well defined as I would like – again, sorry)
(c) no test
(Note: As you, and I and others ask questions, I think the Scrum Alliance will define these things more carefully. Please ask them questions.)
Second. I am not a big advocate of certifications. I am after far bigger results for you, for your Team, for your customers than that.  Huge results.
And I have never been convinced that any certification can ‘prove’ that someone will get results. But, other things equal, more explicit and tacit knowledge is good. And more experience is usually good. And these Scrum Alliance courses that lead to certifications tend to provide good information. Information that can make you more effective.
So, what is our biggest impediment, in the Scrum community?  Well, there are many things that one could point out, but this is what I think.
Too many people are doing Scrum or ‘scrum’ (as they define it), and getting results that are not as impressive as I would like. So, the frequency of ‘subpar’ results. (Subpar is still usually at least 20%, which is a great return on investment. But far less than we ought to be getting.)
I would like to see Teams regularly, almost universally, getting 100%, 200%, 500% and more improvement.  And I think all of them can (compared to their own baseline). (Yes, there will always be a few dysfunctional teams. And people who should never be in a team.)
I think the 400%+ level of improvement is quite uncommon.  I will guess in the neighborhood of 15-30%.  Why?
Many reasons:
- the firm’s culture
- lack of aggressiveness in removing impediments
- too many doing ‘scrum’ or Scrum-Butt
- a forgetting of what Scrum is
- many other factors
I think the CSP approach can help with this. The PDU approach is only one method to address this problem. (And, given human nature and life, we will never get 100% of the people getting 400%+ with Scrum.) But I do think the PDU approach can help.
Why?
- Because people need to get fired up again
- Because people forgot the first Scrum course (research shows that people forget over 80% very quickly; it is just how the brain works)
- The core concepts of Scrum are quite foreign, or at least counter, to what most of your work environment is telling you. So, while you may absorb some basics at first, you cannot absorb the fine points. The real art of it.
- Scrum starts to ‘wash off’ (if you get the metaphor)
So, the PDUs do two things.
- They remind and enrich your brain, your muscle memory, on what Scrum really is
- They give you extra things to add to Scrum (adding things is essential to successfully using Scrum)
To me, whether you get a CSP is not very important. But, if you are using Scrum, you must continue to learn to get better.  And you must endeavor to take it (Scrum, innovation, productivity, fun) to the next level with your Team.

Making Change Happen

I was delighted the other day to have a brief conversation with Mary Lynn Manns, who is the co-author of Fearless Change, an excellent book on making change happen.
And I told her I had this idea: We can let change happen to us. (This is mostly to be passive in the face of bad change.)  Or we can make change happen (the good change).
This dilemma was expressed by Shakespeare:

Whether 'tis Nobler in the mind to suffer
The Slings and Arrows of outrageous Fortune,
Or to take Arms against a Sea of troubles,
And by opposing end them...

We mean something slightly different.  Not just to oppose the negative changes.  But to advocate for positive change.
It takes guts.
I think, for many, it does not feel like guts. It feels like this: "I have to make this change happen, and I don't care if I get nicked or scratched along the way." The nicks and scratches are a 'small price to pay'...is the way they feel.
Anyway, we are better people for making the good changes happen.  It makes us better people.
To make it happen, we must be by turns aggressive and patient.  By turns, emotional and thoughtful.  By turns, with laughter and with all seriousness.
How do we make this happen?
Well, this change and we ourselves are the stuff that dreams are made on.  There is no science here. But there are still many good ideas, and some of these ideas have been tried many times.  And in the hands of the professional, they are usually or often successful.
Mary Lynn Manns and others call them patterns.
The first pattern is Evangelist. That would be you.
The Evangelist comes up with the good idea (somehow).  (Hint: I think the first idea to implement is Scrum.)  And then starts to...well, to evangelize. To get others to try the idea.  To help the idea.
A couple of more patterns:
Ask For Help: The Evangelist asks others for help with the new idea. Maybe help defining it. Maybe help implementing it.  Maybe help evangelizing. Also, have you noticed how wonderfully seductive it is to be asked for help.  Who could possibly have more taste, brilliance, and acumen than the person who would ask me for help?
Innovator:  Usually you have in your group some Innovators. Ask them especially for help.  Get them on your side. In part, they are the ones most likely to have a positive attitude toward trying new things.
Just Say Thanks: Again, it is remarkable how a few bits of good manners can get people to go along with a new idea.  Saying 'thanks' for the help can...well, help a lot.
Step by Step: Some of us want to make one big grand change. And be done with it.  But the experience is that it is almost always best done, in some sense, step by step. One smaller change at a time. And they become added together into something quite big.
Small Successes: This is a similar idea, but somewhat different. As you have successes, even if small, be sure to celebrate them.  The small celebrations will delight the change's supporters, and confound its enemies. (Mark Twain said: When in doubt tell the truth. It will confound your enemies and astound your friends.)
***
In the book Fearless Change, Mary Lynn Manns and Linda Rising have gathered much more detail on these patterns. Indeed, on a total of 48 patterns.
You will find patterns you have done (but probably not done recently).  You will find patterns you have heard of other people trying (but you have never used). And you will hear of completely new patterns.
The main problem is: use one pattern each day.
I think, if you do that, you will win.

We want a Stable Team

I think our (your) business is about knowledge creation.  (Well, I think it is for almost all the people who come to my courses and workshops.)  About innovation, creativity, inventiveness. About cool solutions to hard business-technology problems.  It is about some sort of intersection between people and technology. So, coming up with a great product requires something special.

And I believe the ‘special thing’ these days is far more likely to come out of a good Team.

So, from a business management viewpoint (and it is the managers we most need to convince about this) — we need a stable Team.

And it needs to include virtually all the functions (or far more so than we ever did before).  And that also means it needs to include business people and technology people.  Just for amusement, I like to call them suits and geeks. To me it suggests that it just might be ‘interesting’ to put them together.

We must mention two things.

It should be FUN to work in a real Team.  And in fact, in Scrum with all but dysfunctional teams, it is fun. (But maybe could be more fun, if you had a good ScrumMaster helping the fun along.)

It should be more satisfying working in a Team. It is my belief that the human animal has been selected to enjoy life in a small Team.  Like a family, but a bit different.  A small ‘pack’.  Maybe within a larger pack.

So, how long should a Team be stable?

To answer this question, we need to identify basically three situations.

1. Mediocre Team. This team improves 20-50% with Scrum.  Give them 6 months.  If they don’t become better by then, then try putting the individuals in different Teams.

2. Good Team.  This team improves in the 100-200% range.  Wow. Leave them alone. They are doing pretty darn well.

3. Great Team. This team improves in the 5x-10x range. Wow!  Don’t mess with them.  This is the goose that laid the golden egg.  You would be crazy to bother them unless and until they want to be bothered (want to change).  And, if you continue to give them good satisfying work to do, they may never need to change. But, of course, something will eventually happen…one of the usual human things (birth, marriage, death, move, etc, etc).

(There is also the situation of the occasional dysfunctional team. Usually that can be identified in a few Sprints. As soon as you are sure it is not just ‘storming’, then you must change the team composition or totally bust up the team.)

***

This idea of stable teams leads to a major shift in orientation. (The change can happen over time.) We no longer start with projects, and find people to do them.  We now start with a Team, and find good work for it to do.  Who knew that people were important?

Don’t blame Scrum for helping you see

Today I completed a CSM course & Workshop in Charlotte.

I forgot to tell the attendees one thing.

One of the major purposes of Scrum is to enable the Team to see its problems better.  We hope that, being able to see the problems (impediments) better, the Team and the firm will take more action to fix the top one (well, over time, the top ones).

But it is painful to see some of the impediments.  In the former days, we could pretend that we were better than we (really) are.  And some of the problems seem so stupid, once you see them.

Some people want to blame Scrum for the problems.  That the Team is dysfunctional, or not really a Team.  That people won’t agree.  That we don’t have enough automated testing. That we have too much technical debt. That the product owner is not conveying very good requirements.  Whatever the key problems may be.

And these problems are often hard to fix. People are involved. They are stubborn.  It is trouble.

But they need to remember that it is easier to fix problems if you can see them.  And that Scrum did not cause the problems. Scrum, in fact, is helping you dig out of the problems, a little bit at a time.