Understanding the Indian 'Yes'

My experience with the word 'yes' in India is that it doesn't seem to mean what I think it means. And the word 'no' does not seem to exist.

Doing business with India for me has always been a somewhat strange experience. As native speaker of North American English, there is a language barrier. Yes, it's English, but.... I was never really sure when negotiating with my business partners whether they were really going to deliver what they said they would. Often there would be substantial differences between what I thought we had agreed to and what was actually delivered.

Since I agreed to a four city tour in November of Scrum Trainings, I thought this would be an excellent opportunity to explore what yes really means, and why it remains such a stumbling block. What did I find out about 'yes' and other aspects of Indian culture?

Raising the question

My Scrum courses devote substantial attention to working agreements. At the start of each course, I facilitate a discussion among the participants. “What agreements do we need among ourselves so that we can work together effectively between now and the end of the course?” The participants propose their topics, and then agree to concrete actionable proposals. I might add a topic or two. Sometimes we have to modify the proposal before we can come to an agreement that everyone can really support.

Agreements among the participants make for an effective course and agreements among colleagues are an excellent tool for transforming corporate culture. You can't change corporate culture directly, but you can influence your meeting culture quite strongly, simply by making working agreements with your colleagues. This in turn influences and changes your corporate culture.

Nicolas Jene, one of my participants last October was retaking the CSPO course he had taken a year ago. Back then, we had made a number of working agreements, including being on time and ready to go after breaks, devices off or on silent, no crosstalk, the attention protocol, how to deal with questions, etc.

People are the same everywhere...

Nicolas noticed that the working agreements this time around were essentially the same as the agreements as in his last course, so he asked, 'Are the working agreements always the same? Even in different cultures?” I thought back to my the last year of courses in Switzerland, in Russia, in Portugal, in Italy, and in Texas, and replied, 'yes, pretty much. But I am not sure how that will be when I get to India, because the culture there is quite different compared to where I have been before.

So in all of my India courses, I facilitated the same discussion. What do we need to work together effectively?

All of my participants in India asked for and agreed to more or less the same the agreements, just like at every other place else I have been to. They did have some novel suggestions, but the topics and actual agreement were essentially the same.

My conclusion? People are the same everywhere. They want the same things from each other. They need the same things to work effectively: Focus, Commitment, Courage, Openness and Respect. Sound familiar? These are the Scrum values. You find all of them reflected in people's working agreements.

But cultures are different

If people are the same everywhere, does that mean everyone thinks alike? Of course not! Case in point: during my last product owner class, I showed Henrik Kniberg's fantastic video “Agile Project Ownership in a Nutshell” (watch it here). One highlight of this video is the importance of saying 'No.' “Pat [the product owner] practices [saying No] every day in front of a mirror.” After watching the video, the class wrote down their “Eureka!” moments of what they would take home from the video. Most of the participants found that 'No!' was a highlight of the film. “We are allowed to say no!?” “We're expected to say no!?” “Wow!”

One person, of Indian origin, had a completely different lesson from the video: “Sometimes it is better to say yes and prioritize down.” What?! That was exactly the opposite of what Henrik's video was trying to say, or so I thought. I even asked him about it. Yes, that was his a-ha! moment. After getting past my disbelief, I reflected on why his answer might have been different from mine and the others.

If the inputs seem the same, but the outputs are different, then there must be some other inputs I don't know about. I call these inputs 'culture' and I decided I wanted to explore that further during my trip to India.

Why is 'no' so difficult to say?

At each course in India, during the section on working agreements, I introduced the topic of yes and no, and explained why I thought there was an issue. My participants agreed that this misunderstanding occurs quite regularly when working with western companies. So I invited the participants to discuss in pairs why saying no is so difficult, then report back on to the group.

To my surprise, there was no hesitation to discuss the issue (though I had done a lot to lower the social risks in the room before asking question). The opinions of all four classes – over 100 people – centered on three issues:

• Our upbringing discourages us from saying no. It is impolite to say no.
• If I say no (to the customer), my company might lose the business.
• If I say no (to a manager), I might lose reputation and risk losing my job.

In short, it's about fear. It's about the challenges of living in a developing nation. It's about the fear of becoming part of the 60% of the population that lives on $2/day or less. Saying yes is an accommodation. You may lose the business or your job later, but you do have it today, and that is perceived as much lower risk than saying no right away. Given that upbringing appeared so often in the list of reasons, it looks like the accommodation is deeply ingrained in the society.

What does 'yes' really mean?

What does 'yes' really mean in India? It depends. It might really mean yes. It might also mean “I'm saying yes to satisfy your expectation” (but without committing to actually deliver on the expectation). More likely, it means, “I'm going to do my best, but there may be outside forces that I cannot control which will prevent me from succeeding.”

How to bridge cultural differences?

I don't pretend to have the definitive answer to this question. I found being in India, talking face to face with people and learning to recognize their body language were both very helpful. I found it easier to work with people while I was there than over the phone from Switzerland.

Is there really a conflict between being polite and setting realistic expectations? I think this is a false dilemma. Henrik Kniberg pointed out that Autonomy and Alignment are not opposites, but independent of one another. People can be aligned and autonomous. Steve Biddulph wrote that parents can be both firm and loving with their children. How can you set realistic expectations and be polite? I think that is a fair question for any team to ask of itself.

Conflict avoidance is not evil

Many facilitation techniques avoid using the word No. In a retrospective, we first identify possible topics for improvement. Then we identify the most important items, and say yes to a few of them. We don't actually say no to anything. Just yes. Dot-voting is classic consensus-building tool. Identify the most important, start there. And Rod Collins' Work-Thru also focus on identifying where we agree, so we can start here, and deferring points of conflict until later, when trust is higher and the situation is clearer. (Read more about Work-Thru's...)

Are there patterns here which could be applied for other kinds of collaboration? I have seen evidence that working agreements can be extremely effective at transforming corporate culture. Can working agreements be the basis for bridging cultural differences within a project? I believe so. You create your own culture through your working agreements (among other things – good stories are vital!) within your project so that you and your on-shore and off-shore collaborators can work together effectively.

Finally I believe that one day, people in India will let go of their fear. It is not weakness that makes people afraid, it is fear that makes them weak. India has strong abilities and great prices. There will always be a demand for that combination. If this customer gets away, there is always the next one. Once people realize they don't need to be afraid, they will have the courage to say no and to say a yes that really means, Yes!

What good are story points and velocity in Scrum?

We use velocity as a measure of how many story points to take into the next sprint. When you take in enough stories, and story points, so that you reach your average velocity, then, you can end the sprint planning meeting.

Although this is a common approach, it is exactly how you should not use story points in Scrum. It leads to over-commitment and spillover (started, but unfinished work) at the end of the sprint. Both of these are bad for performance. How should you use story points in planning? How do you create the Forecast? And what do you do if the team runs out of work?

The first thing to remember is that Development Team is self-organizing. They have exclusive jurisdiction over how much work they take on. The Product Owner has final say over the ordering of items in the backlog, but nobody tells the the Development Team how much work to take on! Not the Product Owner, not the ScrumMaster, and certainly not the math!

As a Product Owner, I would use story points to help set medium and long-term expectations on what is really achievable. Wish and probable reality need to be more or less in sync with each other. If the disparity is too big, it's the Product Owner's job to fix the problem, and she has lots of options: less scope, simpler acceptance criteria, more time, more people, pivot, persevere, or even abandon.

As a ScrumMaster, I would use velocity to identify a number of dysfunctions. A wavy burndown chart is often a symptom of stories that are too big, excessive spillover, or poorly understood acceptance criteria (to name the most likely causes). A flattening burn-down chart is often a sign of technical debt. An accelerating burn-down chart may be sign of management pressure to perform (story point inflation). A lack of a burn-down or velocity chart may be a sign of flying blind!

As a member of the Development Team, I would use the estimate in story points to help decide whether stories are ready to take into the sprint. An individual story should represent on average 10% or less of the team's capacity.

How to create the Sprint Forecast

How much work should the team take on in a sprint? As Scrum Master, I would ask the team, can you do the first story? Can you do the first and the second? Can you do first, the second and the third? Keep asking until the team hesitates. As soon as they hesitate, stop. That is the forecast.

Why should you stop at this point? Taking on more stories will add congestion and slow down the team. Think of the highway at rush hour. Do more cars on the road mean the traffic moves faster? Would be nice.

Why do you even make a forecast? Some projects say, let's just get into a state of flow, and pull work as we are ready to take it. This can work too, but my own experience with that approach has been mixed. It is very easy to lose focus on getting things done and lose the ability to predict what can be done over a longer period of time. So I believe Sprint Forecasts are useful because they help us inspect-and-adapt enroute to our longer term goal.

What about "yesterday's weather"? Can we use the results of the last sprint to reality check the forecast for this sprint? Sure! If your team promised 100 but only delivered 70 or less, this is a sign that they should not commit to more than 70, and quite probably less. I call this "throttling", and it is one of my 12 Tips for Product Owners who want better performance from their Scrum Teams. But yesterday's weather is not a target, it's a sanity check. If it becomes your target, it may be holding you down.

What if the team runs out of work?

On the one hand, this is easy. If the team runs out of work, they can just ask the Product Owner for more. A working agreement can streamline this process, for example, Team, if you run out of work, you can:

• Take the top item from the product backlog.
• Contact me (the Product Owner) if you get down to just one ready item in the backlog
• Implement your top priority improvement to our code ("refactoring")

Implementing improvements from the last retrospective is usually a particularly good idea, unless you are very close to a release. There are investments in productivity that will often pay huge dividends, surprisingly quickly!

Are agile trainers agile?

There are literally hundreds if not thousands of people out there who will train you to do Agile (and some will even try to convince you to be Agile). Some of them are certified, some are not. How many of them apply Agile to their own profession? I believe the answer is "not many," and I have realized that I was not one of them. This a-ha moment help me refine the purpose of my CST mentorship program.

When people say "Agile", most people are referring to the four values of the Agile Manifesto. While these are important, I believe the fundamental definition of Agility is contained not the four values, but the first statement: We are uncovering better ways of developing software by doing it and helping others do it. (emphasis added).

I don't develop software, I train people to do Scrum. Actually, I like to believe I enable them to turn their current project into their best project ever, so maybe this "training Scrum" is too limiting. Hmm... let's not go overboard just yet! So what would my manifesto look like? Here is the first draft:

We are uncovering better ways of teaching Scrum, by doing it and helping others to do it! -- Peter Stevens

This has become the overarching goal of my CST Mentorship idea. Not just to get you through the TAC, but to create a community of like minded Agile trainers, who help each other to become better trainers, and help others to do the same.  It is no longer just a CST mentorship program, but a CST Mentoring Network.

P.S. I went looking for trainers who are active and transparent about mentoring. I have only found two (including myself):

• Daniel Gullo - see the section on the Gullo Protocols
• Peter Stevens - CST Mentorship Network

Does anyone else belong on this list? Please let me know!

Announcing: Scrum Trainer Mentoring Program

Do you want to become a Certified Scrum Trainer? Becoming a CST is long process which requires you to demonstrate both your knowledge of Scrum and your ability to teach Scrum to the satisfaction of the Scrum Alliance Trainer Acceptance Committee (TAC). Many trainers resist working with aspiring CSTs, out of fear of competition, lack of interest or lack of time. Until now.

After a couple of attempts on an ad-hoc basis, with both successes and failures, I believe the best way to mentor CST-aspirants is to lead them through a structured program. My goal is that by the end this program, you will be well qualified to teach Scrum and should be ready for the rigors of the TAC. I believe a structured mentorship will be a better way to achieve that goal.

My motto is partnership. I believe that future CST's and I can work together and we can grow together. And I have some ideas on how we can benefit each other. Interested?

1. Check out the CST Mentorship Program!
2. Contact me to discuss further!

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?