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.

https://hbr.org/1986/01/the-new-new-product-development-game

The first of three new resources is this article: https://hbr.org/2016/05/embracing-agile

 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.

Enjoy!

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.  

Scrum 201 Course - Why?

Why the 'Scrum 201' course?

Problem:

This course addresses two problems. (A) how to get more success from Scrum. (B) how to advance your career. We are finding far too many teams are only getting 20% or so improvement with Scrum.  This is by far too low.  One way to address this problem is more education on the simple but complex thing called Scrum.  And education on the things around scrum that are necessary or typically helpful in bringing success.

Background:

The course is an intermediate course, somewhat more advanced than our intermediate CSPO course.  Participants must have a CSM or CSPO certification (or the equivalent).  The course lasts 2 days, and we strongly recommend the third day, which addresses mainly agile release planning with a real project per table. (For those who have already done this workshop with a CSM or CSPO course, we are expecting you to take it to the next level with the Team.) The course leads to a Scrum 201 certification from LeanAgileTraining. And leads to an additional 22 SEUs toward the Certified Scrum Professional certification from Scrum Alliance. And it provides 22 PDUs for the PMI.

How:

The idea is that interactive education can teach people to become more effective.  There are other methods (eg, coaching).  But we think this is a key element. Methods include lecture and discussion and exercises.  Just as we do in CSM courses, for example.  In addition, we expect attendees to engage more actively.  So, we expect everyone to propose a 10 minute segment on one topic, and to make that proposal before the course starts.  We will review the proposals, and select a few to use in the course. We also expect people to learn more in the small groups (tables) and then report back to the whole group. And do this more than in a CSM course. We also will allow participants significant leeway in deciding which topics we will address. And of course a lot of the work will include questions and answers. We will cover many topics, and many types of topics. We will generally address things in enough depth that you feel you have what you need to be effective. We will not spread peanut butter across too many topics. We will definitely review the basics, and discuss what we call Scrum-Butt.  We will discuss Jeff Sutherland's ideas on the 9 key patterns necessary for success. For more on the long list of topics we will pick from, see here. All subjects necessary to success are open for discussion.  This gives us a huge range of different types of subjects.  A few key words round areas we will address: technical issues, people issues, management, leadership, self-organization, decision-making, the flow of requirements, testing, disruptions, culture, metrics, business value, addressing the old culture or structure, managing change and getting change to happen, where does the X role fit in?, etc.

Who should attend:

Anyone interested in lean-agile-scrum.

• Managers
• Business people
• Implementers (eg, coders and testers)
• SMs
• POs
• People who want to Agile Coaches
• Others (ask)

Of course all the people in the team (this will be useful for every team member).  Whomever in your firm (or outside your firm) you need at the next level, to help everyone get to the next level. Together.

Advancing your career:

Our first goal is to improve your life, improve the life of your team, and to help you make the lives of your customers better. And, more specifically, advance your career. How? First, by giving you the knowledge to be more successful. Second, we provide SEUs toward the CSP.  We believe that for many of you, you will be given access to more opportunities to be effective with lean-agile-scrum if you have the CSP.  Or at least the knowledge that comes with it. Third, we think that many of the skills and much of the knowledge will help you in whatever direction your career takes.  Perhaps more if you stay in a lean-agile environment, but much no matter where you go.  For example, if you really learn servant leadership well, some of you will easily win many promotions as a manager.

The future:

We understand that the Scrum Alliance is thinking about defining a course that will be very close to this course.  We will keep you posted as we learn more. We hope you and your colleagues will join us for a Scrum 201 course soon. See here for a list of courses. Your comments on the Scrum 201 course and ARP workshop are welcome.    

Jeff Sutherland Google Talk (2014) on "Scrum" (book)

Here is a fairly recent Google Talk by Jeff Sutherland. (Late 2014.)  The talk gives some key ideas from his recent book, Scrum. The talk is long, about an hour. But you can stop it any time.

Lean Agile Open - April 15th, 2016.

We had a great event in Charlotte yesterday, and I hope you did not miss it. Self-organizing people did the best they could (which is actually a lot) to learn as much as they could with other smart people. About Lean and Agile topics. With, I think, the goals of (a) becoming more effective, and (b) making their own loves, making the lives of their team members, and making the lives of their customers ...better. I don't want the event to sound too goody-goody. We all had fun too. But what I want to emphasize first is: we self-organized. And then: it was good. Thanks to many people! Let me name at least these people: Cassandra Wagner, Riddhi Gupta, Murali Varadarajan, and Bob Petruska. But many others also contributed. What was the value?

1. Senior people at 'waterfall' companies could see that regular people could self-organize.
2. We all saw that we all can help each other.
3. Each of us learned some important things to use back at the ranch to make lean or agile work better at our real work. Each person got to focus his learning where he or she wanted.
4. Most or maybe all of us were 'enlivened.' We felt more hope, more belief that things can change, less alone, more hopeful. We had a sense of a brighter future. This is something that you can never 'buy.'

We did we learn? As I said, we each learned some specific things about specific areas of lean and agile. All good, but not my focus for right now. For some who were new to Open Space, we learned to trust 'open space.' So, I hope we learned to be more courageous next time. As your parents always told you, it is important to trust people. Of course, not to trust too much. But to have some trust, and to be trustworthy. Because more people will have more trust next time, the event will be bigger and better. More people now know how to 'use' Open Space effectively. If we use these events well, this will start to change the community. No man is an island. We are all inter-connected. And we all influence each other. These events, repeated regularly, will change the community. And they can, perhaps more slowly than you may want, change the culture of your company. We will use these events to continue to .... Well, the mundane way to say it is: To get better and better results from lean and agile. But I hope in your heart or stomach (those of you who were there) you feel a stronger energy, an energy you cannot ignore, and that it draws you much more strongly than those simple, mundane words.    

The A3 Approach

In every class, I teach the A3 approach to kaizen.

Kaizen is usually translated into English as 'continuous improvement.' In Scrum that means 'removing impediments.'

The first thing to note is that it is an approach.  It is a method, with certain values and principles, and the fundamentals of the approach are more important than the detailed practices per SE.  But, to make an approach into action, you must have practices.

The A3 approach gets its name from that size of paper (for North American readers, roughly 11 x 17 inches).

The A3 approach wants to fit 'everything' on one sheet of paper.  And make it as concise and as visual, and obvious as possible.  The concept is "if you need more paper, you don't really understand it well enough yet."

Then I must mention team-based interactive 'thinking together' at all the right levels.  So, in context, the Scrum Team is trying to get the manager or managers on board with fixing an impediment.  Usually that means the manager must approve ...
(a) money
(b) people
(c) allowing the change to happen (give permission), or
(d) some combination of the 3 above.

The A3 approach supports multiple formats (eg, different section titles) depending on the situation and the need.

Maybe the next thing to say: The A3 approach is tied with the classic PDCA cycle.  Plan - Do - Check - Act.

The context I am talking about, we want to use an A3 document to get the 'planning and approval' done. First.

After the approval, then Do - Check.  After that, 'act' in the sense or reflect and learn and assess whether it solved the problem.  Or assess, after the fact, "okay, we fixed x amount, but should we fix this problem even more?"  (I am imagining that was only partially mitigated a rather large problem or impediment.)

So, use an A3 document to summarize to managers (or potentially other stakeholders) what we plan to do.  The Scrum Team learns to speak manager-speak. (smile)

The A3 sections I recommend (in addressing impediments) are: Problem, Solution, Benefits, Costs, Action Items, Measures.  They are discussed below.

First, I must say: Use common sense.  I make some suggestions below, but you must use common sense in applying those suggestions to your situation. If you are having questions, be aware that the community has almost surely dealt with a similar situation, and may already have a better suggestion for your specific case.  Again, common sense is very uncommon.
<h4>Problem</h4>
Give a problem statement. Sometimes longer, sometimes fairly short.

Perhaps justify the problem. And explain it, often visually.

Two related questions often from the manager:
* why is this problem important enough for me to address?
* is this our most important problem now? (or high on the list)

When you present, be ready for those. (That does not mean you have to address them visibly in the A3 'report'...just be ready.)

To address the important question, often you are tempted to mention ALL the benefits here (eg, to discuss them verbally as you are making the presentation).  Do not.  At this point, the manager wants just one key number that tells him 'I am not wasting my time in discussing this.'

The second, relative importance, may be easier or harder to address.  I would have to know more about your situation.

Often start with a symptom, and ask the classic 5 Whys to get to the root cause of the problem.

Some problems (and even some root causes) are quite obvious.  So, this can be short. Or it can be a long section 'selling the problem.'

Many managers know from experience: often we have a solution looking for a problem.  So, they know that identifying the problem well is often half the issue.  The Lean community and lots of others give you plenty of tools to identify and assess the problem.

The manager may well follow-up with....'why do I believe you have identified the correct root cause?'  Or similar questions.  You may need to have done 'root cause analysis' or the 5 Whys or something similar.
<h4>Solution</h4>
Here you describe the solution you are proposing.  Fairly succinctly.  Perhaps visually.

You might talk about why you chose Solution X over Solution Y.

Often the question is: why do I believe this solution will really fix the problem (root cause) identified?

As suggested earlier, people have two problems in this section of the A3:
(a) the connection between the problem and the solution is just weak. Period. (Human nature I think is the culprit.)
(b) it is hard to quickly and simply <span style="text-decoration: underline;">show</span> the connection between the problem and the solution.

If you only have a partial solution (very common), say so.  And explain, briefly, why you think this solution should be implemented before other possible solutions to the 'bigger problem.'

Again, make the solution as visual as possible.  KISS (Keep It Stupid Simple) for the managers.
<h4>Benefits</h4>
Address all the benefits of the solution.  Both tangible and intangible.

Often it helps to express these as money estimates.  Expect the managers to question your estimates.  Estimates of the future are never perfect, so expect them to revise your estimates.

Try to express your estimates as improvements in velocity, such that we get extra BV delivered in the same time period (say, year).  Usually BV is some multiple of the cost of the Team (say, 3X).  So, the benefits are larger if you see them that way.  If you look at the benefits as only cost reduction, then the benefits are much less.
<h4>Costs</h4>
These are both the tangible and intangible costs.  As broadly defined.

Consider all the costs for 'everyone.'  There might be some debate about what 'everyone' and 'all' includes.

It is classic to have two types of cost: (a) one-time costs, often called 'initial costs' and (b) on-going costs (costs over some future time period).

Again, a manager typically wants all of these expressed 'apples-to-apples' with the benefits. Dollars to dollars makes it clear and simple to the manager (although seldom simple for you).

Again, make estimates of the future, which are always 'rough and ready.'  Expect the managers to question them, and perhaps even revise them.

And the benefits need to be a high multiple of the costs (I recommend 6x, but this varies by the situation, etc).

You may not write this down, but at least consider the personal cost to the manager.  There are many types of personal cost, but one might be political risk, or who he has to explain this to, or 'will I get fired if this goes south?'  Be ready to address these in the discussion.

When discussing costs, the managers will often ask questions like:
* who has to be involved
* how much time is involved
* which other efforts must be delayed if we do this (aka opportunity cost)

In this section we also want to address risk.  Reduction of risk may be addressed in Benefits, but any concerns about increased risk (for any important person) should be considered here.

ROI Ratio: Make very clear and visible the ratio between benefits and costs.  That ratio needs to pass a 'hurdle rate' to be approved.  I suggested 6X above.  Not every firm uses the term 'hurdle rate,' but almost all firms have the concept.  The benefits must be at least X times higher than the costs.

Why? Almost always there are plenty of good things to do. The manager needs the ROI to be high enough to justify executing your proposal versus other (not quite as good) proposals.  We can't do all the 'good' proposals.
<h4>Action Items</h4>
This section can be phrased other ways.  'Next Steps' is a common alternative title.  And it can have different purposes.

But usually the manager wants to know: "If I approve this, what will you do next?"

Maybe the manager wants you to check it out with X or Y or Z person or group.  Maybe he wants to know when it will be done.  Maybe he just wants to know that you have 'a plan that has been thought through, which suggests a high likelihood of successful implementation.' In that case, you might summarize the key steps in 'the plan.'

Some people think this section requires a very detailed project plan.  Almost always: No!  Almost always that is too much information for the manager.  Maybe she would want to know that you had planned this out at some moderate level of detail, though.  (Not to see the detail, just to know that your team has done it.)

Often you are addressing a semi-latent concern, such as: "The last time we did something like this, X (a bad thing) happened. How do I know X won't happen again?"  You might address that concern in this section.
<h4>Measures</h4>
This is a very important section, both in practice and also concept.  Often, even for managers, this is <span style="text-decoration: underline;">new</span> in concept.

In this section you propose how you will measure, after the fact, that the implemented solution turned out to have the success expected.  In this way, after implementation we will close the P-D-C-A loop.

This 'learning after the fact' is vital. In this way you become better and better at solving problems, or as we call it in Scrum: fixing impediments.

In the context of getting the manager to say yes, it has two benefits.  One, the manager is impressed that you thought the measures through. And guesses that if we actually measure X and Y and Z (however many things you propose measuring), that you and your team will surely do a lot better job in executing, since you will be measured later. And if execution is better, then success is more likely.

Two, the manager can also see that if the measures start soon, and if the measures show this proposal going 'south', then the manager can mitigate his risk by stopping the implementation quickly.  Before his boss finds out that 'it did not work out well.'

***

I spent most of the time discussing the A3 document, because that is essential to implementing a basic A3 approach.

One of the key ideas behind A3 is: "Things should be as simple as possible, and not simpler."  (Einstein)  Since we are agile people, maybe the Ward Cunningham version is better: "Try the simplest thing that could possibly work, and then test."  (Ward complains that people often forget the '...that could possibly work' phrase.)

In other words, do not make the A3 document more complex than it needs to be. But do not make it too simple, either.

Related to that, the A3 is a focus for collaboration in solving problems.  The purpose is to work together and become better.  The purposes are not (to pick some bad examples): fight endlessly, CYA, grandstanding, to nit-pick, analysis paralysis, hide the truth (by saying too little), or, hide the truth (by saying too much).

Enough for today.

For more background on the A3 approach, there are many many resources on the internet.  Here is <a href="http://asq.org/conferences/six-sigma/2009/pdf/proceedings/c6.pdf">one.</a>  A good slide deck. If you get into it, you may notice that the A3 approach is used in many, very diverse situations.  So, the 'culture' around it is rich and complex.  But the basics are very simple.  I recommend KISS at first.

Enjoy!

PS. Thanks to Jeff Sutherland and Mary Poppendieck, who got me 'into the A3' many years ago.

&nbsp;

Scrum 201 Course: Agile-Scrum to the next level

I have a Scrum 201 course coming up in Atlanta. This is important, needed and useful. Why? Why Scrum 201? Lots of people have tried Scrum and everyone gets some reasonable benefit. But, you may not have gotten nearly the benefits possible. So, the purpose of this course is to enable you to get much greater benefits. For yourself, for your Team, and for your customers. Key Benefits:

• Better results (you, the Team, the customers)
• More fun (a key value)
• More knowledge in a difficult set of domains.
• The course plus the workshop is 3 days provides 22 SEUs toward the CSP and 22 PDUs.
• More ancillary material (we give you this after the course).

The attendees: I recommend that you bring a whole team or teams. And some of the people around the team. Invite ScrumMasters, Coaches, POs, Managers, ... really everyone. Format: More participatory than most courses. Discussions, exercises, etc. Content: Some core content and some choices among a long list of things to consider. Core Content: The core aspects of Scrum, the basic values and principles. Scrum-Butt. A discussion about why we are not doing the core things more and better. Prioritized Content:

• The underlying principles. Why Scrum works, and all the reasons why each practice is useful.
• How to build a great team (real, dedicated, stable)
• Removing impediments more aggressively
• Improving the Product Owner
• Business Value Engineering
• The ready, ready criteria
• The definition of done
• Better release planning
• The agile contract (fixed-price fixed-scope issues)
• Improving the engineering practices
• Advocating for the Agile Transformation
• Making change happen (large and small)
• Changing organizational culture
• Scaling
• Distributed Agile
• Too many projects at once
• How to manage in Agile
• Managers and Metrics
• Minimizing WIP
• Knowledge workers and motivation
• Smaller stories

And similar items. The list is long. Again, the aim here is to help you and your team get results at the next level. If you are interested, find a Scrum 201 course here.  

A List Summarizing Scrum

We have a slightly improved version of our 'List Summarizing Scrum.' Not many changes, but a few minor ones. A list summarizing ScrumV6 How can this be useful? First, it is only a list, and prints onto one page (front and back). Two proposed uses:

Visit a team, and discuss the list fairly quickly.

The purpose is to enable a conversation that leads to a more successful use of the lean-agile-scrum ideas. The purpose is of course to decide where to improve next. What are [they] doing? What are [they] not doing? Any ideas [they] do not understand? Which areas do [they] need the most help?

Define Agile-Scrum at your company

The list is a start at defining what you mean by agile at your company. Perhaps you have a rule that says "If you are going to be 'agile,' you are expected to be doing the things on the list. If you need to make an exception, please speak to Dr. Freud." The notions behind this rule are several.

• Often 'agile' has no definition, and this often leads to unprofessional agile.
• Things can be crazy 'out there.' (Hence a smiling reference to Dr Freud.)
• There is a need for each team to be different, so some allowance needs to be made for that, even at the 'framework' level.
• Often teams are junior or do not understand agile fully. Or have mistaken ideas about agile. Once they talk to an expert, they see the 'errors of their prior thinking' and decide to do agile more professionally.

We recommend more the carrot than the stick. That is, people should be encouraged and supported in doing agile professionally, rather than punished when they 'do not comply.'

Q: Becoming a good ScrumMaster

Q: "What is your advice on becoming a good ScrumMaster?"

A: This is a good and difficult question.  The main difficulty is where to start and how best to express it.

First, what is a good ScrumMaster?  What makes one better than usual?

You may think it odd, but the first thing I want to say is: the team is having more fun.  Why do I say that?  Mainly because more fun will lead to higher business value.  And it leads to a virtuous cycle or circle of cause and effect.

We do not mean silly fun.  Well, it could be silly a bit (as in a quick joke and some stress relief).  But we mean more the 'serious fun.'  People are enjoying their work. They think of work almost as play or fun.  They would almost pay the company to be allowed to do their job.  That kind of fun.

For example, they enjoy working in the Team.  And while they are serious, they often smile and laugh as they work with each other and talk to each other.

Second, more self-organization.

This is hard to explain, I think.  "You make people self-organize" is my joking way of saying it.  It is a joke, because you cannot really make the team self-organize.  But you can, as a SM, coach and advise and set up the right conditions for self-organization.  And then address any people (or other issues) that inhibit it.

You let people be free. Well, yes and no.  You help people to become the best each person and the Team has ever been before.

And you do not inhibit self-organization yourself. (Actually, we all want to control things, and while some control is good, most of us want to control too much.  At least, that is a common problem, even among the well-intentioned.)  You do not 'tell' people to do things, although you might ask 'could you help with X?'  But, gosh darn it, do not act like a 'command-and-control' style project manager. "I have a list of things for all of you to do, and I will be checking the list daily to see what you got done."  Not that. Not even anything close to that.

Still, you might need to explain why they need to have detailed tasks and answer the questions in the Daily Scrum.  And why that is useful for them.  Paradoxically to some, they do need to self-manage themselves rather closely.

Third, more impediments are removed, and the Team is gaining velocity.

You have to aggressively attack the most important impediment. And when that one is 'fixed,' attack the new most important impediment aggressively. So that the velocity of the team easily doubles in no more than 6 months. (OK, some of you are in organizations that really are hard to change, so you will work hard to double in 1 year.)

And then keep on improving!

Fourth, more business value.

What?  That is the SM's responsibility?  Yes, as we have already hinted.  But let us say more.

The SM should be helping the Team get better in every way. The Team of course includes the Product Owner, so the SM is helping the PO get better.

And the goal of the Team, of course, is to maximize the Business Value (in whatever way they define that) from the Team to the Customers. (There is no maximum.)  And release more quickly and frequently.

Obviously, if the velocity increases the BV will increase.  But we really mean more than that.  The SM should be helping the PO learn to do all those things a PO should do to help the Team maximize the BV.  Examples include: clearer requirements, focus on one release at a time, a clear Minimum (minimum!) Market Feature Set (aka Minimum Viable Product), slicing the stories smaller and re-Pareto-izing them, maximizing the feedback to try to improve the odds the customer will really be excited when they get it, maximizing the feedback (see Lean Start-Up) after the release and then 'adjusting' (pivoting, as appropriate), etc, etc.

I do not mean to suggest that the SM does the PO's job. I mean 'only' that the SM helps the PO become a better PO.  And not only the PO.  The ScrumMaster helps all the people (on what we often call 'the business side') to work better with each other so that the BV is maximized more.  And delivered more frequently (which also helps maximize it).

So, at least as general goals, the SM wants to make the Team the best possible team ever.

More specifically, that means:
<ul>
    <li>More fun</li>
    <li>More self-organization</li>
    <li>More velocity</li>
    <li>More business value</li>
</ul>
It is, of course, more blessed to give than to receive, so actually they will start to feel that delivering more business value faster is more fun.

It can be said that 'removing impediments' is the way to make those 4 things happen. Put another way, anything that is holding those things back is an impediment for the Team.  Fix it!

Have we fully answered the question?  No.

&nbsp;

Question: Explaining Impediments to the Sprint Goal that happen

I received this Email with a Question:

Hi Joe,
I wanted to follow up and let you know how much I enjoyed the agile class and how much I've enjoyed implementing it at my office.

The team has really seen the improvement with their own eyes, and they are getting more and more brought in each day. We are already on our second release plan since the class. Our start velocity with 7 developers the first sprint was only 18, but by the last sprint we were getting close to 50 points. This current release plant we are averaging right under 60 points per sprint. It's been amazing the turnaround in such a short time.

Now to my question, how do you relate loss of staff time to your stakeholders, due to sickness? For example, we had a user story planned for a sprint, but the staff person who needed to be involved in it's design has been sick. I've let the stakeholders know that it may not be finished in the sprint due to illness, but beyond that, I'm not sure what else I can do.

Just reaching out for advice, thanks Joe!  Regards, Tony [...]

ANSWER:

In the title, I use the words '...that happen...'  By this I mean, an impediment that was unexpected that arises during the sprint.  If it were a different situation, I might give a different answer.

First, we want the velocity to be meaningful.  Remind them there is no value in fudging the numbers.  It is good and useful to be honest.  If you all do things 'according to the book' it is actually hard to fudge the numbers.  But not everyone explains enough so that it can be seen that they are (or are not) playing 'by the book.'

Second: Great!  Very good improvement.

Third: These things happen.  People get sick.  And, of course, to some degree every decent human being understands.

You say that 'you let the stakeholders know.'  To me, depending on exactly how you did it, it is a potential weak point, or area for improvement.  For example, if you 'just' sent an email, and they never read emails, then this is not very good.

Here's what I suggest.  The PO should sit down with the business stakeholder (and any key managers) and discuss the project.  Help them understand that we expect to make progress every sprint, but that  the long-term success is key, not that we 'hit or exceed' each and every sprint.  Stuff will happen, and we will have ups and downs.

You want to keep them informed.  When and how should I inform you about impediments in the sprint that mean (or might mean) that a given story may not get done (done, done) in that Sprint?

There are lots of situations.  Sometimes they will say: 'Don't bother to tell us until the Sprint Review.'  They might say 'text me immediately.'  Or other variations.

Discuss the business purpose or impact of informing them, or inform them sooner or later.  For example, if you are lacking something and those people might get that 'lack' fixed (maybe knowledge, maybe a screw, whatever), then informing them quickly could be very helpful.  But, if they cannot do anything with the information, why bother?  So, discuss this.

Discuss also how much detail they need on some sample impediments like this that have happened.  Sometimes they want to know, but without much detail.  Sometimes they may want more detail, and having the detail would actually help.

Let's say you agree to inform them by email asap, with a special subject line (so it sticks out in the inbox).  And usually in not more than 30 words.

Now, also talk about how these impediments will be discussed in the Sprint Review.

Probably agree that the PO should not assume that the business stakeholders or managers read the emails.  Likely they did not read them, or forgot about them.  So, to some degree (ask how much), these impediments need to be mentioned and (lightly?) discussed in the Sprint Review.

As you see, I am proposing a working (living, changing) collaborative relationship between the Team (PO) and the business stakeholders (and/or managers).

The key goal is to make that relationship more effective.  This 'inform about impediments' issue is just one discussion point in that relationship.

Put another way, the answer to your question partly depends on where that relationship is and can be about now.

One more thing.  The Team (the whole Scrum Team) is always expected to work together and overcome impediments (in priority order) where possible.  So, at some point you might need a discussion of other impediments, of what the Team (SM?? Others?) did about them, etc.  After some trust is developed, maybe all of this does not need to be explained every time.  But the key idea is: you can't just say 'I have an impediment, sorry!'  The Team has to always be trying to overcome the top impediments.

In this case, what might that mean?  Well, maybe someone in the Team could help out with the design.  Or the Team borrows a 'chicken' or another chicken to help out with the design.  Or at least went to a manager and asked for advice on this one.  Depending on the situation, this might need to be discussed.  At least there needs to be a discussion of 'ok, but what happens now?  What do you recommend?  Is he well now?  Or 'next man up!'  Or what?'

Long enough answer for today.

Please tell me if you want to give more information and/or ask it a different way.

BTW, I am fairly confident that you (Tony) did the right things.  In part my answer was for others..., others less experienced and successful with Scrum, you might reach the wrong conclusions if I had not explained more.

Multitasking

I think the key goal of Scrum is to help the Team maximize the business value from the Team to the Customers.

But another, of several subsidiary goals, is to enable the Team to focus.

Focus is more or less the opposite of multitasking.

Perhaps even more to the point, multitasking is one of the great destroyers of human productivity. That is, your own productivity, to make it personal.

Please see this webpage for further discussion and a short video.

Enjoy.  

Wide-band delphi estimation for Business Value - 2

See Part 1. ***

Step by step

Let me walk through how I do it.

1. We have a product backlog.  Usually user stories.
2. We identify the right people to be the business value experts. We recommend that they participated in developing the PB.  Typically 5 people.  I call them the business stakeholders (maybe not what your company means by that word...just the key people to do this and participate in the Sprint Review) and the Product Owner.  The 5 best experts. (Sometimes you have 4 people or 6 people.)
3. We discuss BV drivers.  To make the concept of 'business value' more concrete in this specific situation.
4. We choose the highest BV card.  We give it 100 BVPs (BV points).  It becomes the reference story for BV.
5. We select cards randomly.  And compare them to the reference story.  The experts vote on BV using the Fibonacci cards.  I recommend the full true Fibonacci series up to 144.  If you want to add some cards at the high end (some, not many), I think it will not hurt.
6. They discuss and then 'secretly' vote. 1-2-3 show.  Everyone shows his poker card.  If the cards are all with 3 Fibonacci numbers of each other (eg, 21-34-55), then sum the cards and average to the nearest integer.
7. If they are not close, then discuss (especially the highest and lowest voters), enough so that the 5 voters learn something.  Then re-vote.
8. On average, allow about 1 minute per card.  Maybe slightly more. They will discuss the first few cards more slowly than that, and the last half of the story cards will go more quickly, on average.  Do not let them get take more then 75 minutes for 50 use stories.  Go fairly quickly.
9. When you are done as a team, then arrange the cards of similar BVPs.  And you ask the experts...do you see any cards that now look 'out of kilter?'  Often they will identify a few user stories to be re-voted. And then they do that.

That's the basics.  Pretty simple.

Results

I have never seen any set of experts vote all the user stories or even most of the user stories as 100 BVP (on every one).  In fact, they always use a roughly even distribution from 100 to about 5 or maybe 2 BVPs, across the set of stories.  This is quite remarkable, when you think of what we used to do.

Comments

I recommend that the BV experts think mainly in terms of 'wow factor.'  That is, BV is what will make someone (eg, the customers) say 'wow.'  Or say wow more loudly.  the louder the wow, the higher the number.  The experts often talk about dependencies (of one type or another) and want to deduce that the one card on which many other stories are dependent -- that card must therefore have the highest BV.  I discourage that way of thinking.  I recommend handling dependency issues a different way. If they need a decision about what a story is (or is not), the PO is the final decision-maker.  We hope, of course, that the PO uses common sense. We recommend you use a ScrumMaster (or someone like that) to facilitate the meeting.  Keep them at a good pace.  Let the quiet ones talk more, get the talkative ones a bit less verbose. I like to let the implementers listen.  They learn things. And I like to let the implementers, occasionally, ask questions.  "Why is that story so important?"  "I thought that story would be more important...can you explain?"  And the experts take a minute or two to answer.  But, we cannot distract the experts too much. The voting is very interesting to watch. Bring popcorn.  You could even sell tickets.  The experts will disagree with each other, and educate each other, and learn things about business value.  And they will complain that it is hard to estimate the future.  The implementers usually find it amusing when they say that, because these are the same 'jerks' who 2 weeks ago 'beat up' the implementers for not being able to estimate effort more accurately.  They start to respect each other more. The implementers learn a lot about business value, as they watch. This changes their motivation and it will change their behavior when they build the product. Are the experts really expert?  In my opinion, we can say that they are the best people we can find to make these guesses.  But they are really guessing what the customers will want when we deliver the product and for the 2-5 years after that.  No one is really an expert about the future. Still, business has always been risky.  About all real business questions, we get the best people to take their best guesses, and we hope that will give us more success than our competition.

Executive Action Team

Jeff Sutherland has defined an Executive Action Team.  This is similar to the Management Scrum idea that I discussed. You will also notice that Ken Schwaber and Mike Cohn have described roughly similar ideas to what Jeff is describing.  (I will look up later the names they gave to those teams.) Jeff Sutherland's idea is similar to what I (and some others) call an IRT.  An Impediment Removal Team.  That is, a higher level team that looks at all the impediments and works on the 'best' ones.  Best is either highest (best bang for the buck?) or the ones that IRT are best at fixing. For Jeff's discussion of the Executive Action Team, see the video and the slides here.  It is part 3 of his Scrum at Scale series.  You will notice that in addition to working on 'impediments', it implies that they work on 'transition issues' (as they are aka as a 'transition team'). Enjoy!  

Management Scrum Team - Part 4

This is the 4th of 4 parts.  See here for the 1st part. Links to all 4 parts are there. Or search to the right. *** Retrospective.  Again, telling the truth here can be difficult. The whole MST comes to this meeting at the end of every Sprint. For a 2 week Sprint, maybe 2 hours. The purpose: To get better. What do we do in the meeting? We discuss the good and the bad.  Some of the bad gets added to the impediment list (a list of things we want to fix or mitigate to make things work better here). I suggest we give the SM (the ScrumMaster for the team) a 10 minute time-box to explain what he has done this past 2 weeks. Which impediments he has worked on, what solutions he has gotten implemented, how much the velocity has increased because of his efforts (or efforts he drove). People say things like “wow, I guess he did something useful!” This is kind of like a ‘demo’ for the SM. We identify the biggest impediment for the MST itself.  As of NOW. We do this quickly. And we spend most of the time working together to fix the Top Impediment for the Team. As examples, the MST might:

1. devise a solution together
2. plan the execution of the solution
3. build a business case (eg, to justify spending some money). Is it clear now that the benefits are much higher than the costs? Etc.

The business case might go to the CEO or even the Board for a decision.  Often the business case simply enables the Team to work through the information and convince themselves of the best solution.  Often, also, the MST starts a business case, and someone else (the SM?) refines it, improves it, fleshes it out, and completes it later. Who 'fixes' the impediments?  Well, it depends.  The SM, the MS Team, or people outside the MS Team.  Depends on several factors. The key thing is that the Retrospective enables them to get better each Sprint. Better can be measured many ways, but typically as higher velocity for the Team. This is more effective, in a bigger way, than the SM working in isolation. And more useful than just identifying the (usually smaller) day-to-day impediments in the Daily Scrum meetings. *** How much difference could an MST make? Hard to say.  We do not have enough experience in enough situations to know well. My experience suggests that in about 3 sprints, the MST is working at 'normal' level.  Maybe 4 sprints.  Typically.  But the problem is you had no 'before' metrics on the 'velocity' of the MST.  So, there is nothing to compare the new Scrum velocity to. The good news is you now have a metric for the productivity of the MS Team.  They may not estimate the 'story points' well yet.  But they are learning. Usually you find that 'the velocity is lower than we wanted'.  Is that really a surprise?  (CEO, you did know that already! Right?) Now you have an approach to getting better as a Team.  And for avoiding your weaknesses (of individuals) and for drawing on your strengths (as a Team). The difference can be huge.  If people engage, if you allow yourselves to see the truth, if you have the courage to take reasonable actions. *** One key issue.  I think it is typical to find that the people you have in the 'management team' are not the right balance of people for a good MST.  The MST must be balanced against the vision and the items in the PB.  Often you see an imbalance. Thus, you often need to move some of these people outside the MST, and probably add some other 'skill-sets' to the MST (new people). This is a feature, not a bug.  Meaning: seeing what kinds of people you really need in the MST is a big help. *** Those are my simplified and initial ideas on an MST. I hope my humor about the problems of life and the problems we often have being managers was taken the right way. Manager work is hard, and being a manager is hard.  I do have sympathy, despite my sometimes sarcastic tone. One could cry about the situation, cry at the measureless waste in the lives of the managers and the people they manage, and the impact on the customers.  Or one could laugh. I choose to laugh. This problem of measureless waste and 'not good enough yet' is true for all of us.  And it is sad and we can be sarcastic.  Just to be sarcastic is not good enough.  We must act to improve things, as best we know how. In this vein, one must have sympathy for managers.  In my opinion, they are usually not trained well to be managers. In fact, they are generally mis-trained (trained wrongly).  And the Peter Principle (they rise to their level of incompetence) is too true.  And their 'boss' is too...hmmm....lacks the courage to fix it when the Peter Principle occurs. These are good people, some of our best usually, but badly trained and often badly positioned.  To the degree we can fix this (and I think we can, at least some) it can make for a big improvement. *** Please give me and us your feedback and suggestions. That covers the main things in Scrum that the MST must do. It gives a quick overview. It definitely does not answer every question you will have. Folks: Careful doing this at home. It may look easy on paper, but you will want to get all the help you can to learn how to do it semi-professionally as soon as possible. Get training, get coaching, at least. Now, please send me your reactions and comments. Joe at jhlittle@kittyhawkconsulting.com      

Management Scrum Team - Part 3

This is the 3rd of 4 parts. Part 1 is here.

***

Now we come to a harder meeting.  The Sprint Review.  It is hard because no one in this Team is used to showing anything completed in 2 weeks.

They are used to showing Powerpoints.  Vaporware. “Thoughts.” With knowledge workers or managers, when they show this stuff, can you tell if you have made any progress?  Of course they say they have done excellent work.  Meaningless. How do you know?  You don’t.  Sometimes they have actually made tons of progress.  Other times, the progress is negative.  Very hard to know when it is progress (they always say it is).

Ok, then, we have to change things then.  We need to have a better fix on whether we have made progress or not.  And, if progress, how much.

Sprint Review.  Alright then!

First, the MST has to do a general 'review' of things over this Sprint.  The CEO does this quickly.  An example:

• • We committed to the following 8 stories in the Sprint Planning Meeting. (He lists them.)
• • We completed 7 of them.  We did not complete the last  one.  We started an additional story, but did not complete it.
• • Our Velocity for the Sprint was 18 SPs (story points, or units of work).
• • That gives us an average velocity of 20 over the last 3 sprints.  With that velocity, we expect to deliver X on Y date and A on B date.  Just a bit later than what we said 2 weeks ago.

Note that the PO is summarizing for the Team. And the business stakeholders are there.

Necessary talking and summary.  Blah, blah, blah.  Keep this part short!  Very short.  This is altogether too much like the usual BS song and dance stuff they have been trained to waste time with….and they have done it for 5+ years.  People have been promoted for no reason except that they are good at this Powerpoint BS.   I could express this more kindly, but I won’t.  As a shareholder of many companies, I am disgusted at the long wasteful meetings that this stuff is usually done in.  Any questions?

But I do agree, we need a short, very short, summary by the Product Owner (CEO).  10 minutes?  Something like that.  Short!!

The other people can talk some at this point. Not much. These people are all good talkers.  The BS meters are running high at this point. Watch out.

Now, they have to show the real stuff. Demo.

Quickly, they have to demo the working stories.  Whoa!  (Neither demo nor 'working' imply or mean that the product must be released every sprint. Depends on many factors.  A typical situation is that it takes multiple sprints for a product to be built enough to release to customers, whether internal or external.)

We need good independent 'business stakeholders' (BSHs) to be there to give good, independent feedback on what has been accomplished.  We need to know if we have made real progress.  Or, have we just been 'working hard' and accomplished nothing?!  Hence, independent feedback.  Feedback that represents the 'customer' for each story.  Some stories build 'product' for external customers and some stories build 'product' for internal customers. And 'external customers' much too often these days means 'the regulators'.

We need people at the demo who can quickly give us feedback that these different customers will like (or not like) what the MST has finished this sprint. And I call these people (BSHs).  Note: your firm may call them lots of things.  Examples: customers, managers, shareholders, consultants, Board members, dept heads, SMEs, gurus, wise old heads, customer relationship managers, product managers, etc, etc, etc.

Also, often the word 'business stakeholder' already has a meaning in your firm different than my meaning.  Watch out for that.  Picking the right BSHs (as I defined them) is hard. And important.

And we need the BSHs to give complete, detailed, honest feedback now.  So, you will not ever get perfect BSHs, but do the best you can.  "The bad news does not get better with age."

For the MST people, receiving honest feedback can be tough.  They have often not heard that in a good while. All kinds of 'acting out' can happen. Some want to 'shoot the messenger'.  Or blame Scrum.

This can be tough on the PO (CEO) in at least 3 ways: (a) he or she is getting way more negative feedback than in the past, (b) the direct reports are complaining loudly about the negative feedback they are getting, and (c) the CEO can see that the 'team' culture that had been 'talked about' for ages does not really exist in the way they had hoped.  This can be tough to swallow.

If there is not much negative feedback, there are two possible reasons. (a) Everyone is Steve Jobs (or pick another business icon).  Unlikely. (b) People are lying or don't know how to give feedback. Often because we picked patsies as the BSHs (and deep-down knew they would give only 'sweet' feedback).

Get good and honest BSHs. Insist on the truth.  Remind people that the bad news is the good news.  Because "the bad news doesn't get better with age."  Meaning: now that we know it, we're gonna fix it now, before it becomes more expensive to fix.

Be patient.  "Little things are big."  (Yogi Berra.)  And step by step they can all accept that they are imperfect, and improve. Be firm. Be kind. Be honest. Be patient.

Well, to be a bit more honest, at some point the CEO is very likely to see that someone 'needs a promotion to another company.'

The CEO again needs to be patient. These people are good people in various ways.  And the company's culture (or someone's culture) has mis-trained them for many years now.  So, it will take more than 2 sprints for all the dysfunctions to come out and for all the re-training to occur.

So, give people a reasonable chance to adjust.  But at some point, one person is likely to be 'at the far end of the scale' and you have to give them a 'promotion to another company'.  (Often we say "It's not you; it's me."  I say this only partly to add a bit of levity.)  And it is tough, but it is also the best thing for that person at that point.

***

Part 4 is next.  Feedback is always welcome.

Management Scrum Team - Part 2

Part 2.  (See here for Part 1.)

Now, the work of the sprint needs to be defined in small 'stories'.  To me, for two weeks, 8 stories for a team of 7 is about small enough.

Team. Did I mention that this is and should be a cross-functional and multi-functional team?  The 'people' within the MS Team are all about the Team accomplishing the Team goal(s)!  So, we are expecting the people in (parts of) the MST to help each other.  We expect multiple people (parts) to typically work on each story.

Done. We also expect the stories in the sprint (the work of the MST) to be 'completed' by the end of the Sprint.  To be 'working product' that can at least be 'inspected' by someone independent (eg, some independent business stakeholders).  The BSHs should look at it and say 'this is good; customers are really gonna want this stuff'.  Or, at least, this is the feedback we want at the end of the sprint, on each and every story.  The truth is we often learn that the BSHs are not happy with a couple of stories (that had seemed to be ‘working’). And, the bad news does not get worse with age. (Each failure is an opportunity to learn.)

So, each story must be demo-ed at the end of the Sprint.

Writing small stories that can be demo-ed is a new art for the MST people.  Well, they can write stories that will never be demoed (Sorry! I mean stories that can be demoed after they have left the company.... Sorry!  I meant stories that can be demoed in 5 years).  [Too much sarcasm? Sorry.]  But, seriously, writing stories that can be completed and demoed in 2 weeks is hard for them at first, because they have never done it before.  If you have never done something, in fact it usually feels impossible!  It is not impossible at all, but they probably will feel like it is.  These are tough guys to coach.

Remember that 'completed' requires that you have a good 'definition of done' and that always includes some 'verification and validation' by a competent and independent V&V person.   With software, we call this well-tested by a good QA person. This also is trouble for the MST people, since they have never done this before, usually. Or they have never made transparent what they do or don’t do for V&V.

Daily Scrums.  Daily.  Any questions?  I mean, seriously, can there be any question?

A 15 minute stand-up where each person answers the 3 questions.

You will hear some lame excuses about why they can’t attend or did not attend.  'I have another meeting at that time.'  'A customer called.'  'The President of the US wants to see me in 5 minutes.'  You can't make this stuff up.  Honestly, some of these 'distractions' are important.  But the root cause: They do not think the Team is important and they have forgotten how to work as a Team.  They do not see how the Team is going to help their career.

Jon Defriese thinks this is because the Leader, (in our case, the CEO) has not established the right culture.  Often the Leader has not dealt well enough with these issues in his or her own head.

In any case: Daily Scrum.  Daily.  Answering the 3 questions.  Slightly rephrased.

• • What did I (or my home team) do yesterday that helped the MS Team meet the Sprint Goal?
• • What will I (or my home team) do today to help the MS Team meet the Sprint Goal?
• • Do I (or my home team) see any impediment(s) that prevents me or the home team from meeting the Sprint Goal (of the MS Team)?

‘No impediments’ is almost never a reasonable answer.  Unless the people are perfect and the situation around them is also perfect. Rarely does this happen. Anything that slows them down from a perfect and fast delivery (of any story) of the highest value is an impediment.

Also, they need to tell each other the truth at the Daily Scrums.  (Stop that laughing! We are serious here.)  Also, not make 'political' statements.  And then, help each other.

Seriously, it can be tough to coach this team at first.  Often they have totally forgotten how to work together with any team, and especially each other.  Some of you have a better culture; so if you have that case, be mindful when a new person joins the MST, often he or she comes from a company with a very different culture.  Give that person some time and some coaching to adjust.

***

Part 3 is next.

Management Scrum Team - Part 1

This is an important idea that more and more people are talking about.

One reason: Managers need to learn about Scrum.  They can take a course, but they also need ‘reality’, that is, being in a real Scrum Team.  (Real does not have to mean a software dev team.)

Another important reason: Managers can be more effective in a multi-functional Scrum team. (Often.) We need to help managers be more effective.

Now, the purpose of this post is to learn.  Start to define this idea; kick it around, and see how it might be improved or be more useful.  This idea may not be totally figured out.  In fact, my main purpose is for others who have tried this idea or something similar, to give me (and you) feedback on their experiences.

Now, knowing our situation better, I hope you will provide feedback.

***

What do I mean by a management scrum team?

A stable team of managers working toward one vision.  And working on ‘one set of work’ and ‘one product’ (even if broadly defined).

Below I will make my comments specific and practical, in case you want to try them.  Ideas expressed in a practical way are less likely, to be misunderstood.  And I will explain some of the underlying principles.

Reminder: Other people have a similar but different idea. Who is right? (Too early to tell.)  USE WITH CAUTION.

Also, I am making a number of assumptions, and have not expressed all of them.  Use caution. And, I am not suggesting the ideas below will work, or should work, in all situations.

***

A Team. Again, we want to call it a Management Scrum Team or MST.

Get a bunch of managers at almost any reasonable level.  They of course need to be similar in some way.  And have a reason to work together, a common purpose or goal.

We need about 7 people.  A team too large does not work well, and a team too small is ineffective usually.

Next, form them into a real, stable Scrum Team.

***

Now, distinguish 'leaders' from 'managers'.   Sadly, this distinction needs to be a long conversation.  For now, a leader needs leadership qualities, including setting a compelling vision for the people they work with, be decisive, and have the ability to inspire.  In the managing area, she is not 'command-and-control' at least, and hopefully well-skilled at being a 'servant leader'.  (The short version of a long topic.)

Some people think 'management' is a bad term.  I like Peter Drucker, and I think the word management is abused and needs to be clarified, but can be useful.  As well as manager.  I agree that when an organization tends to say 'management' and seldom 'leadership', it is a smell...it causes me concern.

***

OK. Maybe we have the CEO and 6 key managers (leaders, gurus, coaches, call-them-what-you-will).

The next thing is to think of them as a Scrum Team. Probably each person is representing other ‘doers’ who are not in this Team.  So, the Team is (mostly) reporting on the work done by others. To me the key idea now is: the people in the Team are not doing 'real work' (as they always say) but rather are reporting back what their 'home' team has done. (The home team may or may not be a Scrum Team.)  It is probably OK if one or two ‘real work’ people are in the MST directly.  That is, they are doing real work themselves.

What's next?

Notice that I have not (yet) used the word scaling. Partly because, few people agree on what the word means.

And because, I am not assuming that the org has or has not already done 'team-level scrum', which might be called 'scrum with real people'.  To me, we can start doing scrum first with the MST.

Next?

Back to the composition of the MST.  Well, obviously one person is a PO (product owner).  Maybe that is the CEO.  One is a SM (ScrumMaster, the key impediment removal driver for the MST itself).  The rest are the 'doers' (well, they represent the doers in each home team).

We have a Product Backlog.  It is prioritized mainly by business value.

It includes, at this level, all the most important work for the firm.  It might include any type of work (or it likely represents a wide variety of needs).   The composition depends on many factors, including the nature of the firm's business.

It includes 'real work', innovation (if you think of that as different than real work), impediments from the Scrum Teams or the departments/divisions, agile adoption issues, cultural change, etc.  Whatever work needs to be done.  Maybe some of the work is easy and some of the work is hard.  Maybe some work is 'always there' or recurring (in some sense) and some work is 'temporary'.

Again, the work is prioritized mainly by business value (or, more accurately, bang for the buck, as best understood).  Other factors intrude too.

Perhaps I need to say again.... the people in the MST maybe do not do the work with their own bare hands. They may 'represent' other people or teams that are actually doing the work.  In fact, that is much more likely the case.

Sprints.  The MST has sprints.  The shorter the sprint, the better, usually.  I am thinking 2 week sprints.

With managers, you know, they don't need any feedback, so maybe the sprints are 3 months long.  Oh, sorry, I was being sarcastic.  With manager work, getting good feedback and fast feedback is even more necessary than with other work.  "The bad news does not get better with age."  So, seriously, try to get the sprints to be 2 weeks, or maybe a month.

Agile Release Planning.  This MST team must do something like what I call ‘agile release planning’ periodically.  Maybe every 3 months, looking forward for the next 6-12 months.  It is complicated, because this team, at a practical level, is often managing multiple 'releases' of different products.  And they are managing BAU as well (business as usual), which is often a zillion widgets or tickets of CSRs or whatever.  More generically, they define goals and metrics to achieve in some relatively short time frame (in software dev, we call this a release or two or six over, say, 6 months).   Then they define the basic work items (stories or smallish epics) to 'get there'; delivered.

***

This has to be some combination of top down and bottom up.  That is, one would expect 'new ideas' to have 'gone to the top' (no matter where the new idea originated), to be considered and prioritized.  And one would expect lots of basic 'necessary' and continuing work to have been identified (or re-estimated) at a lower level and submitted to the top for 'overall' consideration.  The CEO often has little choice on the 'necessary' or 'previously approved' work, but at least in terms of allocating people and resources, the 'management team' needs to put it in the picture.

Obviously, this is adaptive planning.  Enough said for now.

Sprint Planning. The MST needs to set a Sprint Goal.  At least a somewhat coherent Sprint Goal.  As Yogi Berra said: "You have to be very careful if you don't know where you're going, because you might not get there."  In other words, a typical failing is to 'focus on everything', which is the same as saying 'focus on nothing'.  Which means that nothing gets done.

This is a classic problem.  It affects individuals.  It affects Scrum Teams.  And it is probably even harder for the MST.  So, get some focus each sprint.  "Try to do less, and you will accomplish more."  In agile we  have a similar phrase: "Stop starting, and start finishing."  Or, put fewer things in motion.  Or minimize WIP.  Say it whichever way you want...Do it!

***

End of Part 1.  Three more 'parts' to follow.

Part 1, Part 2, Part 3, Part 4

Wideband Delphi estimation

This has been a commonplace idea for many people for decades. And used in Agile for estimating effort for at least one decade. And only talked about in Agile for estimating business value for a few years. See Wikipedia's article here. See James Grenning's article here.

Agile Alliance website - Agile 101

The new Agile Alliance website has a new Agile 101 section.  Within that section is a "Practices Timeline." The timeline is pretty good, and will almost surely introduce you to some key ideas.  Some that you know (but maybe not well enough) and probably even some you don't know (but should).

Scrum at Scale - 4 parts

Jeff Sutherland has recently done a great job in describing his ideas on scaling.

Here are a couple of things I think are key:

1. Scale down.  That is, it is complex to get lots of people involved in one problem or effort.  Simplify.

2. Use patterns.

3. There are alternatives.  While there are some common patterns, and they can work, do not assume every pattern will fit your situation.  Be judicious and experimental.  Expect experiments may not work out well (for a variety of reasons, including ineffective execution).

Here are the modules.  They include video and slides.  See both.

https://www.scruminc.com/scrum-scale-part-1/

https://www.scruminc.com/scrum-at-scale-part-2/

https://www.scruminc.com/scrum-scale-part-3/

https://www.scruminc.com/scrum_at_scale_part_4/