Topics for the Executives (managers)

I was brainstorming what kinds of topics or exercises the executives (or senior managers) need. This also includes things for the managers close to teams, but it is not especially for them. OTOH, we're not addressing the CEO of JP Morgan Chase, either.  In an example with that kind of firm, we mean the 'executive' or head of a unit of the firm, with maybe 150 people reporting to her or him. Here is what I came up with in a time box.  Not everything, not perfect, but I think some good ideas.

The List

  1. Team self-organization and leadership
  2. The basics of Scrum. (We maybe start with this, and also end with this.)
  3. Reducing the negative impact of the matrix
  4. Management is required with Scrum (but a different kind)
  5. How to use the new levers of control (and how not to use the old levers)
  6. Letting the teams fail (some) and guiding them toward self-management
  7. How big the agile transformation is. And why it is hard.
  8. Let's draw the 'future' organizational picture (future = 6 months from now)
  9. Business side vs Technology: Going from distrust to collaboration.
  10. Influencing better collaboration with the business side
  11. Is it going to be a struggle to have dedicated teams?
  12. How do we manage the chickens? (The people and groups who must support the Scrum Teams.)
  13. How do we manage to get less Scrum-Butt
  14. What are our biggest impediments now? (The list mostly should come from the teams, but let's get their thoughts now.)
  15. Can we have an Impediment Removal Team?  Can we have a Management Scrum Team?  Can we have an Executive Action Team?
  16. How do we organize the chickens to get greater agility (faster release delivery).
  17. Focus and Deliver. Aka minimizing the interruptions and distractions of 'other work'. Stopping the 'death by project switching.'
  18. Minimizing WIP to speed the delivery of finished releases
  19. Using the new metrics
  20. Management must help fix some impediments (people, money, approval, hard work)
  21. How do we learn to double our velocity (productivity)?
  22. Scaling. First, do we really need it?  Second: KISS.
  23. KISS.  More generally: It is important to keep things as simple as possible.
  24. Getting the right product owners and 'business stakeholders' (people who will give good feedback every 2 weeks)
  25. Leading change. Most executives are bad at this; to be fair, it is very hard. Engaging everyone in the change
  26. Influencing the cultural change
  27. The agile adoption backlog (adaptive action list)

If we educated the executives on these topics and they started taking more effective action, could it make a difference? Your comments please.  

Questions: Agile Release Planning


Hi Joe! Hope you are well. We are cranking up the Agile Scrum. I know you are likely very busy, and I tried to find answers to my Agile Release Planning questions below, but I am not finding what I am looking for on the net. That said, I have three quick questions that I think are somewhat specific and hopefully you can answer in 2 minutes or less. We are following your lead and implementing ARP, but in our two pilot projects we had some confusion and overlap. Using this ARP chart you did for us as a sample exercise:

  1. Roles:  Is this meant to mean:  Identify what “user roles” need to be accounted for so that when you write stories all “roles” are included?  As a _____, …
  2. If we had 50 stories, or created 50 stories should we “target” completing Planning Poker for all 50 stories, or is Planning Poker optional at ARP since you have the arrow pointing towards –àSP?  If we did do planning poker at ARP, would we do it again at Sprint planning?
  3. As a best practice, should we have or add Acceptance Criteria to the stories during release planning? My thought is “no, not really required across all stories at ARP, more targeted for Sprint planning”

Thanks in advance Joe. Regards, Michael ________________________________


  1. Roles. These are the roles of the end-users of the product. These are NOT the roles in the Scrum Team. So, we often think of them using words like 'actors' or 'personas.' And, yes, these roles (I suggest you want 5 to 7 of them) are used in the first part of the user story format (e.g., “As a [roles x], I can…”).
  2. Planning Poker. Yes, we want to do planning poker for all the stories we initially identify in the Agile Release Planning day. And I suggested that for about 6 months worth of work for one team, the right level of granularity would be about 50 stories.  So, yes, for all 50 stories.  This should take about 60 to 75 minutes. In other words, they do it fairly quickly. Why so quickly? (Well, to be honest, some people experience this time as slowly, and others feel it is much too fast.) Why so quickly? In part because they will learn more (e.g., as they complete the ready, ready criteria for each story) and as they learn more, from any source at any time, they can re-vote on the story points for a story. The typical time to do that would be in one of the weekly release plan refactoring meetings. Remember, they are definitely expected to re-vote some stories, and they are not expected to re-vote all the stories every Sprint — just the ones they think they are smarter about. Typically that would be the ones about to go into the next Sprint — not all of them, but some of them, or ones where we have notable new learning.
  3. Acceptance Criteria. This term is used many ways. I think of the acceptance criteria for a software story to mainly address, at a high level, the basic tests for that story. No, I do not recommend, in the initial Agile Release Planning day, to identify all the acceptance criteria for each story — that's a lot of work. But, as the team is voting, on some stories they will identify some of the acceptance criteria. When they do that, someone should write down those 'assumptions' (and any others), and if the assumptions change that story should probably be re-voted.  Later, as the stories are being 'developed' in the release plan refactoring 'red zone,' then all the acceptance criteria should eventually be identified, as well as lots of other information about each story. If that new information impacts the 'sizing' of the story, then that story should be re-voted. Anyone can suggest to re-vote a story. Some people go a bit crazy and want to re-vote too much, and some teams do not re-vote enough. A good ScrumMaster helps the team find the right balance.

You did not mention Business Value Points, but I wanted to add that we want to vote BVPs on all the stories on the ARP day. The BVPs and the SPs enable is to calculate the R factor for each story, which is key to ordering the Product Backlog better. (You will recall that the R factor is not the only driver of the ordering, but one of the key ones. The basic ROI concept. Do the highest ROI first — a basic business principle.) Enough? Thanks!    

HBR on Agile! May Issue.

The Harvard Business Review has 3 new resources on Agile now.

The original classic article is: The New New Product Development Game by Takeuchi and Nonaka.

The first of three new resources is this article:

 This is by Darrell K. Rigby, Jeff Sutherland, and Hirotaka Takeuchi.  Rigby is with Bain. Sutherland is the co-creator of Scrum. Takeuchi is a business school leader (now at Harvard), who also co-wrote “The New New Product Development Game.”

 Key Topics:
1. Learn How Agile Really Works
2. Understand Where Agile Does or Does Not Work 
3. Start Small and Let the Word Spread 
4. Allow “Master” Teams to Customize Their Practices 
5. Practice Agile at the Top 
 6. Destroy the Barriers to Agile Behaviors

This article is in the print magazine.

In addition, there is a digital article.

Also a video.


Stop Starting, Start Finishing

The phrase in the title is a well-known agile phrase, but perhaps not well-enough known.

In one way, it is saying: minimize WIP.  Work-in-process or work-in-progress.

In another way, it is saying what my friend Mike Vizdos says: Focus. #Deliver.


But let me tell a story that gives a different meaning.

A few months ago, I was giving a class in Toronto, in the usual hotel I use there.  There were 3 of us talking after the class. One of us (an attendee) was a smart woman from a fairly well-known company.

I forget exactly what we had been talking about, but in a kind of segue, she said: “You know, two nights ago, I got home and put my stuff down and started to think about whether I had gotten anything accomplished that day.  I mean, I had worked hard that day.  Many meetings. Many emails.  Phones calls. I had been very, very, busy all day.  But: had I accomplished anything?  And I was sad, because my feeling was that I had not.  And in fact, I often have that feeling.”


In my view, this is a terrible way to live. Well, terrible is maybe over-blown since people can and do live in much much worse ways.  But it is not good.  At all.  Especially since we know ways to live much better.  She could be living a better way now, I think.

One idea is: Stop starting, and start finishing.

A way to apply this is: Decide in your 'large' department (of 30 to 300 people) to prioritize the major sets of work.  Dedicate people to one team. (That means 100%.) And have each team work on one and only 1 set of work until it is 'complete.'  Meaning: everything useful is delivered to the customers.  (Useful means probably only the top 20% of the work, if you ask Pareto.)  Then, once they have delivered it,  give that team the next most important set of work.

People have satisfying lives when they see customers get the product and enjoy it.  And they see that frequently.



The Team sucks, the Backlog sucks, the Done Done sucks! I know! Let's scale that!

I just led a discussion with Agile Charleston on that topic. The idea for this topic comes from a talk by Mike Cottmeyer at the Scrum Gathering in Orlando. I agreed with Mike that these 3 are 3 of the most common problems with Teams.  And they are fundamental. (One might argue that X is even more important.  Not going to go there….). An additional conclusion:  I think these (or fixing these) are prerequisites to scaling.  More on this below. So, very quickly, when are the team, the backlog and the done-done good enough? Here are my answers expressed much too quickly.

  • Team

It is a stable, dedicated, real team that knows Scrum, values Scrum, and has achieved success with Scrum.  (One could replace the word Scrum with Agile.) They have a common mission and the believe in it together.  They are motivated (at least some) and see the value of being a Team.  And they have shown all this in a single-team context (because it is easier to teach and learn this in a single team context).

  • Product Backlog

The backlog is organized (mainly) by business value, fairly competently. And certainly in a way that can be explained and no one laughs.  (Probably including the ROI concept per story as well.) The stories are small enough, at the top.  To me, 8+ stories are needed to fill a 2 week sprint.  And all 8+ are about the same size. The 'details' are delivered to the Team competently.  Jeff Sutherland calls it the Enabling Spec.  At least we have a notion like the ready, ready criteria or the 'definition of ready' and 'just enough, just in time' information is given to the team so that they ddo not 'spin' during the sprint trying to figure out 'what is this story really?!'  Virtually always, the implementers feel they fully understand the stories before the stories go into the sprint. (There is still sometimes some learning in the sprint…but at the beginning, they think they understand them.)

  • Done, Done

The Team has a good fairly detailed Definition of Done.  And they follow it. And it means that all the bugs are fixed. And it means that virtually no technical debt is growing. And, with a good product backlog and the good DOD, of course they reliably get all the work done that they 'commit' to each sprint.  Reliably means roughly 70-83% of the sprints end with all 8 stories done-done.  Some sprints more, and a few sprints (out of 10) fewer stories. Fairly reliably. *** To me, if a team can do those things, then at least in those areas they are now 'good enough' to think about starting to scale. Now, if they suck in those areas, what will happen if you ask them to scale?  Basically, I think you are setting them up for failure. Just sayin'. Scale down.  You may have to scale, but scale down.  Keep it as simple as possible (but not simpler).  As Einstein said. Enough for today.  Comments welcome. Thanks to the people at Agile Charleston for there thoughts expressed above.