An invitation to join a learning consortium

As many of you know, I have been working with Steve Denning, author of Radical Management, unofficial speaker for the Drucker Forum, and Member of the Board of the Scrum Alliance. His passion is about how management needs to reinvent itself to meet the challenges of the creative economy.

Steve and the Scrum Alliance are striving to build a Learning Consortium to explore the management implications of the emerging Creative Economy.

The members of the Learning Consortium will select five organizations from among these submissions and organize one-day site visits at their locations. Each host organization will make presentations and hold discussions about what it is doing, how it is doing it, and what it is learning. Membership of the consortium is limited to 30 organizations.

Each organization will be invited to send participants on the site visits. Once the site visits are complete, Scrum Alliance will organize a conference at which the Learning Consortium will make presentations and hold discussions about what has been learned. The Learning Consortium will produce a report of the conclusions of the visits and its review. The report will be made available to the 30 organizations.

Could your organization want to be one those 30 companies?

Are you curious? If so, please contact me, and I will be happy to put you in touch with Steve! Or here is more info:

• Steve presents the idea on Forbes.com.
• You can find the full concept on Steve Denning's website.
• You can find Financial Times columnist Andrew Hill's article supporting the idea online (paywall).

Could someone in your organization be interested in participating? If so, please drop me a line! And I will be happy to put you in touch with Steve directly.

EDIT: fixed missing links, formatting.

What does it take to be a good Scrum Trainer...

... and, who would like some kind of training to help become one?

The Doctor: Am I a good man?
Clara: I don't know. But I think you try to be and I think that's probably the point.
The Doctor: I think you're probably an amazing teacher.

This year, I have my second full year as a Certified Scrum Trainer behind me. Looking back, it seems the first thing that happened after becoming was a CST was getting a steady stream of requests from aspiring CSTs to co-train with them. I held off the requests until this year. I have now worked with four aspiring trainers. In each case, I learned a lot and have come to appreciate both the value and the limitations of the mentoring system. I want to create a workshop for aspiring Scrum Trainers, so that they can rapidly achieve the level of a good CST.

What does a good trainer do?

In my eyes, the purpose of a Scrum Master course is not to teach people the basic mechanics of Scrum. You can learn that from a 10 or 12 page document. The purpose is to enable the participants to discover a new, better, and more fun way of working, and leave them inspired to take that vision back to their companies to make it a reality! And they should have enough hands-on experience to have confidence and enthusiasm while getting started.

Just as Morpheus could only lead Neo to the door, but Neo had to choose to pass through, the job of a Scrum Trainer is to offer people that red pill. If what they learn resonates with them, they will want to plunge down that rabbit hole and explore it for a long time to come!

How do you train that? I believe that being a good trainer is a mixture of passion, attitude, skills and experience.

Passion

If there is one thing that can't be taught, it is passion. On the other hand, passion is contagious. So I try to give participants the opportunity to feel my passion and understand why I am passionate about Scrum. I believe sharing stories and learning by doing are the only way. As a Scrum Trainer, you need to be able to tell inspiring stories and facilitate great experiences.

Attitude

If you teach inspect-and-adapt, you have to do inspect-and-adapt, otherwise it is not authentic. (And sooner or later, you won't be very good, compared to others who do.)

I thought I was a pretty good trainer when I started. (Actually, I thought I was a very good trainer when I applied, which probably slowed my application tremendously.) Shortly after I started teaching certified courses, I noticed my Net Promoter Scores were not what I thought they should be. I also realized that despite collecting feedback from participants since my first course, I had never actually implemented a suggestion based on that feedback!

I wasn't inspecting and adapting, so I resolved to start. Since that moment, I read all the feedback. After each course, I strive to implement at least one suggestion or address one issue in the next course. I also send a follow-up to my participants with a summary of their feedback, and if possible, tell them what I plan to do differently in the future thanks to their feedback.

A funny thing happened. After an initial and substantial improvement, it got harder to improve. In some cases, I even regressed. But I didn't stop, even as I suffered some low points. Some issues were really hard to solve. I knew what the problem was, but didn't know how to solve them, even as I heard, time after time, that I needed to do something about it.

My willingness to adapt actually made it easier for me to change when the time was ripe. By always looking at how my customers were dissatisfied, I knew what needed to be done. Sometimes it took a while, but when I saw the solution to my challenges, I was able to implement them right away! (Thank you to the trainers and co-trainers I have worked with this year: Lizzie, Hugo, Elena, Niranjan and Andreas. Each of you has helped me move forward in important ways.)

The jump in my Net Promoter Scores was immediate and has been sustainable. I don't know if that qualifies me as a good trainer, but I am certainly better than I was two years ago, and it is the inspect-and-adapt cycle of Scrum which enabled me to get here.

How would I summarize the right attitude? A willingness to inspect, adapt and collaborate. How could you train that? Again, I think learning by doing and experiencing a-ha moments is the way to go.

Skills and experience

What else does a top trainer need to know? I believe a CST-level Scrum Trainer should...

• embrace the Agile Mindset
• have a validated deep understanding of Scrum
• have a validated understanding of what is not Scrum
• know how to teach so people learn.
• be able to teach any relevant topic spontaneously without powerpoint
• be able to tell authentic stories about their own experience doing Scrum to illustrate key points
• understand related approaches, e.g. Kanban, Radical Management, Lean Software Development, Extreme Programming, and how they relate to Scrum
• understand effective approaches for change leadership, e.g. Leadership Storytelling, Working Agreements, and how they relate to Scrum
• understand current vs. deprecated Scrum and agile practices
• be able to work with very large groups effectively

A Scrum Alliance Certified Scrum Trainer also has had their understanding, ability to teach, and course materials validated both against the authoritative Scrum literature and the understanding of Ri-level practitioners in the community. A CST candidate should be well prepared for the Scrum Alliance TAC (Trainer Acceptance Committee) process.

Next Steps

This is a work in progress. Two questions:

1. Have I captured the right vision for a good trainer? What's missing? What's excessive? What's just wrong? Please leave a comment!
   
   
2. Is there interest from aspiring Scrum Trainers for such a training? Do you know anyone who would be interested in attending some kind of workshop (webinar? combination?) to become a better Scrum Trainer or have an easier time with the TAC? If so, please share this article with them and invite them to start the conversation on my contact form.

Update: I realized that the form workshop was too limiting. Maybe a webinar, or a combination might be better, as it could be a) more long term, less geographically fixed.

How many people do you need in your team?

How big should your team be? It depends on what your goal is. In my classes, I have been showing the relationship between project size, cost and calendar time forever, based on research I had read, but could no longer find. Well, I think I have found the source, a 2005 paper from Team Size can be the Key to a Successful Software Project.

How big should your team be? Well it depends on what your most important goal is:

1. If you are trying to keep costs down, a team size of 3 people or less is optimal.
2. If you are trying to get a result as quickly as possible, a team size of 5 to 7 people is optimal.
3. If you are trying to hit a budget or deadline as accurately as possible, again a team size of 5 to 7 people is optimal.
4. If you are trying to burn a large budget, team sizes of 9 and up are best. These effects appear to be exponential.

Is item 4 really a goal? Nevermind. Silly question.

I think this data explains the Guidewire approach of keeping teams between 3 and 6 people. In effect, this has them cycling between lowest cost and fastest delivery, which is probably a sweet spot to find yourself in.

OTOH - This study is largely based on waterfall projects. Does anyone have the data to create a similar study of agile projects?

Why are you doing Scrum?

I am often asked questions like, "What do I do in Scrum when my team is spread across three locations?" My answer is usually something like, "you will suck." "Don't tell me that! That's insulting! I have to do that." At this point, I smile to myself and think, "that may be true, but you will still suck."

Why do I have conversations like this?

Last week, a got a question about electronic task boards. I could smell another one of these 'yes, but' discussion starting, so I chose to answer the question with a question: Why are you doing Scrum? I drew this picture on a flip chart and invited the participants to put dots on the location corresponding to their (organization's) goals:

Most dots were to the left of middle, the low performance choice, which explains why people did not like the high performance answer.

Scrum is based on the patterns of the 95th percentile of project performance, i.e. those awesome teams that are 3 to 10 times more effective than average. Those patterns are probably the same patterns as you experienced in your own best projects!

So why are you doing Scrum?

What is the Agile Way to Adopt Agile?

Pearl Zhu just posted an interesting question on the Stoos linkedin group. "What is the agile way to adopt agile?" Her answer did not resonate much with me, so I'd like to share how I start a company down the agile path.

Agile is about people, both the people doing the work ("People and Interactions over Process and Tools") and the beneficiaries of the work ("Our highest priority is to satisfy the customer through early and continuous delivery...."). I believe people's own experience makes the most convincing arguments.

So I start by asking the people involved what has worked for them in the past. I ask them to remember their best projects and share the stories of those projects with other people in the room. (See Remembering Heaven for a description of how I do it). After hearing everyone's best projects and identifying the most promising role models for moving forward, we reflect on the patterns that made those projects successful.

Most people are not currently working on their best project ever. In fact, usually only about 10% of the people in the room are currently working on a great project. Very often no one at all is currently working on their best project ever. (I have seen numbers as high as 50%, but the difference between 10% and the higher score has always been a group doing Scrum!)

Would you like to be working now on your best project ever? Most people would! Could you agree to implement the patterns which made your best projects so awesome? Most people are willing to do that.

Wait! What exactly have we agreed to? Well at this point, I start to introduce Scrum (my favorite place to start), not as a set a of roles and processes, but rather as a small set of patterns. These patterns are easy to recognize in people's own successful projects. What patterns do we find?

• Deliver something that works regularly
• Inspect and Adapt regularly
• A small interdisciplinary team solves the problem
• Once voice speaks for the customer / user / stakeholders
• Management guides and helps, and knows when to stay out of the way
• High performance is achieved through continuous improvement 

So now agreeing to do Scrum is quite easy, and we can start without any significant resistance. Why? People recognize Scrum as a place they want to be, because it is a place they have already visited and liked: A great project where work is fun.

Tackle your organization impediments with 59 minute sprints!

As a comment on "How much do you let a new team self organize?" IanJ asked

Why are 59-Minute Scrums cool and what are they good for?

The 59 Minute Scrum has been a popular training exercise for years in the Scrum community. The team gets a problem to solve, and goes through a "simulated" sprint to solve the problem. You get to experience real Scrum in a safe environment.

Fifty-nine minute sprints are an excellent learning tool because so much happens in such a short time. Everything that goes wrong in a real sprint can happen in a 59-minute sprint.  They are great for problem solving!

In my classes, I usually simulate a 3-day sprint, using 5 minutes for each half of the Sprint Planning and the Sprint Review, 12 minutes for each day, and 4 minutes for each daily scrum. If you add it up, it comes to 59 minutes. Each Scrum Team has a Scrum Master, a Development Team and a Task Board. Depending on the context, there may be one Product Owner for all the teams in the room, or each team gets it's own PO. Note the 59 minutes does not include the Retrospective, which I handle separately in my courses. I usually don't too much about the length of the Sprint Review either.

I have found that if a team does three of these over three days, by the end of third iteration, they are really good at the basics of Scrum and ready to do it "in real life."

What is the difference between this being a Scrum simulation and a real-life "micro Sprint"? Well not much, except for the importance of the results you are producing. If you plan to throw away the results, it's a simulation. If plan to use them, it's a micro-sprint.

What would be an example of using micro-sprints? One area is to address organizational impediments. Imagine you have assembled in one room not just the Development Team, but also their management, important stakeholders, the operations group and other interested parties for the product. Ask them, "What are the biggest impediments to success of our project?" Have them write them on stickies and post them on the wall. Like in a retrospective, have their owners present them. The others can ask clarifying questions.

Finally you do some sort of dot-voting to identify the top issues. Exactly how you do this depends on many things, most importantly the number of people in the room. One way is to each table create a short list of two or three items, merge the lists to get about 10 to 15 items, then have everyone dot vote the this short list to prioritize the problems.

Now you are ready to use Scrum 59's to tackle your challenges. What could you do to solve the issues identified? Form teams around the top priority cards, usually one team per card and one team per table (did I mention, island seating with about 6 to 8 people per group?) Whoever wrote the top priority cards becomes Product Owner for those cards.

Iterate once or twice to come up with possible solutions for those impediments.

I have seen awesome results with this approach! Usually the people who are most surprised are the managers in the room, because they have never seen their staff working so creatively and with such energy. And the teams come up with good ideas that the managers never would have thought of. Oh, and they get really good at the mechanics of Scrum and ready to take on the challenges of their project using Scrum to help them.

Prepare to be amazed! And don't forget you can start implementing those solutions right away!

On the road to high performance teams

I have been thinking about continuing education for Scrum Masters.

The objective of a Scrum Master is to create a high performance team, which is in turn part of a high performance organization. So both team and Scrum Master must develop their skills moving forward. Just facilitating the Scrum meetings won't get you there.

The Scrum Alliance has defined the Certified Scrum Professional (CSP) program. This is the journeyman-level Scrum certification (think Apprentice -- Journeyman -- Master ). This certification is not achieved by passing a test, but rather by demonstrating a commitment to Scrum by doing Scrum and learning about Scrum.

How do you achieve the continuing education needed to achieve journeyman status? My answer is the Scrum Breakfast Club. The Scrum Breakfast Club is an inexpensive, recurring open-space format for solving problems related to Scrum and Scrum Projects (and learning advanced Scrum as you do). You bring your problems and find solutions, with me and with other people who face similar challenges. I also provide an opportunity for one-on-one coaching during this time.

Each Scrum Breakfast Club workshop earns you four Scrum Education Units. (If you are familiar with the PMI, these are like PDUs, and can also be used as PDUs).

From a career point of view, if you take a CSM Certified Scrum Master course, follow it up with a CSPO Certified Scrum Product Owner course 6 months later, and participate regularly in the Breakfast Club, after 2 years, you will have accumulated enough Scrum Education Units to qualify as a Certified Scrum Professional. And you have had plenty of opportunities to address the actual issues in your organization.

Here is a description of the Scrum Breakfast Club. How does this fit into your plans?