"It's a mixed up muddled up shook up world"

I suppose we can all agree, after reading any newspaper, that the outside world is ...mixed up, muddled up, and shook up.

Do we let ourselves see that this is also true of the world and the people more immediately around us?  And maybe, ah!, even ourselves?

Agile and Scrum are ways to work through all the change and stuff, and strive toward success.  In business. (Some say it can be used at home, but we won't go there today.)

Maybe you will enjoy reflecting on the quote.

Scaling, Part 2

Here are some additional patterns to consider when Scaling.

For now, consider that I am using a narrow definition of scaling, to mean only, collocated teams working together on one product in a fairly tight way.

1. Upfront Work.

To over-simplify, if we create any product, we plan, we build, we release.  That is the simplest pattern.

And, often, especially with 'greenfield' products, we have to do some 'upfront work' along with the planning.  This is true even with one Team.  I call that work I-A-D.  Infrastructure, Architecture, and Design.  There are many names for it, and the exact nature of the work can vary a lot depending on the nature of the product. And god knows, there are lots and lots and lots of variations for how people are doing this work currently.

There is so much to say about I-A-D.  Let me say only a few things here, today.

One, we must keep it small, but which now I mean mainly small in duration. It is so easy to 'take-off' 6 months to do a perfect architecture, as an example.

Two, it must be tested incrementally.  All knowledge work should be tested quickly after the knowledge is created.  And re-tested and re-tested.

Three, as we scale, we must accept that, ceteris paribus, we usually need more of it than with a
smaller effort.  Or an effort with fewer people.  It, for example, has to be documented somewhat more.

Four, we want 'everyone' in the 3 scaling teams to know 'everything' about the I-A-D.  Well, as soon as I say that, you see our dilemma.  Getting all 21 people on the same page about the I-A-D is a 'knowledge management' nightmare.  But, as soon as we have scaling, that's what we want.  So, using common sense, we do things to help the knowledge appropriately spread throughout the Group (the 3 Teams).

Ok, for today I feel I have said enough.  Good people, with common sense, can execute on those ideas.  But it is true that many of us need more detailed patterns, even for only 3 teams.  More on that later.

2. Coordination of Sprint start and end dates

In general, it appears to be a good pattern to have all Teams in a scaled group start and end their sprints on the same day (or days).

Why?  Well, they have to be coordinated together.  In part, this means that they must receive feedback together.  And then use this feedback together.

Yes, I entirely understand that this pattern, as much as it helps, also presents problems. How do you actually do it?  What is the same person needs to be in 3 meetings at the same time?  Etc, etc.  Still, it seems to be the better pattern.

Both in theory and in practice. If it makes you feel better, think of it this way: this pattern sucks the
least.

3. Changes to Sprint Planning Meeting

As soon as you scale, you want all 3 Teams in your Group to be at one Sprint Planning Meeting. But then you have roughly 25-30 people in one meeting, and a meeting that size always sucks.

So, what to do?

Clearly (from experience) you cannot have each Team working alone, in their own Sprint Planning Meeting with no 'outside' influences.  Also, clearly, having a whole day meeting with 25-30 people is very very hard.

The usual solution is to compromise.  That is, spend part of the day as a Group.  And part in individual Teams.  I like starting as a whole Group.  And ending as a whole Group.  And maybe a middle whole Group meeting where you review the stories selected for each Team.

4. Changes to Sprint Review

As soon as we scale, and we want to have the Sprint Reviews for each Team on the same day, someone says: "How can we do that?  We need the same people, or many of the same people in every Sprint Review?"  Which usually is a correct observation.

So, we use common sense.  There are many similar answers, but I'll suggest what my colleague Catherine Louis calls the Science Fair approach.  You probably did this as a kid.  Each kid or team had a table in a large room, maybe the cafeteria.  And all the parents would file in over 2 hours, and the judges too, and look at each of the 'exhibits' or 'experiments'. And go back and forth.

And that is the idea.

So, each Team continuously demos its features.  At a separate table.  And the CPO (chief product owner) and the POs (the product owner for each of the 3 teams) and the BSHs (the business stakeholders for all 3 teams) all move from table to table, trying to see what has been done, how it fits together (or doesn't), and deciding how to give the best feedback.

And in fact, team members also shuttle amongst the tables, trying to see what has been done by our Team and the other Teams, and how it all fits together and what it 'means'.

As you can see, doing this well requires some skill and experience.  And you can imagine the self-organization that also takes place each time.  And in ways that cannot be predicted.  People will see issues and identify inter-relationships that could not have been anticipated beforehand.

In any case, hard as it is (and in some ways, it is easy), we recommend the Science Fair approach.  It takes somewhat longer, but it pays dividends.

We also recommend that each Team have a short 'review' discussion. And that the whole Group have a 'review' discussion. Probably a short Group review at the beginning, and then again, at the end, to review the overall feedback and its implications.

If only scaling were simpler!   For that matter, people!  You know, if we could only get rid of those pesky customers, things would get a lot better real quick!

That reminds me of the most important advice about scaling: KISS.  Or, as Einstein perfectly expressed it: "All things should be made as simple as possible, and not simpler."

The PO - The Team - Daily Scrum

I have some different views on this, and wanted to share them.

Your comments are of course welcome.

I am NOT asking what is or should be in the Scrum Guide. Or whichever 'scrum bible' you use.

I am just saying what my thoughts and experiences have, together, taught me.  I want to discover just what is most effective for 'pretty good' Scrum teams.  (Maybe not best for super teams or for beginner teams.)  So, I am trying to have a conversation -- maybe about what to add to Scrum -- not a religious war.

OK.  My views expressed too quickly:

1. The PO is very important to success.
2. Understanding business value and understanding detailed 'requirements' is very important to success. Both these 'activities' are extremely difficult.  Both for the PO and for the Team.
3. Knowledge creation as a full team is very important. In multiple domains. All domains impinge on all other domains. (Key example: cost-benefit analysis.)
4. The full Scrum team delivers the product. Each provides his unique skills and ideas and creativity.
5. The PO is definitely a member of the Team.  Given real life, often 100% of his time is not enough (see also #7 below).
6. The only team that matters is the full Scrum Team.  It is this team that self-orgs, most importantly. (Yes, every person, pair, teamlet self-orgs....not the most important aspect of self-org though.)
7. I do not think it is useful to talk about a team within the team. (I hardly ever say 'Dev Team'.)  Talking about a team within the team  creates an us-them attitude. And anyway is not useful. And at first at least, a bit confusing.
8. The PO must spend a lot of time with 'people outside the team'.  I will call them, at times, customers. managers, business stakeholders, etc etc.
9. Still, the PO should attend the Daily Scrum as often as possible (by phone if not in person).  And should answer the 3 questions. His work affects the output of the Team.
10. The simplest example is: On Day 1, a question is asked by the coder. On Day 2, the PO can give the answer (or at least say 'I got the answer') in the Daily Scrum.
11. If the PO does not do the Daily Scrum (ever), I think most team members start to think or feel (sub-consciously): "who is that guy; he is not part of the real team".

OK.  This is my experience.  Maybe limited experience.   Maybe just bad thinking.

Imagine that you disagree.

Where we differ, I expect my main reaction or push-back would be: "Well, I can see that happening, and it has happened to me, but I think we should coach them to be better, and often, if we coach them to be better, they actually will be."  Meaning for example: They can do the things above, and it will make them at least a bit better.

Certainly some of you have done different things and been successful.  But could you have been more successful doing it this way?  Or might 'my' teams be more successful doing it your way?  This, to me, is the question.

Again, I am not sure I would coach all beginning teams do it this way.  I am sure some super teams might be more successful another way.  My inquiry is: For most 'good' (but not super) teams, which is the best way to do these things? (PO, Team, Daily Scrum)

Of course, there are many other things in life and in Scrum than just the 3 things I discuss above.

BTW, while what I am saying above is not exactly how it is described in the current Scrum Guide, I do not think it is contrary to what the authors would want.  But it may be more than 'the bare Scrum framework'.  The minimum that they want.

Complex Adaptive Systems

Self-organization, which we just wrote about, is only one of the ideas that we know contribute to the success of complex adaptive systems.

While we are not convinced that CAS (complex adaptive systems) have been fully figured out, we think it has a lot to add. (In fact, our hypothesis is that that E=MC(2) is only a working hypothesis (as are all the so-called scientific laws) soon to be revised...and soon might be 1,000 years). But we think anyone working with creative teams must be studying CAS. Well, and thus, self-organization.

Another key related idea is Knowledge Creation. We cannot talk about this too much.

In our businesses of new product development, the key thing is the amount of good new knowledge created and per unit of time. And good, in overly simple terms, means high business value (along with lots of other constraints).

We think self-organization is key to high levels of knowledge creation. As anyone who has done brainstorming knows, you cannot command-and-control creativity. Or, if you do, you should expect very low creativity, creativity smothered in a prison jump suit.

We think CAS and knowledge creation are key to better Scrum teams.

This leads me to this thought, said earlier a different way: Our biggest impediment is refactoring our wetware.

Now, one of my missions in life is to reduce and reverse de-humanization. (Sounds quite high-minded and daunting, but it is not; it is just a daily struggle, like brushing one's teeth. Or mostly it is.) De-humanization is where people are not treated as being fully human, with all the good and bad and other stuff that implies. Where, for example, they are treated as a thing, maybe a computer. So, I am not in love, as a lover of words, with words like 'wetware' that take a computer model to explain the human CNS or mind. But, if it makes you happy...(as the song says).

PS. Takeuchi and Nonaka, the godfathers of Scrum, have spent much of their later careers studying knowledge creation. Seek and ye shall find.

Against Central Planning

In general, it seems simpler to have one central brain plan everything. And to assume that that brain has it right. And "everything will work out for the best in this best of all possible worlds" if the Central Planner plans it for us rationally. (Cf Candide.)

Suffice to say I do not buy this horse hockey stuff.

Complex adaptive systems rule. You add a few basic constraints and the "system" (with multiple decision units) figures out the rest in real time, and continually adjusts.

This is not to imply that CAS's are perfect. The world is a tough place. Stuff happens. Any given CAS can not always figure it out fast enough nor always adapt fast enough. But a decent CAS will whoop a very good Central Brain every time. Ok, over a reasonable span of time, like a year.

My hypothesis is that one of the key problems is that the world (even one domain of it) is so complex that one brain cannot envision the whole elephant at one time. (See the 6 Blind Man and the Elephant story.) Thus, a CAS, with multiple "views", has a much better chance.

The is true for humans. (Taken as a whole, each of us is a CAS, although some of us seem intent on dominance by one "logic" unit.)
For families.
For Teams.
For small firms.
And, if done at scale, for larger firms.
Clearly the free enterprise system in the US is a CAS (or what is left of the free enterprise system).
The world economy is also a kind of CAS.
(Not to mention other modes (than economics) of how groups interact across the world).
Perhaps there is a higher scale too.

A few people, with Scrum and similar approaches, are enabling CASs to develop at the Team level. Once we have multiple Teams in a firm going hyperproductive, what is far less clear is how to be effective in having Teams interact in a CAS way, as parts of one higher-level CAS. In Scrum we have some approaches to this (Scrum of Scrums, etc.), but it is less clear that we can have a group of 5 Teams then jump to "hyperproductivity" for that group.

This is normal. We have not learned to walk; we really don't need to worry about running well yet. In scaling Scrum.

Let me note in passing that, in the economy, more and more firms are working in explicit partnerships. And the partnerships take many different patterns. The Lean guys talk about "full" value stream mapping, across all the partners needed to bring customer satisfaction. So, we in Scrum perhaps have some more ideas yet that we can borrow from.

Most of us, I included, continue to be seduced by the notion that the overall firm (say, of 10,000 or 100,000 people) must also have some "overall" plan. Which would need to be prepared centrally, right? Certainly it seems this would be more efficient. (At least in one use of that term.) And then I think about efficiency and the firm, and in real life I find firms do quite well being extremely, obviously very inefficient. (In one or two meanings of that term.) They do something or things well, but maybe efficiency (in the way I am thinking of it) is not the key. Umm, maybe the oak tree's innovation approach is wiser than we knew.

Perhaps eventually we will completely give up on the Central Planner "fixing things" for us.

"Calling Dr. Jung, calling Dr. Jung."