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!

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.  

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!    

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.