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

Question:

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 ________________________________

Answer:

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!