Saturday, June 18, 2016

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.  

Friday, June 10, 2016

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!    

Monday, May 30, 2016

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.


Saturday, May 21, 2016

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.  

Sunday, May 15, 2016

Scrum 101

Here is the slide deck I used in the talk with the Agile Halifax group. Scrum101.key You can see slides from other talks I have had here. Enjoy!    

Monday, May 2, 2016

Scrum 201 Course - Why?

Why the 'Scrum 201' course?


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.


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.


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.    

Sunday, May 1, 2016

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.

Friday, April 29, 2016

Getting Started with Scrum

Let's talk about the basic standard patterns in getting started with Scrum. (We have talked about these ideas before, and so have many many coaches and advisors.)
  • Start a pilot team
This also means pull together a team with the best possible criteria for success. These criteria are worth reviewing in more detail later. But let's at least mention now that it ought to be a full time team (every member full time), about 7 usually, and dedicated to the full success of only one mission. And the environment around the team should be set up for success (at least as compared to set up for failure). Start only one or two teams at a time. The organization needs to support them. The people (eg, you) and the org can only handle so much change at one time. Once you have the one or two teams going well, maybe add a third.
  • Team training
We recommend that the full team be given training together. And that should include key people around the team. They all see each other buying-in to the lean-agile-scrum ideas, or maybe not fully. But they can all see. This makes it much easier for the beginning ScrumMaster, for example.
  • Team coach
Everyone (AFAIK) agrees that a team coach is essential. This needs to be a senior agile person, an experienced coach. That person is coaching the whole team and the organization immediately around the team. The person is teaching them Scrum (what they do wrong compared to what they learned in the course), advising, coaching about details, answering all their 'how do I do it exactly?' questions, etc. Both in the team and for people outside the team. There is not much agreement in the Scrum community on how much the coach is there. Some say, for example, full time for one team for 2 months (40 days). Others say 3 days or 2 days at a time for 4 sprints (let's call that 9 days). But, that beginning teams need a coach is understood. Should this coach be internal or external? At first, no one internal is usually ready to be a coach. And at first you need an authority, and an internal person usually does not carry that authority. Later, you need both internal and external coaches. The internal ones help make 'realistic' choices and address 'realistic' problems. The external people keep the internal people 'honest', and keep them from compromising too much. The external people tend to pursue change more aggressively. Always a good thing as long as people are willing to learn through mistakes. Enough for a start?  

Saturday, April 16, 2016

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.    

Sunday, April 3, 2016

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.
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.
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.
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.
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.
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="">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.


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


Thursday, March 31, 2016

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.  

List of Courses and Workshops V12

Some of you may have seen our prior list of courses and workshops. Scrum 201 was added. We did this one years ago with Jeff Sutherland, and the need for it continues to grow. Many of these courses and workshops are available publicly, or could be done publicly about anywhere if there is some interest (5 people would be a good start and maybe an offer to help get us to 10....typical numbers). Or they can all be done in-house or privately. Please do not hesitate to contact us to discuss. will go to both Joe and Cassandra. Or call. Here is the list: Course and Workshop Offerings Ver12

Tuesday, March 8, 2016

2014 State of Agile Survey

Here are the survey results from Version One on the state of agile.  A pretty good job, I think. Many interesting observations in the survey. Let me highlight one. Under "Barriers to Further Agile Adoption", the top 3 answers were:
  • 44% ability to change organizational culture
  • 35% not enough personnel with the necessary agile experience
  • 34% general organizational resistance to change
Very similar things, I think. Certainly a pattern that has held fairly constant for years now.  Probably a pattern very common to all similar changes.

Saturday, March 5, 2016

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.'

Thursday, February 25, 2016

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:
    <li>More fun</li>
    <li>More self-organization</li>
    <li>More velocity</li>
    <li>More business value</li>
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.


Sunday, February 21, 2016

Scrum makes work a game.

You know, of course, that Scrum is named for the Scrum formation in rugby.

More generally, Takeuchi and Nonaka were inspired by the 'rugby' they saw in several great companies and how they did new product innovation.  And Sutherland and Schwaber read that article in HBR: The New New Product Development Game. And that was a key input to creating Scrum.

Here's where we are I think: "Life is hard, life is confusing, and I can never tell if I am making progress. It starts to be no fun, no real people to talk to usefully, no way to see if we are making progress. I am always late and it seem never-ending!"

If some of your colleagues feel that way sometimes, you can imagine that that is: Not Good.

So, Scrum changes it to a 'game.'  It is still real, so not a game in a sense that it is divorced from real life.  But it is, as they say, gamified.

We have a 2 week sprint. We have some defined roles. We put a person on a Team.  We ask the Team (not one person) to be successful.  We suggest that they self-organize and work together (collaborate).

And we allow they to make first downs (as in America football). They get feedback quickly (as in any game)...are they making progress.

Are the measures of progress that we have in Scrum perfect?  Well, actually I think they are very good, but they are not perfect.  But something that is fairly frequent feedback and fairly accurate is far far better than 'nothing.'  Or a couple of 'at-a-boys' that were said half-heartedly.

The key thing is that we have made things 'fun' in a way.  And that feedback is useful for course correction, but perhaps more useful as motivation.

  • we get positive feedback
  • we see that other people care
  • we can feel proud of ourselves with small wins
  • we work together, and it no longer feels lonely
  • usually they team starts laughing during the day.  It is fun in that way too.
Let me remind you how games are seductive.  As any behaviorist psychology major can tell you, they give intermittent (positive) feedback.  To be honest, not always positive feedback.  But the positive feedback in intermittent.

And this, according to the research, is key to making the game 'fun.' Now, when they are playing the game, they do not always have a smile on their faces, but still they are engaged, and typically more focused, more 'giving their all' than they usually do working 'in their cube' (as we often see in waterfall).

As with any good game, we need to be able to see frequently, transparently, easily if we are making progress or not.

The managers need to talk about work as a game.  A game we wish to win.

Tuesday, February 16, 2016

Wide-Band Delphi Estimation for Business Value - 3

This is the third in a series of three.  See part 1 and part 2. ***

How can we use the BV points

We could organize the Product backlog strictly by BVPs, at least initially.

In fact, I recommended this, to see patterns or to make any mistakes obvious.

But I do not recommend doing the work in the order of the BVPs, the story with the most BVPs first.  This is much too simplistic.

The key thing we are missing is cost.  For centuries now, man has talked about the trade-off between costs and benefits.  And in business we have the concept of return on investment.  You invest $1000 (the cost) and get $2000 back (the benefit).

Can we use that concept here?  Yes!

For each story, we can calculate an R factor by dividing the BVPs by the SPs.  This gives us a rough ROI for each story. We could call it CBA (cost benefit analysis, or bang for the buck).

We think this is useful.

By no means does the R factor completely determine the order of the Product Backlog, but one can readily see that following the R Factor could help us maximize the business value per release, other things equal. (Of course, other things are not always equal, but we will not try to address that here, except to say that the Product Owner or others must re-order the Product Backlog some to account for the other things.)

What is the value of a BV Point

Sooner or later someone will ask: What is a BV Point worth?

At first, it is relative, strictly relative.  That is Story X is 50 BVPs, which means it has half the value of the reference story (which has 100 BVPs).

But let's imagine a very simple situation and see what it shows us.

Imagine a product backlog.

Imagine it has a total of 1,000 BVPs across all the stories.

Imagine that we know that the total Product Backlog is worth $2,ooo,ooo.

In that case, we can calculate that each BVP on average is worth $2,000.

You can't cash in your Story cards at the bank for money (based on the BVPs on each one).  You must release and there are MVP or MMFS issues as well, but one can at least feel (fairly accurately) that the BVPs are not just fantasy, but actually a foretelling of a future reality.  Well, if the customer still wants it when we deliver, and if we had good BV estimators.  

Objectivity and Visibility

In our opinion, whatever business value is, it is ultimately in the mind of the customer, and in the future.

So, to us as business people trying to solve a business problem (help people and also not go bankrupt), this seems altogether too subjective.

The BVPs start to make it a more tangible thing.  And this helps.

Whatever number we decide ob is then no longer a 'feeling' inside us (or one of us), but rather a number 'out there' on the story card.

This helps.

It helps in many ways, but let's give one example.

In former days, we would ask two experts for Story X: Is it high, medium or low?  And of course they would both typically say high.  Now, we ask the two experts to vote with cards. One says 21 and the other 89.  We and they can quickly see that one high is not another high.  And they can start to have the famous conversation about how high is high.  We can laugh, but actually this is a useful conversation.

In fact, one of the most valuable things about the numbers is that it makes the conversations better.

Tacit Knowledge

We just gave the example of the more useful conversation that arises.

When they vote, and they disagree significantly (wider than 3 Fibonacci cards), we want the two extremes to talk. Others may talk as well.

What do they talk about? Well, we think it is best to think of this as sharing the Tacit Knowledge.

One definition of tacit knowledge is "all that stuff we know, but we don't even know we know it, and it has not been made explicit it."  And, obviously, this is knowledge that we think is relevant and even useful in a given domain, or to accomplish a given set of work.  Explicit knowledge is knowledge that has been written down or put in a formula.

Do you want a Team to share their tacit knowledge?  Of course! In all the relevant domains.

Is it easy to get them to do so?  NO!  It is extremely hard.  In part because they don't know what they know, and in part because each person doesn't know what the other people are missing.

Priority poker forces them, in a fun way, to share the tacit knowledge.

In my opinion, this is the most valuable thing about the whole exercise.  Not that other things would not justify it.  But the sharing of the tacit knowledge is the single most useful thing.

Helping the Product Owner

Priority poker makes the PO job easier.  And it is a very very hard job, so any help is welcome.

In what way? Without priority poker, the PO had to make tough choices in ordering the Product Backlog.

Let's assume, in former days, that he talked to all the business stakeholder individually.  And they disagreed, of course, on the values of different stories.

So, the PO has to use up his political capital in just saying: This story is #1, this one #2, etc, etc.

This was 'risky' and often there would be some tense conversations. Too often the PO would be wrongly overridden by one or two business stakeholders.

Now, with the priority poker, all the business stakeholder educate each other. (Again I say, bring the popcorn.  This is fun to watch.)

Still sometimes, in relatively rare cases, all 4 of the business stakeholders are being stupid at the same time, and the PO's number will make only a small difference in the average.  And let us assume the PO's number is right.  Only then does the PO have to use political capital to 'move' the story to a more correct BV number or more correct ordering.

This reduction in effort frees the PO to focus his work in other areas.

Overall benefits

I want to reiterate the key overall benefits I mentioned earlier.
  • They all see the same elephant (better)
  • They all are more motivated
  • They all have shared the tacit knowledge
If priority poker is done with the implementers, these benefits accrue to the whole team.  And remember that motivation is not just a 'feel good' thing; higher motivation directly leads to higher productivity from the Team.

I hope you try priority poker soon.  And tell us how it went.  I hope you will tell us how much it helped you.  

Saturday, February 13, 2016

What is Scrum?

I am starting a series of posts to explain quickly what Scrum is.

It turns out that Scrum is very simple, and yet also very hard to explain concisely.

The main purpose of this series is to give my course attendees a bit more of an introduction than the Scrum Guide does.
Scrum is an agile method co-created by Jeff Sutherland and Ken Schwaber in the early 1990's.

It was known then, and has been known since, to enable Teams to achieve much more productivity, to find work more satisfying, and to produce wonderful products for customers.  Scrum is not a miracle, it is not a panacea, it is no guarantee, but Teams regularly do impressively better by using it.

Scrum is one of many agile methods.

Agile methods are usually defined as those methods that follow the Agile Manifesto and the Agile Principles.  Jeff Sutherland and Ken Schwaber were both there when the Agile Manifesto and Agile Principles were created.  They helped create them.

One of the key things about Scrum is that it is simple.

Scrum is only providing a bare framework for a Team to work in.  The fewest possible constraints to enable the Team to pop up to a new level of functioning.

What is Scrum most essentially?  Ah!, this is hard to say.  It was created by two guys in New England, and they usually like to express themselves very practically, so you may have to experience Scrum for awhile before you can answer the question.

Team Sport

Scrum is a Team sport.  Scrum tries to enable a Team to be more successful.  Or at least to see how they are doing, and then decide what to do about that.

We mean a real Team. That is, all members of the Team are expected to collaborate.  And each is supposed to take full ownership of the full success.

This does not mean that everyone is equal or that they all have exactly equal skill sets, or that they all have skill sets in all areas.  But that, together, they are taking on the goal of success.  They are taking on the Vision as defined (usually and mainly) by the Product Owner.

We mean a real Team.  Virtually everyone in business has been told 'you are on team X.'  But mostly those are work groups or something similar, not real teams.

Among the attributes of a real Team is that each member is 100% dedicated to only one Team.  And the Team has a common purpose, and all members of the Team are bought-in to that purpose.  To accomplishing that goal.

Team Roles

Within the Team Scrum defines 3 roles:

Product Owner


Implementer (role)

Note that the current Scrum Guide calls the Implementer role the 'Team' role, which I think is confusing to beginners.  It gives the impression that there is a Team within a Team.  And I find this is unhelpful.

Scrum lore has the 'chicken and pig story.'  I am told some cultures do not like this story (I do not know which ones or why), and so it is used less.  But in the US (where I live), it is still a useful metaphor.  (Let us of course agree that no one truly wishes to be compared to a barnyard animal.)  I will not give the story here, but the idea is that the pigs are committed and the chickens are 'only involved.'  From the point of view of the pigs and their work, to be 'only involved' is not bad, but it also not good.  The chickens are normally less reliable in delivering what we want on time with high quality.  But we find that chickens are always necessary.  The pigs can never, in my experience, complete their work without some help from some chickens.

Roles Outside the Team

I want to mention two more roles outside the Team.

Customer.  Customers are those real people who will use our product. They may be internal or external to the organization we work in.  It is in delivering something wonderful to them that we get the greatest satisfaction. Very typically, the customers are in 'pain' (in some sense or other) and we are delivering pain relief.  One can appreciate the urgency in doing that.

Business stakeholders.  I use this term to represent the people that must work with the Team part-time, but every sprint.  Mainly to give us feedback. I will say more about them later.

Thursday, February 11, 2016

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

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

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

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

Maybe you will enjoy reflecting on the quote.

Friday, February 5, 2016

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 [...]


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.