Scrum 201 Course: Agile-Scrum to the next level

I have a Scrum 201 course coming up in Atlanta. This is important, needed and useful. Why? Why Scrum 201? Lots of people have tried Scrum and everyone gets some reasonable benefit. But, you may not have gotten nearly the benefits possible. So, the purpose of this course is to enable you to get much greater benefits. For yourself, for your Team, and for your customers. Key Benefits:

• Better results (you, the Team, the customers)
• More fun (a key value)
• More knowledge in a difficult set of domains.
• The course plus the workshop is 3 days provides 22 SEUs toward the CSP and 22 PDUs.
• More ancillary material (we give you this after the course).

The attendees: I recommend that you bring a whole team or teams. And some of the people around the team. Invite ScrumMasters, Coaches, POs, Managers, ... really everyone. Format: More participatory than most courses. Discussions, exercises, etc. Content: Some core content and some choices among a long list of things to consider. Core Content: The core aspects of Scrum, the basic values and principles. Scrum-Butt. A discussion about why we are not doing the core things more and better. Prioritized Content:

• The underlying principles. Why Scrum works, and all the reasons why each practice is useful.
• How to build a great team (real, dedicated, stable)
• Removing impediments more aggressively
• Improving the Product Owner
• Business Value Engineering
• The ready, ready criteria
• The definition of done
• Better release planning
• The agile contract (fixed-price fixed-scope issues)
• Improving the engineering practices
• Advocating for the Agile Transformation
• Making change happen (large and small)
• Changing organizational culture
• Scaling
• Distributed Agile
• Too many projects at once
• How to manage in Agile
• Managers and Metrics
• Minimizing WIP
• Knowledge workers and motivation
• Smaller stories

And similar items. The list is long. Again, the aim here is to help you and your team get results at the next level. If you are interested, find a Scrum 201 course here.  

The Organization of the Scrum Course - 2

See part 1.  Now continue below with part 2….

***

One of the big problems is that the attendees, or many of them, resist intellectually.  So, as in Zen, we have to confuse the intellectual mind in order to enable real learning to happen.  Or, as the Army says, we have to break them down in order to build them back up again.

We have to ‘go around’ or ‘get behind’ the intellectual resistance that is common to just about all of us. So, one technique is to do exercises. Not following a highly logical flow is another technique. Surprising the attendees (in small ways) is another. Humor and improvisational exercises are other techniques. Food is another.  Addressing them directly, and getting to know them as a person is another technique.

For some, our techniques are…umm, disconcerting. If a person is a certain type – well-organized, intellectually rigorous, thinking, logical – it can feel a bit uncomfortable.  But if one has at least an intellectual understanding or some real experience that people and  life do not always follow pre-conceived intellectual notions, then it is not so uncomfortable. Very few people are uncomfortable, although a very few are.

So, I admit that the course to a new person, or to a few, might feel uncomfortable. (Actually, my impression is that most people enjoy it. About 98%.  But not all.)

During the course, if you tell me you have that an uncomfortable feeling, then I will offer some advice. First, I will address the topics that are on the one-page (two-sides) outline of ‘Scrum’ I hand out (it is really more than just Scrum).  I will follow the outline on the website. (Except not in that order.)  We will follow the slides, except  we will cover additional material.

We have a strong confidence that most real learning is not logical, per se. It happens in the sub-conscious mind, where experiences are ‘put together’ by the brain into a ‘logical’ way of looking at the world; assembled into a pattern or set of patterns. I try to  force your brain to break down old patterns, and rebuild new patterns.  I have confidence most of our attendees can do that.

And I know, sadly, many are ‘controlled’ by ‘waterfall ideas’ and they will not be able, after only 2 or 3 days, to really replace the waterfall patterns with agile/scrum patterns.  Some people are like that.

Would we succeed better if we presented things in a more organized, more logical way?  Well, a few people might say ‘it was a good logical presentation’.  That small group, would feel better.  But I am completely convinced that, if you look at the overall results, they would be much much lower.

Remember that our goal is not teaching. Nor learning. Nor even action by the attendees. Our goal is that attendees achieve real results with Scrum. For the person, for that person’s team, and for that person’s customers. One will never achieve real results with merely a ‘logical understanding’ of the work.

So, we are not after explicit knowledge. We are after ‘a sense of urgency’ and the tacit knowledge that leads to successful results.

So, I hope now it is clearer why I organize the Scrum course the way I do.

I wish you every success in having fun in achieving real results.

The Organization of our Scrum Course - 1

Why is our Scrum course organized in the way that it is?

***

Is a Scrum Team organized?

Well, a good Scrum is usually described more as adaptive than organized.  Of course, we can debate the meaning of these words, during a day or during a sprint, or during a release.  I would rather that the Team be adaptive, than follow an organized plan, as one example.

This is one small reason our Scrum course is not organized in a strictly logical way.

Second, why do Scrum Teams fail?

Well, there are many reasons.  Do Scrum have a problem because Scrum is too complex?  No.

The attendees have no problem with the explicit knowledge around the bare framework of Scrum. But, they do often have problems ‘getting it.’

In fact, the bare framework of Scrum is very very simple. (On purpose.)  Understanding the explicit knowledge around that is quite easy.

Hence, I am not worried that I need to organize the course so that the attendees build in their minds ‘complexities upon complexities’ about Scrum.  If Scrum were complex, for example, like Calculus, then we would have to organize the course a different way.

Again, Scrum is ‘holistic’ or interdependent.  One cannot understand one part of Scrum without understanding how it works or plays with another part.  ‘No man is an island’ as John Donne famously said.  So, I like to continually weave from one thing to another, so this weaving becomes embedded in the ‘back’ minds of the attendees.

So, one of the key problems is tacit knowledge. Getting the tacit knowledge and all that it means into their heads.  Honestly, not just into their heads, but their hearts, their souls, their guts, their bodies.

Continues in part 2, tomorrow…

Agile Release Planning workshop - Comments

I have many comments to add to the blog, and many topics to discuss.  Let me start with this one.

Last week we had another Agile Release Planning workshop, in Montreal.  (We do one almost every week.)  The workshop is mainly about taking a real set of work (about 6 months of work for one team), and doing real agile release planning.  This is explained in this blog, and at LeanAgileTraining.com (for any specific workshop), and in my book, Joe's Agile Release Planning.

First, most everyone in the group said 'this is the best' or 'this is when it all came together'.  These are frequent comments from the workshop.

Today, let me talk specifically about Serge and his team, which were all from one company.

They took a brand new set of work, which the company has to do soon, and planned it out.

It was so good that Serge took the release planning information (the product backlog, etc, etc), back to the office.

***

They had two issues that struck me.

One:

They are used to developing the backlog in isolation from the Team, by one or two people.

And, to be fair, many of the people in the workshop were not members of what will be the real team.  Still, I think Serge started to see the value of creating the backlog with a Team.  And the team members did too.

And, later, all the individual detailed work could be done.  Research, cross-checking, etc.  So, the difference from what they used to do (have 2-3 'experts' develop the initial product backlog)....the difference ends up being mainly timing.  Now, the Team (with business stakeholders) does it first, and then the individuals can work on it later and make it better.

Why is this better?  Well, several reasons.  I will list two.

1. It greatly reduces the time before we start 'real work'...I'll call that real work 'writing code'.  And with code we can get feedback from 'the real world.'  So, instead of waiting 3 weeks before we can 'start', we can start the next day (well, honestly, usually it takes a few days more).

2. It enables the Team to have their hands in at 'the creation.'  This has two benefits.  One, it gets their creativity involved.  One consequence is that some of the 'missing' stories are identified now.  Two, it changes their motivation.  They no longer get the mushroom treatment.  And they start to see, by working on it, how all the pieces fit together.

The only downside is, this is a change, and to some degree some people may resist, and you have to explain it to them.  But I have always gotten people to do it fairly well the first time.  (Can you alone get them to do it the first time?  Maybe not.)

Two:

How to do Priority Poker?

In this case, the company has few 'business stakeholders' who will show up.  It is a small company, and one of the people who 'should' show up and do this is the CEO.  But he does not have the time.  And there is a sales person who also has some good insights, but who might take the Team in 'his own direction' ... we will say it that way.

And, Serge is right -- this is not ideal.  And, getting really good business stakeholders is hard and has problems.  Almost always, at least to some degree.

Still, we can get the ...well, best people we can get.  And then use the poker cards to vote, and then average the answers.  And put business value points on each story.

And, as is always the case, we will feel and in some sense know, that this is not perfect.  Except that, the BVPs are the best guesses by the best people we can get to do this at this time.

And then we can do things to improve the numbers.  Starting the next day, maybe.

One obvious thing in this case: Take the product backlog with the BVPs (business value points) and show them to the CEO, and then get his opinion.  And often he suddenly says something like "wow, I wish I had been there...I want to be there next time....but let's change the BVPs on these 10 stories."  And you realize that for 40 out of 50 stories, the CEO is agreeing we did a good job, and he is 'only' changing 10 of the stories.  And usually by not really that much.

AND...the exercise and the numbers enables the CEO to realize that he should act differently with the Team.  The information becomes evidence that causes him to change his behavior.

Well, I do not know that with these numbers and this CEO this has happened this time, but I do know that it can.  With the right CEO and with the right advocate.  (It may be that this CEO really really is too busy, for example.)

***

I hope these key observations (for me) also lead to useful thoughts and actions for you.

If you have questions or comments, please speak up (below or via email).

Question about Retrospectives and the role of the SM

A very bright and quick class attendee wrote and asked: Why don't you talk in the class more about Retrospectives? And why so much about the PO? Why do you focus on the basics so much?  I want more advanced materials.

First, I actually think we do, as explained below. We do talk about Retrospectives, and we do have some advanced materials. Even in the CSM course.

Here is basically what I said to her, somewhat edited (I wanted to make it better).

First, it is not correct to think of the SMs duties as mainly revolving around the Retrospective (as many do).  Although the Retrospective is an important meeting, you as SM must teach the whole company how to adopt agile and scrum.  (Or adopt it more fully, often much harder.)  In addition, you must help and teach the PO to be more effective;  Th typically the biggest impediment (and multifaceted).  The next highest impediments are usually technical impediments (eg, getting good Continuous Integration and automated test suite).

But, we do a lot around Retrospectives.  The whole exercise at the end of the first day (where we emulate doing a Business Case in the Retrospective) is essential.  I expect you as SM to use that A3 approach to drive higher velocity.  (I recommend you Google the A3 approach and learn more about it.  Jeff Sutherland and Mary Poppendieck talk about it, as well as many others.)

The first problem with many Retrospectives is, as Angel said, all talk and no action.  Classic!

So, you (with the Team) must take action.  In two sentences:
(a) collect data and decide the top impediment for the Team
(b) start to take action

I suggested action in one of 3 ways - with the Team in the Retrospective:(a) devise a solution (Ken Schwaber loves to say it that way)
(b) plan the execution (not a detailed MS Project plan, but 'who will do it and how?')
(c) pull together a Business Case to get a manager to say 'yes' (to $, to give you people, to approve).

And the A3 exercises was all about starting to learn how to make the case to a manager. Which, usually, we are terrible at doing because we do not speak 'manager-speak'.  To the Team, that is a foreign language usually.

The A3 exercise also, indirectly, teaches us how to prioritize. Mainly, by benefits (eg, increased velocity) to costs.  So, a key thing is that you must help the Team prioritize the impediments in a benefits-costs way. And do other parts of the thinking, as implied in the A3 approach.

To learn more about Retrospectives per se, you might read Esther Derby and Diane Larsen's book, Agile Retrospectives.  Esther Derby and Don Gray are giving a course in Atlanta, not exactly about Retrospectives, but I recommend that.  Again, not exactly about Retrospectives.

I have to balance the different topics in the 2 days and I have way too much to say to make all of them a 'good enough' SM.  It is always fine if an attendee says: 'I want to talk about the Agile Retrospective more.' Or asks a question.

Again, your biggest impediment is likely to be a 'not good enough' PO or a business side that does not give you enough PO time or BSH (business stakeholder) time.  As SM, you should spend lots of time making the PO (or the Business side) better.

One of the biggest problems with Retrospectives is that some SMs get too cute.  They have lots of new, cool, weird 'process' -- but the Team does not move much on really getting an impediment fixed.  And that is your time, as SM, to get them to help you.

How can you help?  Mainly the ways I said: (1) identify the top impediment, (2) devise solution, (3) help plan execution, (4) create bus case. Also, the Team needs you in the Retrospective to report back on progress (or not) on the last big impediment, and usually, to tell them "we got it done" (by someone). Again, getting too fancy does not help.  Just say: 'let's devise the solution together' or something like that.  And let them self-org. (Sometimes you have to 'make' them self-org if they look helpless to do so.)

An SM's job requires patience.  It requires the willingness to practice practice practice the basics (yourself), and the willingness to let others do the same.

Yogi Berra said: Think!  How am I gonna think and hit at the same time?

In other words, you and the Team must endeavor to get the practices and the values and principles of lean-agile-scrum so deeply embedded in muscle memory, that you don't even think about it.  It naturally flows.

It is similar to the discipline of learning the piano, which is clear to many people.  Practice, hard practice, even harder practice.  But it is not so clear for the discipline of SM.  Anyway, watching others make mistakes is very trying for the impatient SM, who by now can easily do it herself.  I would be very surprised if a relatively new SM did not need to practice many of the basics a lot longer, to get them into muscle memory.  You know doubt know of Malcolm Galdwell and how he has popularized the 10,000 hours concept.  Not just repetition, but how learning hours either practicing or doing.  And to many in Scrum, sadly, they do many hours just repeating dully the same mistakes -- nothing gained on the 10,000 hours scale.

And we must also see and feel how the lean-agile-scrum 'music' (the values and priniples) plays with the practices.  And we barely even started to touch on the underlying principles.

It is true that some experienced people come to the CSM course, and want to go in-depth into one or two areas. But the CSM course is also a rank beginner's course.  So, if we have beginner's we have to slow down for them.

But bear in mind  that as an SM, yo must learn yourself to teach beginners.  For more advanced people I often say: Think about how you would explain Scrum to a beginner.  KISS.  Watch how I teach, how I emphasize simple things, and make them focus on only the basics.  They cannot advanced until they master the basics. You can observe a lot, and steal from me how to explain to others as a SM.  So, rather than the content, you focus also on the methods.

Now, even the advanced people need to re-learn the basics.  This is because, 100% of the time, they are doing so degree of Scrum-Butt (or you may prefer another phrase for it).  In some way, they have mis-understood.  If you play golf, we can say even Tiger Woods let's some bad habits get back into his swing.  You get the idea. KISS.

Also, simple as it is, it is too complex for them to really do.  Or they can't explain the basics well enough to get people to do them.  It is not the trainer, not Scrum, but simply human nature. The two big things: we forget and we fall into bad habits.  Again, you have plenty to do to get them all to follow Scrum (as you now know it to be).  See the Scrum-Butts list I gave you.

There is lots advanced material in the course, but I kind of hide it.  (I am trying to keep is KISS for the beginners.)

For those who are intermediate to advanced, I have a Scrum 201 course.  And other CSTs have their intermediate courses.  The new CSP path gives you an reinforcement for learning more.  As you know, I think Tacit knowledge is more important than explicit knowledge, but they are both learning.  And with an in-person course or workshop, you cannot help but pick up tacit knowledge from any good Agile person. And, sooner or later, you must have coaching from the best coach you can find.  Every professional sports team does, if they want to be successful.

Please tell give us more questions.  We hope these ideas help, or at least make you think and learn.

Courses Coming Up

We have several courses coming up.Certified ScrumMaster (CSM) course – This is the basic course, which we recommend for everyone and for teams. We are now almost always including a 1-Day workshop (on Agile Release Planning). Strongly recommended. And, occasionally, a 2-Day workshop.Places: New York, Toronto, Nashville, Montreal, Charlotte, Durham, Charleston, etc.
Intermediate Certified Scrum Product Owner (CSPO) course – In this course we want people who are experienced with Scrum — either notable experience or a CSM plus some experience. And it deals with more advanced topics. And we also include a workshop (on Agile Release Planning).

Places: Charlotte, etc.

Scrum 201 – This is an intermediate course for any team member or manager. We must have a CSM and some good experience with Scrum. With a workshop.  (With the workshop, it gives you 22 SEUs toward the CSP certification.)  The purpose is to help you move to the next level. And to try to answer (or help you answer) all the detailed questions that come up when you implement Scrum.

Places: Atlanta.

For more details (dates, etc.) see: LeanAgileTraining.com

We like to do in-house courses, and we could do any of these courses at your firm.
And we have other courses in the works.

Some of these courses are co-taught with my colleague, David Muldoon. He brings a different viewpoint and a wealth of experience leading an agile transition at a large corporation.

And don’t be shy about asking me or Cassandra Wagner (cassandra.wagner@leanagiletraining.com) questions.

4 Announcements

We are happy to announce 4 things.

1. New LeanPub Book: Joe’s Agile Release Planning.

Some of you may have seen a prior draft. It is revised now. And published. I expect to have some further revisions.  I seek your feedback.
You can see it here.

2. New Workshop: Story Splitting (Feature Decomposition)

This is a 1/2 day workshop, with David Muldoon. We are doing this workshop first in Toronto, Oct 11, in conjunction with a CSM Course (Oct 8-11).  We will be doing it at other locations soon.  See Courses at LeanAgileTraining.com.  See here for details about the workshop content.

3. New Workshop: Scaling

This is also a 1/2 day workshop, with David Muldoon. We are doing it first in Toronto, Oct 11, in conjunction with a CSM Course (Oct 8-11).  (This and the Story Splitting workshop form a 1 day workshop offering.)   We will be doing it at other locations soon.  See Courses at LeanAgileTraining.com.  See here for details about the workshop content.

4. Lean Agile Training page on LinkedIn

We have started a Lean Agile Training page on LinkedIn, here. Please visit and follow us. And please tell us what you think we should provide there.  What do you like?  What should we add?  What should we subtract?

Story Splitting (Feature Decomposition)

We have added a 1 day Workshop to our course in Toronto. And will add this to courses in some other cities.  The one day is composed of 1/2 Day on Story Splitting. And 1/2 Day on Scaling.

What.  Story Splitting is always required. We always need smaller stories in the Sprint. Some experienced Teams do this regularly and quite effectively, but lots of less experienced Teams struggle with this. So, the immediate purpose of the workshop is to move them beyond the 'struggle' stage more quickly.

Value. Story Splitting is not the only factor that can assist your Team to achieve the following benefits, but it is important, and often key.

• More reliability. When they 'commit' to 20 story points, with the smaller stories, they are more likely to hit 20 story points.
• Faster velocity. It seems paradoxical, but by taking the effort to get to smaller stories, the Team can get more done. If they do it professionally and cleverly.  Many reasons for this. One of my favorites is: "The bad news doesn't get better with age."  Also, the Lean community explains this well.
• Fewer and smaller failures. Sometimes a Team will not get a story completed in a Sprint, as they 'committed.'  To some degree, this is normal in innovation work. Unexpected things come up.  If we have small stories, first the likelihood of failure goes down.  Second, the degree of failure is smaller. We don't fail on 50% of the work, but rather on only 13% of the work (as an example).
• Team Morale is better. For the reasons stated above. Sometimes the Team will not at first understand the value of small stories; and it may seem like extra work to them at first. This must be explained. But once they are over that hurdle, Team morale should go up.
• The sense of 'traction' is better. As suggested above. Almost every day we can see a small story being completed.

See here for a fuller description of the Workshop.

ROI for Scrum Training

Does Scrum Training give a good ROI?

Well, of course, that depends. Mainly, how whether the Team (the full Team) takes an aggressive attitude toward improvement.

But let's look at the following calculation.

We start with the a Team that, fully loaded, costs about $1 million per year.
Their current Business Value delivered after 1 year's work....taking the NPV (net present value) of all future cash flows, is currently $3 million.  Now, maybe you can follow most of the rest below.

Financial Benefits Estimate
Cost of Team	$1,000,000
Business Value Delivered by Team	$3,000,000
Note: This is NPV from work delivered in one year
Improvement Factor	2
Note: Reasonable improvement factor in 12 months.
Note: Jeff Sutherland is looking for a factor of 5x-10x.
Note: This is usually measured as an improvement in velocity.
BV Run rate after improvement	$6,000,000	per year's work
Gross BV Improvement	$3,000,000	per year's work
Note: Per year!
Note: Thus, this is a LOW (conservative) estimate
Investment required to obtain improvement	$750,000
Note: This includes many things, mainly accumulated cost of impediment removals
Note: This is a HIGH (conservative) estimate
Note: At some point, a lower investment could correlate with a lower improvement factor.
Net Net BV Improvement	$2,250,000
Return on Investment	300%

Let's talk about the investment of $750,000

So, this includes the cost of training.

This includes the cost of travel to the training.

This includes the time lost while training.

This includes the cost of removing impediments for the Team (this is by far the biggest cost).

Removing impediments may require servers, software, training on automated testing, etc, etc, etc.

To be honest, we think $750,000 is a gross over-estimate of the cost of getting a 100% improvement in velocity.  It will cost MUCH less. Maybe $100,000 or $200,000 or $300,000 -- depending on your situation.  If the cost is 'only' $300,000, then the ROI after one year becomes 900%.  Or 9x.  That is huge.

Where would I invest first?

1. Train the whole Team.
2. Get an Agile Coach (I won't debate here how much time the coach should be dedicated to the Team. But a coach for one Team.)
3. Improve the Product Owner
4. Improve the continuous builds
5. Improve automated testing
6. Improve integration and regression testing, so that they are much more robust

Almost always, these are the top areas.

Each Team also has its own specific things, things unique to that Team.

Some Teams are fundamentally dysfunctional.  Some Teams need people skills.  Or facilitation on decision-making. Or training in specific skill sets.  Lots of other possibilities.

The key thing is that you see that we think starting Scrum is the key to releasing all these benefits.

And that it will not be Scrum alone that releases the benefits.  Getting all the benefits will require hard work and further investment.  But it starts with Scrum.

And Scrum, if played professionally, has a huge ROI.  Huge.

Note: Here is a link to a spreadsheet, so that you can do your own calculations.  Use different assumptions, and see what you get as an ROI.

Intermediate CSPO Course

Scrum is, in a way, simple.

But we think that, for many reasons, doing Scrum well requires continuous study.

For one thing, we need to do the practices in harmony with the values and principles behind lean-agile-scrum.  And we are always forgetting the values and principles.

But there is more to it than that.

You may have taken our CSM course. If you have done Scrum for a while, you should seriously consider taking the intermediate CSPO (Product Owner) course + Workshop. If you are a PO, the reason should be obvious; you need to take your skills to the next level.  This will greatly benefit the Team.

If you are a SM, you need to understand the PO role much better, so you can coach your PO to become better.

The course is also good for manager's, business stakeholders, and business analysts.

Our next Intermediate CSPO Course + Workshop is in Charlotte on May 21-23. I hope you can join us. See here!

But my main point here is not this specific course. My main point is the need for continuous education, so that you, your team and your customers realize the full value of scrum.  This course in May or the CSPO course more generally is only examples of that continuous learning.

Special Offer: Today thru Wednesday: 10% off the Charleston course in May

Today thru Wednesday, for that limited time, we have a special promotion on this course.
CSM + Workshop in Charleston, May 15-17.
10% off to members of the local Agile or PMI groups. (Or those who join today.)

Details are here or here.

Leading Fearless Change Workshop – Apr 12th!

We recommend that all agile advocates and all ScrumMasters and Product Owners learn more about making change happen.

Change both in the large (changing the organization and adopting Scrum more or better) and in the small (changing to fix each impediment).

Mary Lynn Manns will be leading a 1-day workshop on change. In Charlotte. April 12th. I can hardly imagine a better way to learn about change, and how to do it better.  Nor can I imagine a more essential skill set.

For more info: http://leanagiletraining.com/ChangeWorkshop-Charlotte-1.html

Hope you can join us!

Agile - Penny Game rules

As attendees of my courses know, I like to use the Penny Game.
Rules:
1. Say: "We are about to see who is the best penny processor in all of [city] today.  And the winner, with the best single round, will win $20."
2. Select 4 players (4 departments).
3. Select 4 managers, one for each Dept. Make sure the managers each have a stop watch.  Also, we need a one or two special managers, for the 'first penny' and the 'last penny'.  Also with stopwatches. (Get inventive if you don't have enough people.)
4. Give Dept 1 a bunch of pennies (any kind) and say: "Please get 20 pennies ready, all face up, or face down."
4b. Optionally, ask the managers how they will motivate their worker.  Some good laughs.
5. Round 1: The managers time how long it takes to flip each penny, one at a time.  Only using one hand. And pass the FULL batch of 20 to the next Dept without errors. (May use 2 hands to pass.)
6. Write up the times for each Dept, and the times for the 'first penny' (to reach the customer) and for the last penny (to reach the customer).
7. Round 2: Each Dept must process 20 pennies, but in 2 batches of 10.  As soon as the first 10 are flipped, they must be passed. Each manager measures the full 20, until fully delivered.  Again, we write up the scores in public. Including the timing for the first and last penny (the last penny is in the last batch).
8. Round 3: Each Dept must process 20 pennies, but in 4 batches of 5.  As soon as the first 5 are flipped, they must be passed, and so on. Each manager measures the full 20, until fully delivered.  Again, we write up the scores in public. Including the timing for the first and last penny.
9. Round 4: Each Dept must process 20 pennies, but in batches of 1.  Flipping must be separate from passing. As soon as the first penny is  flipped, it must be passed, and so on. Each manager measures the full 20, until fully delivered.  Again, we write up the scores in public. Including the timing for the first and last penny.
The Dept with the lowest single score 'wins' the $20.  Hand the money to the manager.
10. You ask the participants: 'Did we do this game to find out that [George] is the best penny processor in [city] today?'  They say No.
11. Ask the people, "So, the numbers are talking to you. What are they saying?"  If you have experience with the game, you might comment on how 'normal' the numbers are.  Typically most numbers are quite normal, but a few are 'off'.
Usually the will come up with some very good, counter-intuitive Lean insights.

Choosing a Scrum trainer/course

This is a question I get from time to time: How should I choose between one course/trainer and another?

This is an important question and deserves some thought.  It does not deserve, in my opinion, a simple answer, as one might get from Zagat's about a restaurant. The choice is very much different than choosing yet another restaurant.  For most, this is a once-in-a-lifetime choice.

The good news: Most people (I'll say 95%ish) are happy with their choice. Or so I hear. But did they make the best choice for them?  Very very hard to know.

Here are some criteria for you to consider. I believe you can think for yourself once you have some context or framework (a key Scrum theme).

1. Date, location, price. Yes, of course. You may think I am biased, but of those, by far the least important should be price.  Because in relation to the benefit, it is trivial.  OK, these three were obvious.

2. Course/workshop goal.  Yes!  What is the real goal of the course and the goal or goals of the instructor.  Even though they all say "CSM course", they do not have the same goal(s).

My goal is this: I want results for the attendee, for the team, for the customers.  To me, those results are the only things that count.  But I am sure many other CSTs (trainers) would say something different. Or would not agree.  Or would at least word that challenge differently.

3. Instructor personality: Yes.  Trainers have different personalities. And this affects how you learn.  How would you learn about this?  Well, one way is to read the trainer's blog. You might want someone who is the opposite personality to you.  Interesting ideas.

4. Instructor background: Not simple.  But if you are in finance in NYC, you might want a trainer who knows finance in NYC.  And a zillion other examples.  It can also be argued that, other things equal, the buyer should get it from someone who is from a different background. Maybe.

5. Instructor teaching approach: Each trainer has a somewhat different teaching style. To give an overly simple example: some use mainly a slide deck, some have no slide deck at all.  One related idea (theory): the training style should match your learning style.

6. Experience with Scrum. Some instructors have more experience with Scrum than others.  Jeff Sutherland and Mike Cohn would be good examples of that.  They have been doing Scrum for many many years.  (Oh, you thought I would only recommend myself?  Wrong.)

7. Accuracy of describing Scrum.  Umm. Some trainers understand Scrum better.  I do not know how wide the divergence is amongst the Scrum trainers.  I do know you will not hear the same thing from each one. Even about what I call 'the bare bones of Scrum'.  And certainly not about what things to add to 'the bare bones' to make it work better, but maybe that is different than 'accuracy of describing Scrum'.

8. Ability to explain the 'abstraction' of Scrum in a way that seems (is) do-able and practical in your specific situation.  Umm. Seems pretty important, right?  And yes, it is related to some of the other things already said.  But it is different.  One suggestion: read the trainer's blog.

9. Workshop or not. My colleague Catherine Louis got me, against my better judgment to try doing a third day Workshop. So, now I do that all the time. Most Scrum trainers do not. Or they do a different kind of thing.  In any case, that is an important part of the choice, in my opinion. Suffice to say that I think the Workshop is very valuable, based on feedback from the attendees.

I am sure there are more criteria. But that is a good start.

One thing I suggest you not pay attention to....

First, there is a thing called NPS (Net Promoter Score).  It is used a lot on normal products, and many smart people (not all), think it is very good. I usually mention it when talking about the Business Value of products.
First, I think the course/experience/situation in a CSM course is very different from a normal product.

OK. Some trainers gather an NPS score. From attendees who have just completed the course.  I do this also. (For me, I find the information somewhat useful.)  Each trainer attracts, for many reasons, different kinds of attendees.

If you get a chance to compare NPS scores across trainers, don't.  You do not yet have enough information to compare those numbers.  After you have taken the course from both trainers (of course, the first trainer will bias your observation of the second), you will almost have enough information to compare the NPS scores between both those classes.  If you could see only the NPS for each course (and both trainers would likely show those numbers to you, if you asked).  But NPS numbers averaged over a year's worth of courses will not be meaningful.  To you (although perhaps a trend line might be meaningful to each trainer).

In general, for all the trainers I know, the NPS will be high, and the differences between the NPS scores will not be meaningful. Certainly compared to other factors.  IMO.

Hope that helps. Interested in your comments.

***

Why our CSM (Scrum) course + Workshop is unique.

We believe our CSM (Scrum) course plus Workshop is unique.  And better.  For the following reasons.

1. We focus on results. We want you, your team and your customers to get real results. In a big way.  In 3 words, more satisfaction, more money, more fun.

2. Therefore the teaching style is not toward remembering explicit knowledge.  The teaching style is to enable you to change your own mind, so that you want to take action.

3. We focus more on 'why' each Scrum practice is done.  We think that this 'music' makes the dance steps of Scrum more powerful, more effective.

4. We have learned from 8 co-trainings with Jeff Sutherland.

5. We are more business-oriented than most Scrum trainers.  And still protective of the Team being asked to do a Death March and yet call it Scrum.

5. While we offer some serious challenges, and ask you to challenge yourselves and your company to truly achieve the results you deserve, we are also realistic.  We appreciate that Scrum will be tough. We offer sympathy.  But not too much.

6. Attendees say the Workshop converts the ideas of the course into action. So that the Team can get off to a good start. 

We know a bunch of great CSTs. It is unlikely that our trainings are unique in every one of these ways.  We know that one trainer or another does, we think, every single one of these things. But in the combination of them, no doubt we are unique.

Referral Program

We have introduced a referral program.

The idea is simple. We want to provide a token of thanks to those who refer a person to one of our classes.

The token is a $20 Amazon gift card (we can substitute other gift cards of the same amount). So, it is not a huge referral bonus, but a token.  Of our appreciation.

A few rules:
* One per course (ie, only one gift card per course, whether you refer 1 person or more). If you refer a second person to a second course, then a second referral gift card.

* The referee must identify the referrer.  Mostly likely in the check-out process, but this is not required.

* We need a simple way to send or deliver the gift card. Assume US Mail.  Assume we need a delivery address.  No overnight or expensive delivery.  Something close to $0.44 for the stamp.

* We reserve the right to change the rules at any time.

Refresher Attendees: new program

As most of you should know, I am a Certified Scrum Trainer.

I have decided to allow prior attendees of my courses to attend the same course again, for a much reduced fee.

I expect the main usage of this is for people to attend again when some of their associates attend the first time.  But it is also true that research shows that attendees typically remember only about 20% of the content of a course.  I know that attendees only take in a small portion of what I really mean.  And, perhaps I am biased, but I think information about doing Scrum professionally is very valuable.

We have to have a few rules.

1. You have to have attended the same course / workshop with the same instructor.

So, if you attended a CSM course, then you can "refresh" at any CSM course (given by the same instructor).  If you took the Workshop as well, you can "refresh" the Workshop also.

The course does not need to be at the same location (same city). This is not restricted to the CSM course/workshop.

2. We must have space for the next refresher person in the class/workshop.

In this regard, there will be two criteria.  No more than 1 "refresher" for every 3 regular attendees. And, refreshers cannot be the main cause of bumping up to a more expensive room.

3. The current fee is $200 per day.  If you have a normal paying colleague also attending the same course, then your fee would be $150 as a refresher.

This fee may change. This mostly covers our food & beverage and hotel costs. And the processing/admin costs.

The rules are subject to change, as we see and learn how this works in practice.

***

We are interested in your comments.

Why add a Workshop Day to the CSM course?

Apparently I am one of the few Scrum Alliance CSTs (Certified Scrum Trainers) who always adds a Workshop day (or 2) to the CSM (Certified ScrumMaster) course.

Why do I add the workshop day?

The simple reason is because the attendees demand it.

Well, honestly, before they have taken the course the attendees don't know to ask for it or not. And often, after they have taken the course and the workshop, they can't compare with or without the workshop day.

But, for example, I had a manager at a major corporation near NYC send his whole team to our NYC CSM+Workshop course this week. His reasons:
(a) he knew me from having taken a course with me last November (with a workshop), and
(b) I was the only CST he could find who had the workshop day.

Next, I want to give credit to a friend and colleague, Catherine Louis (also a CST), who made me add the Workshop. (I was originally skeptical.) So, it was her idea originally. Now, based on experience I am a strong advocate.

Note: I still let attendees sign up only for the 2-day course. That is all that is required by Scrum Alliance to get a CSM.

Why do I consider the Workshop 'necessary'?  Or maybe better: why do attendees find it so valuable?

I get a few answers that are, to me, fairly similar:

1. It makes the ideas real.

In the class we talk and do exercises, but the exercises are never about the 'real work' that the team will do (or return to) on Monday.   Maybe similar to real work, but not their own real project or product. In the workshop, we use a real project, ideally the real project for the whole workshop team. Then the team starts doing Scrum (or at least release planning in a Scrum context) with their real work.

And the real questions come up. And get resolved. Or at least they see that their worries are not as great as they had imagined.

2. The ideas stick.

And attendee yesterday said, well, we need the first two days [the course days] because that gives us the ideas. But then we put the ideas into action on the third day.

And by putting the ideas into action, the ideas stick better. And, having put them into action, even if limited action, you know that when you go back to the real world, you can do this new agile stuff.

It is reactions like these (the two points above are based on attendee reactions) that lead us to always strongly recommend the workshop.

Here is another discussion and another customer reaction about the workshop day.

Business Value Engineering framework

I am about to do another BV Engineering workshop. In Orlando, Feb 23-34.  Preceded (appropriately) by an Intermediate CSPO (Product Owner) course. Feb 21-22.  See: http://leanagiletraining.com/courses.html

In this post I wanted to explain the workshop from a different angle that I have done before.

First, what is the BVE framework?

So, Scrum is a framework, not a full methodology, but a framework. Similarly, BVE is, in part, a framework for improving the delivery of business value. And, we think, a nice adjunct to Scrum.  Maybe not appropriate for every situation, but we think it is a simple set of tools and ideas to enable you and your colleagues to drive higher and higher delivery of Business Value.  In most situations.

Why do we need it?

Several reasons.  Here's one.

We find that many people have good ideas about Business Value and what the PO should do. But the "buyer" of these ideas has no framework to use to analyze whether this tool, or that idea, or that paradigm is the most important thing for that buyer to add now.  We believe the framework offers a way to prioritize the implementation of new ideas and approaches. To prioritize and act on improvements.

We also find that if people don't have a basic set of ideas and a "process", then "things don't happen". So, here are some basic ideas and a very basic process to start the improvement happening.

What's in the framework?

Well, many things from a certain point of view, but here are some things I want to highlight today.

1. What is Business Value?  This is a notion that the practical definition of BV must be done case-by-case. For and with humans.

2. P-D-C-A.  We must have a Plan-Do-Check-Act kind of approach to improving. Iterative, incremental, cyclic. And with metrics.

3. Mapping. We steal the Lean idea of Value Stream Mapping, and propose a yet more basic approach for BV.  At least make the process (or lack of process) visible. Only then can you improve it, bit by bit.

4. Visible. Make the underlying (implicit) hypotheses by which your group does BVE visible. Articulate them. Usually there are about 20 key ideas or assumptions. And once you make them visible, everyone starts laughing at at least a few of them.

5. Fix-Measure.  To some extent I am repeating part of the PDCA.  Once you identify the biggest problem, try to fix it or improve it, and then measure. And then determine whether the fix is any better. (We also have a healthy skepticism of metrics.)

6. End-to-End.  Ideally we should examine and improve the whole end-to-end process. (Always hard to say when things start and end, but in general, we tend to go broader.)  We don't want to over-optimize one part, to find that we have sub-optimized the end-to-end.

So, we talk about these ideas in the Workshop.
But mostly we start doing exercises to implement these ideas.
We learn by doing.

To be fair, Business Value is a hard and complex subject.  We do not expect people to come out of the course as experts after only 2 days, but we do intend to establish a framework for getting continuously better.

Why an Intermediate CSPO (Product Owner) course?

I am about to do an Intermediate Certified Scrum Product Owner course in Orlando.  Feb 21-22.  Followed by a Business Value Engineering workshop. Feb 23-24. See http://leanagiletraining.com/courses.html

In this post I wanted to talk about why the Intermediate CSPO is important and how it is different.

First, our finding is that the Team is important. Any focus too much on one role, or one role in isolation, is potentially leading people astray.  In a Team, every role plays with every other role. (Yes, we might do some work in isolation, but always for the use or benefit of others. So, the isolation is only temporary, and not very meaningful.)

So, I like all Product Owners to start with the CSM (Certified ScrumMaster) course. And ideally to take this with the rest of the Team.

And then to play Scrum for some time.  So, the PO starts to have real questions from the real world.

Second, I think for almost all teams, the biggest impediment is that the PO is not good enough.

This is not because we don't ask good people to play the PO role. Usually we do.  Sometimes excellent people.  It is because no one is a trained and experienced (eg, for 5 years) Product Owner.  At first.  So, very good people appear weak because they lack training and coaching and experience.

So, I find that the best thing is to take POs with a CSM and some experience, or no CSM and a fair amount of experience, and send them to an Intermediate CSPO course.

The course actually covers most of the same topics. But from the point of view of an experienced person.

For example, we review basics.  In this course not to explain them the first time, but to check for real world understanding. And to correct the mistakes that beginners in any sport always always always make.  The bad habits, we might say.  The Scrum-But that they have started to do.

Third, we try to build the aspiring Product Owners into stronger Product Owners.  I have just suggested my key point-of-view: That becoming the Tom Brady (the Quarterback of the New England Patriots for those in Rio Linda) of Product Owners is a journey that takes years.  So, when we say aspiring, we do not mean that they come to the course with no accomplishments, but rather that whatever they have done, they aspire to be better.

A lot of the basic things we talk about are also discussed by other trainers. And on the website above.

What are some key ideas that we talk about that others (usually) do not?
* minimizing work in progress
* maximizing learning
* ordering the product backlog to optimize BV delivered over some period of time
* focusing on the gold, platinum and diamonds, and ignoring the silver, copper and dirt (Pareto)
* sizzling steak and killing babies (the psychology of an earlier release)
* a brief intro to the BV Engineering framework (approach)
* no Technical Debt (is a PO issue too!) (Well, zero is a very low number, but that's the direction.)