How I teach - 1

For those who will teach and for some puzzled course attendees, I want to do a series of posts about how I teach.

First, the goal is not to teach. Or, more clearly, the goal is neither teaching nor learning, but results (ie, more than just action, but actual results from action). Results for you, for your team, for your customers. That is the only goal that counts.

If you think I 'fail' as a teacher, and yet you get results...to me I have succeeded. Such 'failures' I will take any day.

OK, so I conduct the class in such a way as I think best will lead to the most results for the most people.

Right away you see certain 'philosophical' or fundamental issues have been addressed with certain assumptions. Assumptions that we have developed over many years of experience, but assumptions nonetheless, as we are far far from omniscient.

For example, we don't assume that everyone is the same. (In fact, closer to the opposite.) Nonetheless, at any moment, in overly simple terms, only one style of teaching is going on at that moment.

Second, I don't assume that the brain is the most important part of the human being. The soul, the spirit, the heart, the guts, the will, and many other parts are also important. There is increasing evidence that they are more important. At least in terms of real results.

Third, we have a theory, based partly on Piaget and others, that the mind resists changes to its fundamental constructs of the universe, of how 'things work'. And we have a theory that lean-agile-scrum is a fundamental paradigm shift in many of these constructs. So we are subversive. There, we have admitted it openly. We are trying to sneak up on your brain. But in a good way. Not to rob you, but to give you a gift more quickly.

Fourth, while lean-agile and scrum particularly are very simple (like all great things), at the same time, they are very complex. We hold the perhaps arrogant view that, at least vis-a-vis lean-agile-scrum, we are smarter than you. (And that's why we are leading the course, and not you.) So, while we get you active and talking, there are, sometimes rather indirectly, some things we are trying to tell you. We might wait for you to discover them on your own, and we might wait for monkeys at a typewriter to eventually write Hamlet. But, frankly, while we have some exercises where you discover things for yourself, for everything we are not that patient. Given that we only have 2 days for the basic course. So, we "tell you". (Some might call it 'lecture', although you might not. In any case, a different kind of lecture than most are used to.) Yes, yes, yes; we know all the problems with that. But we actually think that some people, if we add jokes and other tricks, actually stay awake, actually listen, and actually learn this way.

As Yogi Berra said, if people don't want to come out to the ballpark, nobody's going to stop them. Meaning: If they don't want to learn, fugetaboutit!

Also, we frankly are not clever enough to come up with enough exercises that can be done quickly. And, having felt 'played with' (in a bad way) by some of these kinds of games ourselves, we are sympathetic with those who are naturally skeptical of games. So, we still do some games and exercises, but maybe not as many as others. Instead, we use other tricks.

It perhaps bears saying at this point.... What we teach are not ideas that we invented. We feel we have been blessed to share the wisdom from men and women on whose shoulders (as the metaphor goes) we stand. It is a great wisdom, from the gods one might say, and we are humble about our real ability to pass it along as accurately as it deserves. And yet, despite the jokes and playfulness, which in some eyes might imply lack of caring, we value this wisdom very highly. And we think reaching the inner secrets of this wisdom is difficult. Realizing in a full way the most benefits is very very difficult. And, paradoxically, as with all great things, it is in fun and with great ease that the most benefits are realized. Trying too hard does not help. As any baseball player knows, we must simply swing the bat, and just let happen what may. So, the main point here is a certain kind of humility.

More later....

And your comments and reflections on this are solicited.

Note: The picture is of Carolyn Eyles, an award-winning teacher in Canada. Google her.

Release Planning

This is a short post to summarize our recommendations for Release Planning.

First, R.P. is that initial part of Scrum, where we plan the Product Roadmap and develop the first Release Plan. It is pretty important. We do it before we start doing Sprints.

Some people believe one myth about Agile (and maybe others). This first myth says: "we always leap in without looking or thinking." This is a myth, ie, incorrect. We must look and we must think first. But, how much??

Within Agile there is always this tension, between thinking just enough and YAGNI (you ain't gonna need it). Each team must resolve this tension its own way. Experience has shown that we learn most from real experience. So, suffice to say we do not, in agile, have a 6 month planning 'phase' (for any project that I have ever been on... and I accept the possibility that there just might be a fundamentally different kind of project than I have ever experienced before).

So, should it be done in one day? In 3 days? In 3 weeks elapsed time? The simple framework of Scrum does not answer this question. Use common sense (which is quite uncommon).

Still, the Product Owner and the ScrumMaster must set a high-level time box and day-by-day time boxes for the Release Planning. And try to get the participants to stay within them. It is hard. But the law of diminishing returns tells us not to waste that 'extra' time.

OK, what to do?

1. The Vision
2. Build the Product Backlog (stories)
3. Organize the stories with Business Value (I like BV points from Priority Poker)
4. Estimate the effort of the stories (using relative Story Points)
5. Discuss risks, dependencies and other things.

THEN
6. Order the work (based on all the info developed above)
7. Decide on (a) scope and date (together), and (b) cost.

We generally assume that the team is a constant cost per Sprint, so once you know the number of Sprints, you can easily calculate the cost.

Over-simplified. Left out some key things (well, not left out, but maybe not made fully transparent to some readers; assumed by me).

Having completed the R.P. you have achieved two main benefits.
1. You have established an "early warning system", which, when improved, can give you some advanced notice if your effort is getting into trouble.
2. You have all the "pigs" (and others) much much more on the same page about what the effort is really about. At a good medium level of detail. This is very very valuable.

Oh, yes, and we have the initial scope and date. The quality of those is technically termed 'crappy', so I minimize them as benefits. But soon, when revised and improved, they will become decent guesses.

Eventually (maybe up-front), this release plan must be developed further into a Product Roadmap (I don't really care what name you call it). Typically this is a rolling 12-month plan. After the current release, this is typically at a pretty high level (small to medium epics). Most businesses need about a 12 month plan. Some less, some more.

To close on a semi-controversial note: NO Sprint Zero! We did some release planning, now let's do a real Sprint (with a demo of working software at the end)!

No man is an island, entire of itself

In summers past, I have gone whale-fishing from Nantucket island. Well, not I, although I did go to beautiful Nantucket, as Ishmael did in that novel. But they never called me Ishmael.

But I have set out from Nantucket, as they did of former days, intent to catch me a whale. Albeit mine was a metaphorical whale.

So, you see why I choose Nantucket as the island. I think maybe John Donne, in his very famous Meditation XVII (a much recommended long tweet), maybe was in part thinking of the small island of England, Scotland and Wales.

And thinking of how we are all connected, one to another.

There is something very mystical, magical and special about any team that achieves success. They are indeed connected. And, no doubt it is or will be painful at times, but mostly such a wonderful feeling.

And the great paradox, by losing ourselves we become ourselves, becomes true.

If your collection of individuals would become a great team, they must not just gush with emotions, but act in their beating heart, and strike it with their muscles. Together. The paradox is cut through not in meditation, but in fierce sword-like sharpness in the real world. A game for the courageous.

This team part of the game we try to ignore, quite often. The head bobs at "we are a team" but the body does not follow through, as we might say. Each of us has our issues about this: our old patterns, our egos, our introversion, etc, etc.

People are "Created half to rise and half to fall" as Alexander Pope wrote, so, yes, it can take a lot to deal with them. And it is not just the logical and the emotional. We must deal with all the 18 (and counting) sides of the people in the team with us. (Yes, Virginia, we need more than IQ and EQ. These are whole people in the team. Dang.)

But if we would have any success or satisfaction in life, 'deal' most of us must. And the simple framework of Scrum sets in motion a basic interaction pattern. Which we can build on.