Strategy as Distributed Phronesis - Nonaka

Some of you will recognize this name.  He is one of the two men who wrote The New New Product Development Game, which directly lead to the creation and naming of Scrum.

Here is slide deck on "Strategy as Distributed Phronesis."

Sounds like a mouthful, but it has some great stuff in there.

I think you will enjoy.

nonaka phronesis slides

 

What does the Executive Team do in Scrum?

In an earlier post, we described an Executive Team in a smallish company (aka an oversight group in a larger company).  And we described a simple situation.  For example, the oversight group is responsible for 8-10 initiatives. Or, basically, 8-10 Scrum teams.  For now, let's make it simple, and imagine that each Scrum Team is working fairly independently.

What does the Executive Team do?

First, the ET is getting new ideas, new projects, new initiatives.  The ET must decide which things to start and which to stop.  Ideally, we stop an initiative just after the Team has delivered a significant release, so that the productivity of the Team is not wasted.

And the ET resolves conflicts between Teams.  Team 1 wants George and Team 2 wants George.  Often the Teams and/or some individual managers can figure out this problem quite well, but sometimes it requires and Executive decision.

The ET does high-level budgeting.  For example, how many initiatives should the firm have in flight at one time.  And this decision affects the start-stop decisions.

The ET monitors the overall impact of the initiatives on the firm and the customers.  Only with all the different perspectives on the ET, can the ET (as a team) see the overall impact of all the different factors.  (And there are so many different factors.)  No one person sees them all, but the ET (if it has the right people) sees them all.  Or, at least should see them better than any other group.  (We must admit that we are all human, and so the ET too will be imperfect.)

So, the ET must act as a real team, and decide for the overall good of the customers and the firm.  And not have each person focus only on his individual area.

So, in a broad sense, the ET (together) sees and looks after the broader interests of the customers and the firm.  Everything considered.

And, of the 3 levels I mentioned before (Team, business stakeholders, ET), only the ET together sees the overall picture. And only the ET has the knowledge and power to make better, high-level, decisions.

***

One key thing the ET must decide: The priority order (today) of all the initiatives.  And of all the 'ideas' that might be done.  Only together can they compare and decide on the probable impact to the customer base and the firm.  And then start the best initiatives and stop the least valuable initiatives.

***

One more key factor: Do not under-estimate the motivational impact to the Team of seeing the ET once per month (briefly).

First, the Team will realize 'hey, this must actually be important work, because the ET cares about us.'

Second, the Team will say 'darn, we must have some good stuff to 'show' every month, to impress the ET.  We can fool around or lose focus.'  (By show, I do not mean a demo to the ET.)

Third, when the ET likes it, the Team can feel proud.

Fourth, the Team can ask for help from the ET.  'Give us some money or some people or just approval to fix our top impediment.'  The Team will need to pull together a decent business case, but the ET must look at and decide on this requests.  (Note that a business stakeholder/manager could also get some of these requests too.)  'Who knew the ET would actually help us?' is what they often say.

***

What does an ET do for a Team?

Most often two things:

1. 'We like your work and your progress. Please continue.'  If this can be done briefly, at low cost, this should have a big impact on the Team.

Note: While doing this, the ET (for the customers and the firm and the overall motivation of the Team) has re-confirmed, after all the change and everything we have learned in a month, that, compared to anything else this Team might do, this is still one of the Top X initiatives.

2. The ET helps the team with one impediment.  Ex: The ET directs that George give not just 10% but 20% of his time to the Team.  Ex: The ET gives the team $3000 to take a course on some aspect of Java.  Ex: The ET directs that the Team engage the Communications group in the next week.

Let me take that last example, and go a step further.  What should have happened is that the Team itself contacted the Communications dept, and Team and the Communications dept worked out that problem soon enough.  Or, failing that, that the business stakeholders (manager) associated with that Team had intervened and had gotten that conversation going sooner.  And the Communication group also has the responsibility to reach out to the Team and contact them, if they see a need.

BUT (possibly) in this case all those thing had not happened (yet) because the Team and the manager did not see the big picture, and could not know that because of X Y and Z, that engagement with the Communication group needs to happen sooner.  And the ET, seeing the bigger picture, directs that that conversation happen sooner (in this case).

So, we must recognize two things:

1. Human being will fail sometimes.  One failure does not mean that the responsibility should be taken away.  When we manage, we must assume some degree of failure.  So, we have backup systems, but only to some reasonable degree.

2. Even if one has a responsibility, one will not always have the information to execute well on that responsibility.  In this case, the ET, having the broader view (as a full Team) could see the issue and direct a resolution.  (One could call this fixing an impediment.)

***

Trade-offs

We must emphasize the following point.

In managing innovation, there is a strong trade-off between managing things better and the cost/overhead of management.

It has been our tendency to over-manage innovation.  And mostly what that does is destroy the productivity of our knowledge workers.

The ET meeting for any one Team must be brief.  Probably 15 minutes per month.  (One might argue for 30 mins.)  Obviously, if the Team is doing badly, or the ET feels it must take some action, then the meeting for that Team might take longer this time.  In any case, the timebox must be managed; all Teams and initiatives are complex and we easily could talk 'for a long time', but with very little additional value added.

In this context, an 'epmo process' must give the ET some information to do their job effectively.  But we must make sure that process does not over-burden the Team with reporting work.   Also, the 'epmo' itself should not become another layer of management... this is bad.

And it is tempting.  The ET people are by definition very busy.  The unconscious desire is to avoid the tough decisions, and to push work back on the epmo person.  The epmo person will never have the broad perspective that the ET has (as a team, if the ET people share the tacit knowledge as a unified team).

Also, for the ET to be effective, the information flow to the ET must be 'clean' or unbiased.  If the epmo person is allowed to 'take responsibility' for things, the more that happens, the more we get the human desire to hide and to only show what we want to show, ie, the ET gets biased information. This degrades the effectiveness of the ET, possibly almost completely (I think I have seen those cases).

Last warning: Let the Team talk directly with the ET.  (Maybe only the PO and SM attend.)  It is tempting to rely only on reports.  In innovation, a huge portion of the inputs are people.  Hence, only by 'looking at the people' can the ET see what is really going on.  Also, only the people can explain what is really happening (all the tacit knowledge that never gets into a report).  And, if the ET decides or directs anything, the people need to understand.

The Team are indeed human and prone to bias.  We have to accept that that happens to some degree.  So, we also recommend that one or more business stakeholders from the Team also be there in the ET meeting, to also answer questions with less bias.

***

We hope you can see from this discussion how the management at the ET level would really work in this situation.

We welcome your comments.

Why are we doing Agile?

We just had Southern Fried Agile in Charlotte.  See SouthernFriedAgile.com

I have 5 take-aways.  For today, the first one.

1. Why are we doing this?

We are not doing Agile for Agile's sake. We are doing it because we think it will help.

And the most important people to help are.... well, first, everyone.  Everyone at the same time.  Unbelievable.  But that is too broad for most of us.

First, the customers.

Secondly, the widows and orphans that own the firm (and, ultimately, it is the widows and orphans who own the firm).

Third, the workers and the managers (although in knowledge work, where you separate worker from manager is hard to see...).

Making people's lives better is often overly abstracted into the notion of delivering Business Value.  And that is mostly correct.  But remember that we are delivering business value to real people.  We are real people, and even they (the customers) are real people.

So, we talk about how lean-agile-scrum is so important, and it is, but only as a means to helping the lives of real people get better.

***

Change is always hard.  They say birth is painful.

If it is 'too hard' to become truly agile in X period of time, should we compromise?  Is it better to compromise?

The logic being: the benefits of X (agile, for us) are not worth the pain of the transition.

(Fortunately for human life, most women do not find this argument compelling enough.  Although you see in the eyes of 'new' mothers some thoughts like this. Before the baby is really real.)

Umm.  Very difficult question this is.  Worry about it you will.  Act you must.

And if we compromise (of course we humans always do), should we become complacent with what we changed to 'in the first jump'?   NO!!!!!

***

One of the key points...   We agile people too quickly assume that others (eg, executives) naturally understand why agile is important, and 'care' about agile.

And, one point is, they often do not.  They care about people, they care about business goals.  But, they do not see the necessary connection between business goals and agile.

We must always remember this.

Even with people who understood agile a month or two ago, we always should remind them, and show them well, how agile gives them the benefits they need and want.  Agile is a means, not an end in itself.  Let us not conflate the two.

***

Do I still think that, in most situations, by doing less Scrum-Butt people will get more benefits.  Yes, strongly!!

Do I think that everyone everywhere must immediately do, and only do, pure Scrum?    Well, I think that is too broad or aggressive a statement and not worth answering. For example, I will never talk to or even see 'everyone'.

 

Impediments - Charlotte - Oct 2014

This the list that this class identified:

1. Indecisive
2. Little stakeholder engagement
3. Started development late
4. LOB changed strategic direction
5. Assumptions
6. Lack of Test Environment & Data
7. Undefined risk
8. Lack of communication
9. Missing requirements
10. Too many bugs
11. No DOD
12. Time constraints (this is not yet a actionable impediments...but an issue for analysis IMO)
13. Backing into dates
14. Unreasonable deadlines
15. Poor leadership
16. Politics
17. Loss of team members
18. Opaque decision-making
19. No standards and practices
20. Third parties
21. No team - everyone for themselves
22. Change
23. Scope creep
24. No mitigation strategy
25. Poorly defined success criteria
26. Bad or no acceptance criteria
27. No business face time
28. Uncooperative team members
29. Laziness*
30. Lack of clear communication
31. Poor documentation
32. Difference in down time
33. Additional server & DBAs (lack of)
34. Product delivered on time with fewer defects (lack of)
35. Cloning test envronment
36. Team location distributed
37. New requirements
38. Bad requirements (or changing, in the waterfall model)
39. Requirements never done
40. Poor grooming
41. No plan
42. Changing needs
43. Not tested properly
44. QA too little too late
45. Poor testing/QA
46. Disengaged product owner
47. Bad attitude
48. Competing priorities
49. Loss of funding
50. Epics as stories
51. Change priorities
52. Poor quality
53. Not focused team members
54. Organizational dysfunction
55. Bad coding practices
56. Lack of full participation
57. Incompetent people
58. Single points of failure
59. Technical solution determined by Business was not achievable by Technology
60. Shifting business priorities
61. Decentralized execution teams working in silos
62. Needed expertise not available
63. Budget
64. Not enough time (again, an issue but not clearly an impediment itself...needs further analysis IMO)
65. Non-team players
66. Mis-managed timelines
67. Budget overruns
68. Poor grasp of requirements
69. Multiple priorities
70. Complete requirements (lack of)

See earlier lists for further discussion.

3 Ways a Scrum Team is managed

We think it is reasonable to manage a Scrum in at most 3 ways.

1. Self-management.

The most important way is to tell the Team that they are respoonsible for managing themselves to success.  That is, within their scope, they have to figure out what they need, and then get it.  They have to define all the details of success.

2. Business stakeholders.

The business stakeholders directly working with the Team have a responsibility to provide management over-sight. Honestly, though, what I see is that these managers usually over-manage.  They do not let the Team self-manage enough.  And this hurts.

But, if the Team is not managing itself well, they must do something.  The first thing is to say things, ask questions, but let the Team make some small mistakes.  That's the way they learn.

But if the mistakes continue or might be big, then these 'managers' must intervene.  Usually by helping with one or two impediments.  Possibly by making some people changes.  At the extreme, by dis-banding the Team.

3. Oversight of multiple Teams

There should be an oversight group.  In a small company, this might be the Executive team.  In a larger company, maybe a 'team oversight group'.

The purpose of this group is to look at each team and evaluate whether it is doing 'well enough' to continue, when compared to other Teams and other opportunities.  And, they can help a Team as well.  And resolve some conflicts (eg, two teams want the same person, and that's not possible at the same time).

One can also imagine that the business stakeholders might not do their management job, so this is a backstop to that level of management.

BTW, we strongly urge that the Team itself be there when the oversight group reviews them.  The Team can answer questions, and they can take any feedback 'back to the Team' with much less mis-understanding.  Try to keep the communication clear.  It might be ok if only the PO and the SM appear at the oversight group.  Maybe.

***

So, 3 'levels' of management.  And that is *enough.  The poor Team needs time to actually do something, instead of being managed so much that they go crazy.

In Scrum, it is pretty clear to see if they are making progress, and usually even if they are making enough progress.

It is just wrong to over-manage innovation.

 

9 Key statements about estimating

I won't explain them now, but here's the summary...   

1. Estimations can be mis-used by some managers (and have been).  Watch out!

   
2. Customers want some kind of estimate. (Ask for their details about what kind of estimate they want.)

   
3. There is a trade-off between the time it takes to estimate and relative accuracy.  Keep it shorter (usually) (of course, that depends on how short you were thinking...).

   
4. Always re-estimate.  Usually many times.  And arrange things with the 'customer' of the estimate to expect a re-estimate.  Make it easy to re-estimate.

   
5. Re-estimate when you are smarter.  Devise things so that you get smarter

   
6. Always discuss the variability of the estimate.  At least in some way, with the 'customer' of the estimate. ('I can promise 2015, but I can't tell you which month.'  A small joke, illustrating the range method.)

   
7. People can learn to estimate better, and faster.  Sometimes they start out terrible.

   
8. It is not the plan, but the planning.  We (the Team) get so many wonderful outcomes while we are planning.

   
9. Estimating can be fun, if you do it right. (But expect many teams to start with latent fear due to #1.)

Interested in your comments.

Bonus points if you notice a reference to John Legend.

Can the Team promise a date?

I think this is an important question.

Promise.  Umm.  What does promise mean?  Can Joe Namath promise a Super Bowl victory?

(I think he said 'guarantee'... and, oddly, his Jets team did actually win it.)

***

Let's say you have a fairly big project, that maybe requires 3 releases that happen every 3 months.  So, overall, a 9 month product before it is 'fully' built.  (IMO, no product is ever fully built; the customer always wants more.)

So, it is what I used to think of as a normal situation.

To make it easy to describe, let's imagine we are at January 1, and the releases will be March 31, June 30 and September 30.

In this situation, can the Team promise on Day 0 (Jan 1) that the releases will happen on exactly those dates?

Well, maybe they can.  In other words, they can say "We will release on those dates, and we can give some rough ideas today what the functionality will include, but it may change some."  I think they can usually or often say that.

Will change happen?  That is about the only thing that is a 100% certainty.  (Ben Franklin said death and taxes were certain, but Buddha said "Everything changes, nothing remains the same.")

For certain, some bad change will happen.  We will disrupted.  People will be 'taken' from us, in some form or another.  Important features will be discovered later.  (BTW, discovering important features is only bad when it happens 'later', and really only because it leads to a delay, and we have a weak mechanism for doing the customer trade-off between delay and the value of that feature.)  Etc, etc.  What is uncertain is how much 'bad' change will happen.  But, we will certainly have some bad change.

If we are professional, we will also have good change.  What is that?  Well, we will learn.  We will become smarter.  We will remove impediments and become more productive.  And, if we generally professional, this good change is certain too. What is uncertain is how much good change we will have.

***

Can we make a useful prediction of the release date for every product?

This is a very hard question, since no one can even imagine 'every' product.  But it certainly sounds like the answer must be 'no'.  One can imagine situations of many unknowns, extreme change, etc, etc.  We can issue a prediction, but, at least for those 'hard' products, it will turn out to have been useless or worse.

So, 'useless' predictions are possible, I think.

But, does the 'fact' (well, we posit it as a fact) that some predictions will be useless make all predictions useless?  I think not.

How accurate does a prediction need to be to be useful?  Well, I find most business people do not need that much accuracy.  They completely understand risk and uncertainty.  But they want some better information. Often they will say 'can you get me better information than the competition has?'.... a very low standard usually, but when we say it that way, you see how they will use the information.  They just want to improve their odds.  The odds of success, and also the odds of not losing too much on a gamble.

***

Now, back to the Team's point of view.

A promise is not a guarantee (Joe Namath not withstanding).  A prediction is an educated guess about the future.  And, as any adult should know, to predict is difficult, particularly of the future.  (That's a variation on a quote from the Latin.)

Can managers mis-use a prediction?  Most certainly.  And some people called managers have brutally punished the Team when their forecast was not accurate.  This is not right.

Typically, managers should not even see the Day 0 prediction.  But, after some small number of sprints (given something like a 9 month situation), most Teams should be able to give a reasonable prediction.  It is never a guarantee, because something weird could always happen. But it is usually a useful business prediction, that can enable useful business decisions.  Decisions by managers or decisions by customers.

If you are in the Team, when should the Team 'issue' these predictions?  Well, that is a very hard question, that requires lots of judgment.  It depends.

It depends on whom they are talking to. How much that person (that group) understands that things might change.  How much we have learned.  How much uncertainty this product has compared to others.  How close it is to the release date.

There are many factors.

But, as a coach, can we in fairness suggest that Apple never tell the customers anything?  Should we suggest that Apple actively deny any rumors about a future iPad?  And say, 'we have no idea when the next iPad might be ready?'  (Today Apple is expected to announce a new iPad.)  Apple should never tell its suppliers when to expect to start building the new iPad.  Never tell its managers when the basic development of the iPad might be done? (So that the managers could talk to the supply chain.)  Clearly, in business, some predictions must be made.  It is just required by business.  If the company and 'rumor' does not make a prediction, then the people themselves will, and often a very wrong prediction (too early or too late).

And, of course, some understanding of the degree of uncertainty needs to be communicated, if the person can listen to it.  Sometimes we use a percentage. Sometimes we use a range.  Sometimes we use only non-denial of 'rumors'.  Or just words ('we think it will be announced in the Fall of 2014').  But we urge you to help those you are working with (eg, help your customers) by giving them some sense of the degree of uncertainty.

The uncertainty can vary quite a bit, from one product to another.

***

In summary:

1. Be careful making predictions.

2. Sometimes bad things can result from making predictions.  (Ex: Some teams have, to my horror, been forced into a Death March to make some 'predicted' date. Unbelievable that humans would do that, but it has happened and continues to happen, we think.)

3. Again, do not make predictions lightly.

4. You usually must make a prediction at some point.  People will require it; it is the nature of life.

5. Try to assure that the person understands the uncertainty in every prediction.

6. Try to establish that a new and better prediction will be made later (when you are smarter).

7. Accept that life has risk. ie, Make a prediction.

8. Learn to make useful and relatively accurate predictions.  The best way to learn that is to ... practice.  By making real predictions, and seeing how life turns out.

9. Never pretend that a prediction is a guarantee.



 

Public Impediments - Charleston Oct 2014

Until you are perfect, you have impediments to fix.

Here are the ones identified quickly in the course in Charleston.

From an Agile point of view, I am not sure I would agree all are impediments.

1. Team member looking for other work
2. Lone wolf attitude with some team members
3. Changing technology
4. Lack of specific skills
5. Uncontrollable outsiders' influence
6. Team churn
7. No success criteria
8. Poor communication
9. Different areas/teams not working together
10. Micro-management
11. Unrealistic expectations
12. Project uncertainty
13. Lack of QA
14. Lack of Development [people]
15. Not enough teammates or do not have all skill sets needed
16. No contact with end users
17. Scope creep
18. Scope changes
19. Funding - money was cut
20. Not understanding what the customer really wanted
21. No direction or poor plan
22. Unclear requirements
23. Lack of formal or clear requirements
24. Customer not trained properly in agile
25. Intractable customer

Not sure I understand what each person meant by every one of these.  But I feel strongly we start with a rough public list. And then we aggressively work on fixing the most important problem first.

Maybe this list helps your people identify a better list for your team.