Scaling Business Agility: Three Essential Pillars for Being vs. Doing Agile

The difference between being a large Agile organization and simply calling yourself one is by correctly scaling Agile with these three tenets.

The concepts of Agile, Scaling Agile, and Business Agility have become buzzwords. The crux of being Agile for the customer and people who are building products and services is buried under a focus on conducting ceremonies.

Prior to scaling Agile, let us not forget the manifesto for Agile software development. It’s all about uncovering better ways of developing software that provides value both to the customer and for people who are part of the delivery stream.

Business agility can be associated with the value ecosystem as below:

Scaling adds complexity to the whole value delivery cycle. It’s a myth that only when we have larger teams involved do we need to scale up. Listed below are a few parameters that add challenges and require scalability at individual and system level:

• Communication and collaboration across distributed teams
• Architecture balance between legacy and modernization
• Continuous integration and continuous deployment across multiple business units
• Dependencies
• Roles and responsibilities within and across teams
• And many more…

An Agile mindset doesn’t happen overnight; let’s explore the pillars for being Agile as we scale.

People

Organization Culture 

If each business unit within an organization operates as a separate function, this has to be the first candidate for transformation. Even before we align the cadence and processes, it’s important to ensure everyone understands the purpose of working together. System thinking evolves as we help the team understand the vision and purpose.

Top management must be aligned before a team gets involved.

Transparency and working agreements within and across teams are vital in building a healthy culture.

Leadership

It’s at all levels, not just top or middle management. This is about enabling and adding value at every level in the ecosystem. It starts with product management who plays a crucial role in identifying and communicating value to the entire stream. From Engineering and Support to Program Management and Sales, everyone has a role to play in the value ecosystem. Those leaders must be identified and nurtured by management and the leaders need to hone their skills, not just to show or lead, but to be part of the journey.

Balance Between Customer and People

While we focus a lot on the customer and delivering the value for them, let us not forget the folks who are bringing those value. The Agile Manifesto talks about working software, while at the same time developing it at a sustainable pace by motivated individuals. The motivation becomes quite a challenge especially when the people are part of different value systems and are coming together for a common purpose. For knowledge workers, the work itself is the key motivation. Hence providing a clear vision on business, product and architecture along with the role they play are essential. HWell, happy employees try to make customers happy.

Technology

DevSecOps 

Who says Agile is all about just processes and practices? As we focus on delivering value in minimal predictable cycle time, it’s important to make our continuous delivery, continuous integration, and continuous deployment pipeline stronger. The toolchain for coding, building, testing, packaging, configuring, releasing, and monitoring must be carefully aligned with the organization culture as well as the value ecosystem. The DevOps team should be an integral part of the development team instead of behaving like governing function. As we scale up, it is essential to incorporate security in the whole value stream. Hence DevOps needs to scale up to DevSecOps. Every individual irrespective of their role must understand the critical role DevSecOps play and should upgrade themselves to be comfortable with the toolchain and value it brings in.

Practices

Framework

There are several frameworks available such as SAFe and LeSS to help the enterprises scaling up Agile. The framework should fit our purpose, not the other way around. It’s important to evaluate the framework for a fit in our organizational culture, technology, and adaptability to customization. Frameworks are intended to be used as-is, but we need to see if they are adding value or hindrance. Let us not forget our foundation of the Agile Manifesto and value ecosystem while we adopt and transform for the framework. After choosing the framework, for underlying Agile methodologies, we can leverage the knowledge matrix explained in the article “XP: An Obsession for Simplicity and Productivity with Focus on Humanity” as one size doesn’t fit everyone.

Lean Flow Focus

As we scale up, we might be introducing new processes and practices. At each step, we need to question ourselves on how this is adding value overall. We need to increase value-add, minimize the value enablers and eliminate the non-value add. For further reading on how we can optimize the value flow, please check out the article on “Let’s Lean on Lean.”

In summary, we can scale up business agility focusing on business outcomes by motivated individuals through leadership. At each level in the value stream, everyone has a key role to play:

• Product Management: Vision, roadmap and defining the value
• Architect: Laying the path ahead
• Program Manager/Scrum Master: Alignment & removing the roadblocks
• Team Member: Delivering the value
• Leadership: Leaning the non-value elements
• Cross functional teams (Support, Sales, Marketing, etc.,): Value enablement

Advertisement

4 L’s Retrospective…

There are different ways you can do a retrospective with your teams. Choose the one that will engage your teams and help in identifying few action items that will benefit the teams and in turn the organisation. In this blog we will discuss the 4 L technique. Initially developed by Mary Gorman and Ellen Gottesdiener, it is a simple and popular technique.

What?

The Four L’s is a classic exercise that can be used in agile retrospectives. It helps your teams to look for things they Liked, Learned, Lacked, and Longed For in their iteration, and to take actions based on their shared insight on how they are performing as a team.

As with all retrospectives, 4Ls should be timeboxed. Depending on the size of the team, 30-60 minutes should be enough. If you are doing it for the first time, then allow up to 120 minutes.

The 4 L format can be a great technique to gather data or brainstorm on ideas, etc. It can be a great facilitation tool for conflict resolution, ideations, decision making, etc.

When?

The questions might be subtle but by moving away from the traditional agile retrospective and allowing people to be more engaged from a “heart and mind” perspective can switch up people’s thinking and open-up new insights

Also, be observant and cognizant of the team temperament. There are times your team members will not want to discuss their challenges openly but, talk about those during their water-cooler discussions. Be very attentive and full of empathy for your team. Know that we all are human beings and not machines. We deal with machines and we discuss with people. 4 L is one of the ways to do it.

As an Iteration Manager it is very important for you to know your team temperature. You are one of those leaders who have the responsibility of leading your teams to victory while ensuring that even the new entrants in your team get enough opportunities to participate in the victorious journey. It is no fun to reach the goal with few star performers instead of reaching the goal with everyone involved in the journey. The focus should be on creating a star team (cross-functional) rather stars in a team.

In short encourage your team to:

• Highlight the positive (liked & learned) as well as the negative (lacked & longed for)
• Think mostly from a factual (what happened) perspective, rather than an emotional perspective.

More details…

The 4Ls retrospective is designed to get people to share their thoughts as part of being agile and with the aim of continuous improvement. By asking these questions, it can help open-up the team in to sharing their thoughts, bring out new ideas and foster a sense of being heard. It is based around the following key themes:

• Liked: What did the team really enjoy about the sprint? In particular; what went better than expected? Emphasize on the positive.
• Learned: What new things did the team learn during the sprint? These can be technical things (like the importance of unit testing) or, nontechnical things (like a new and effective way to keep a key stakeholder informed). It can also be about new ways of doing things. It can be around technology, process, software delivery frameworks, etc.
• Lacked: What things could the team have done better during the sprint? What seemed to be missing from the last iteration? This might be something that was unclear or needed to be implemented to ensure that things continue to run smoothly.
• Longed For: What things did the team desire to have during the sprint that were unavailable? Again, these can be technical (like the need for a continuous integration server) or nontechnical (like the desire for more face time with the stake holders).

You need:

Post-it notes, flip chart paper, white board, pens etc.

Process:

1. Hang four posters, one for each L, around the room, titled appropriately. Or, use a white board and divide it into four quadrants. One quadrant for each L.

4 L- Quadrant on white board

• Ask people to individually jot down what they Liked, Learned, Lacked, and Longed For – one per sticky note. When the time is up (3-4 minutes), they silently place their notes on each poster.
• Divide the team into four groups; assign an “L” poster to each group. They read all the notes, cluster as appropriate and identify themes.
• Each group reports out on the themes.
• The entire team (all four groups) then decides how they might use the data. Identify the action items. Share the outcome with the team and stake holders, if required.

How we did it?

Action

Ask each team member to add what they think under each of the four questions. This is best done independently. This process might be best done anonymously in order to help surface any issues which might otherwise not come out. They can indicate when they have finished, or you can set a timer so that you know when to move onto the next stage.

Brainstorm

Scan the ideas for common ground and have a quick discussion. Drag and drop related ideas to combine them for easier voting. Team Retro can also automatically suggest ideas that are similar, saving you and your team valuable time.

Voting

Ask people to independently vote for what they would most like to discuss in the meeting, or items that they feel are the most important. You might want to have 4 votes for example so that they select one under each topic. We used dot voting.

Votes can be tallied for the Discuss stage.

Results (Discuss and identify the action items)

You can now discuss the top voted ideas.  Walk your team through ideas one-by-one and keep the conversation focused.

Create action items based on discussions, assign owners and due dates that will carry through for review at the next retrospective.

Pizza… 😊

Spend the final few minutes to allow the team to appreciate each other and share their thoughts. That will encourage the team to speak up in groups without being overwhelmed.

Researched by- Nabarun Paul, Iteration Manager at Tavisca, A cxLoyalty company                                   

Mother-in-law syndrome in the Agile world

Mother in law is spoiling the family life! Managers are spoiling Agile Team!

“Monster in-Laws:” A Leading Cause of Divorce. In the Agile team context this causes for attrition.

An article titled “Divorce Causes: 5 Ways to Destroy Your Marriage” in the Huffington Post states that in-Laws can be a leading cause of divorce. Author Francesca Escoto writes, “how spouses relate to the in-laws is a strong predictor of marriage longevity. A man who gets along with his wife’s parents is wise — his chances of a strong marriage increases by about 20 percent. Women who get along with their in-laws actually have an increased probability of divorce, by about 20 percent.” 

What can we do about it ? We need them but they should not break the family.

In an Agile Team/Family, the manager is like the mother-in-law! in the Agile world they do not have much to do, because they have retired from the active family life, or lets say delivery role. This delivery role is managed by the Product owner and Scrum Master.

But, managers like mother in law is interfering in every course of action.

Have you seen such instances in Agile projects where the manager is hovering around the scrum team?

Mothers-in-law are known for being, judgmental, critical and overbearing. They don’t want to leave the control. For them, you are still kids and cannot decide for your good. In Project team also Manager could be the same.

She is always right, without exception. Which means that she’s never wrong. She’ll never admit being wrong, and she will never apologize for anything. In her opinion, you (and possibly your spouse) are the only person to blame. Similar situations can be seen in the Agile Team.

To establish her dominance she will expect you to please her. That would require you to appear at every family event, to learn her way of cooking, cleaning and just about everything else under the sun (because her way is clearly better). And, if you fail to do any of those, you are doomed! and she has a right to complain about you to anyone who’ll listen. Similarly with the Agile Team, the Manager does exactly the same and the escalation goes to the senior leaders.

If you are still not kneeling to her will, she will move on to heavier artillery. She will start a smear campaign in her community, trying to turn everyone against you. If she succeeds, those people will start putting pressure on your husband to leave you, saying that they’re just “worried about him” and they “want him to be happy.” Similar things can be found with the Agile Team, where Manager will be doing exactly like this and eventually the husband/scrum team member may leave.

Don’t try to mediate your son’s marital disputes. Let them solve their own problem. In Agile team, let the team members solve it, managers don’t have to jump into all these to become an hero. Managers are already heroes, now it’s time for the team to become one.

Don’t rearrange your daughter-in-law’s house. Clearly the coffee mugs should be stored in the cabinet over the coffee maker. Any idiot can see that. But it’s not the Mother-in-law’s kitchen. So, Mothers-in-law don’t decide where the coffee mugs go. In an Agile team, the team decides everything with the help of PO and SM.

1. Fold daughter-in-law’s laundry without her permission,
2. Buy clothes for daughter-in-law that only mothers-in-law would wear,
3. Think daughter-in-law is perfect,
4. Enter daughter-in-law’s bedroom without knocking,
5. Offer unsolicited advice,
6. Show up unannounced,
7. Criticize daughter-in-law’s cooking.

All these activities can be mapped to Agile team context where Managers are getting into team comfort zone and spoiling the self-organized culture.

Many of the items on the list are considered faux pas in any situation. They are a hundred times more egregious when put in the context of a mother-in-law – Manager)/daughter-in-law (SM/PO) relationship. 

How to Manage her, or Managers

What Scrum Masters can do for the Agile team ?

a) Respect her different viewpoints. Even if you don’t agree with what she has to say, listen to your mother-in-law. Don’t immediately write off what she has to say. Hear her out (even if you feel it’s ridiculous) and let her know you’re listening. You don’t have to agree to anything.

Respond neutrally by saying, “Okay, I’ll consider that” or, “Thanks for your input.”

If she puts you in a difficult position, defer to your spouse. Say, “I don’t want to answer right away. Let me talk to my spouse first.”

b) Use humor. Deflecting criticism, or other awkward interaction with humor can deflate conflicts and put everyone at ease again. Whether the situation seems tense or she’s making things difficult, a little humor can go a long way.

c) Work through your own feelings about your mother-in-law. Are you able to put yourself in her shoes occasionally and see just where some of her so-called interfering or judgmental behavior comes from? She values the person you’re married to, so there must be something good inside her!

 – Keep in mind that whatever your feelings, your mother-in-law remains one of the most important people in your spouse’s life. Be sure it’s not your own untamed jealousy causing problems.

– If your relationship with your mother is strained, or difficult consider whether that is affecting your relationship with your mother-in-law. Remember that they are different people, and you can have a different relationship with each one.

d) Create some ground rules. If you live with your mother-in-law, establish some ground rules for living together. If you know there are things that might cause conflict, talk about them beforehand and make sure everyone understands the rules and why they are in place

e) Make compromises. You and your mother-in-law will inevitably disagree on certain things, especially when living together. Choose your battles and decide what things you can tolerate and what things you need to be firm about

f) Create mutually-agreed boundaries. Both you and your mother-in-law may enjoy having your own space and ways of doing things. Ask your mother-in-law how you might make her comfortable while enforcing your own needs and expectations. As long as your boundaries don’t conflict, try to respect her space and independence.

g) Look for the good she does and praise it. Look for the good things about her, not just the bad. If she’s always cleaning despite you telling her not to, thank her for her care and contribution. Find the positive ways she adds to your life, your partner’s life, and even your kids’ lives. If possible, do this in her presence and be genuine

h) Talk about how she makes you feel. If you’re in conflict with your mother-in-law and it’s not resolving over time, or on its own, it’s time to talk about it. If she tends to criticise your marriage, or your parenting, let her know how this makes you feel. Be kind and honest and tell her what you’d like instead. Aim to find resolutions to your problems.

Author: Chandanlal Patary. 

Share your thoughts in the comments section.

Enablement Over Facilitation: 5 Essentials to Be a Great Scrum Master

Being a Scrum Master isn’t just about knowing the jargon associated with the role. It’s about being able to build trust, see the big picture, and enable success.

“We don’t often get the respect we deserve”, “Folks think our role is not a critical part of delivery”, “It’s a thankless job” – we hear this quite often from our Scrum Masters. While the road to becoming a Scrum Master is short, becoming inclusive isn’t as smooth as one thinks. Gaining respect as a Scrum Master requires a lot of dedication, persistence, and introspection. A valuable Scrum Master always goes beyond doing the “cliched” administrative work and adds value by enabling the team.

Based on our experience, we have listed down 5 essential skills that can help gain inclusiveness and respect as a Scrum Master.

1. Build Trust

The critical measure of a good servant leader is trust. Without trust from the team, no matter how hard one tries, it’s hard to succeed in any role.

When people trust us, they are ready to follow our lead and walk along with us.

In his book Speed of Trust, Stephan Covey talks about the framework to gain trustworthiness quotient.

Trust has two dimensions – Character and Competence.

• Character is a constant – It’s necessary for trust under any circumstances. 
• Competence is situational – It depends on what the circumstances require.

Building trust with the team is a stepping stone to earning their respect. People value us when we don’t just talk the talk but walk the walk with a great attitude along with delivering the right results in the right way.

2. Psychological Safety

Google’s massive study on team performance reveals that the highest-performing teams have one thing in common: psychological safety.

 “Psychological safety is a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes.” – Stephen Covey

One of the core values of agility is openness. If people are afraid to speak up, then even if we achieve the business outcomes, the productivity won’t be sustained long enough. As part of forming a team, it’s essential to understand team dynamics as well as awareness about individuals. The personality studies such as Myers Briggs (MBTI) and DISC assessment come handy for Scrum Masters. Working agreements, mutual consensus, asking questions, and inviting people to open up and talk about their perspectives will also help in achieving mutually desirable outcomes.

Conflicts must be healthy and not lead to blame games, judgment, and disrespect. Hence the role of the Scrum Master becomes crucial in conflict resolution leading to personal safety while achieving business objectives.

3. Domain and Technical Expertise

The level of technical expertise required for Scrum Master is always a debatable topic. An extremely technical Scrum Master may end up dictating the team on ‘how-to’ rather than creating an environment to come up with great ideas. A person with no technical background may be clueless about the impediments and mitigation plan to address them. Hence the Scrum Master won’t be able to help the team in a timely manner.

What is important is striking a balance. While extensive technical knowledge is not a mandate for a Scrum Master, a familiarity with the project-specific domains will be a boon for the Scrum Master as well as for the team. This helps to build trust through competency as we discussed earlier.

4. The Scrum Master Role Goes Beyond Facilitation

Facilitating ceremonies suggested by various Agile methodologies is NOT the only job of a Scrum Master, rather facilitation is just a part of the job.

Agility is all about delivering value to the customer in the shortest possible time and the Scrum Master’s role is to provide enablement. We should be flexible enough to understand team dynamics, the nature of change, and other parameters that influence the delivery cycle and adjust the processes and practices as required.  

While theoretical knowledge is good, it’s important to reap the benefits by leveraging the underlying concepts. For each and every step in the value stream, a Scrum Master should ask whether that step is necessary in order to eliminate the non-value added elements in the overall cycle.

One of the challenges for Scrum Masters is to choose the suitable Agile methodology for the team. The article where we discuss out of box thinking and choosing based on the knowledge matrix might help.

5. Be Aware of the Big Picture

Sometimes being too focused on the team level commitments may help in doing an excellent job for that iteration and team. But we should remember we are operating at a system level and a holistic view is critical for success.

“People are working harder than ever, but because they lack clarity and vision, they aren’t getting very far. They, in essence, are pushing a rope with all of their might.”  – Stephen Covey

It’s important for Scrum Masters not just to know about the big picture but also to help the team understand and be part of it.

The team needs to understand ‘WHY we are doing WHAT we are doing and HOW this is going to help the business WHEN we deliver this’ and the Scrum Master plays a crucial role in enabling the team with the required knowledge.

Conclusion

The Scrum Master role is not an easy job. It requires knowledge on where to put our energy, retrospect on what’s working and what’s not and then working on continuous improvements. We need to ask ourselves if we want to help enable our team and experience the satisfaction of being part of the journey or if we want to think of it as a thankless job. The choice is always ours!

Co-authored by Anusha Kalvala

SCRUM Values: Story from Panchatantra

There lived four friends in a certain town. Though, all of them were young learned Brahmins, one of them was a complete ignorant in matters of learning but had good common-sense. The other three were very learned in matters of the Holy Scriptures, but lacked common-sense.

One day, as the four friends met, they decided, “The scholarship that we have over the Holy Scriptures is no good, if we cannot use it to impress the king, or otherwise to earn money!” 

They decided to travel, in order to earn a living using their learnings. But, the fourth friend was not learned, so they thought of leaving him behind. They agreed, “What good is common-sense? His talents would not help in earning money, so let’s leave him.” 

After much pleading by the fourth Brahmin, the other three decide, “It will not be correct to behave like this to a dear friend, let us take him along. We should also share a part of our earnings with him!” 

As decided, the four started their journey. As they were travelling through a jungle they noticed the bones of a dead lion lying on their way. 

One of them said, “Let us start using our scholarship! We have a dead lion in front of us. Let us test our scholarship, and try to bring it to life!” 

They are Open and transparent in thei decision making.

THEY ARE COMMITTED TO EXERCISE THEIR KNOWLEDGE

While the three Brahmins agreed, the fourth Brahmin did not like the idea. But, his preference was ignored by the other three, and they started theholy rituals.

One of the Brahmins collected the bones of the lion and using his scholarly education, created a skeleton of the lion. 

The second Brahmin used his expertise to cover the skeleton with flesh and skin. 

As the lifeless lion stood in front of them, the third Brahmin initiated the rituals to put life into the lion. 

They are all committed to do their work but  that was foolhardy commitment

The fourth Brahmin was alarmed, “O friends, if the lion comes to life, he will kill us! Please stop what you are doing!” 

The fourth Brahmin was focused on his survival. The other Brahmins were focused to exercise their talent and they were committed to do so.They were courageous to accept the consequence.

The Brahmins ridiculed him, “After reaching so far, are we going to waste our knowledge? You say so, because you are jealous of our scholarship!”

They did not exhibit any respect to their team member.

The fourth Brahmin knew that there was no point in arguing with them. He pleaded, “Please give me a moment. I wish to climb the tree nearby before you infuse life into the lion.” 

He started climbing up a tall l tree, and could see from above the third Brahmin using his scholarship, to put life into the lion. 

As soon as the lion came to life, it noticed the three Brahmins, who were celebrating the successful implementation of their education and talent. 

The lion immediately pounced on them, and killed them. 

The lion was also committed!

The fourth Brahmin could do nothing but wait till the lion had gone. Then, he climbed down the tree and returned home alone. 

Fourth Brahmin demonstrated all the scrum values.

He showed Openness and Courage to challenge their decision, he respected their decision.

He was focused and committed to warn them and save everyone’s life.

The fourth Brahmin is the scrum master, he has shown courage, he was committed and focused to help his fellow team members. But, as they did not show any respect, he could not do much to save them!

If all these team members were trained to understand the scrum values, their life could have been saved.

In the Spirit of Business Agility Transformation

An Agile transformation begins with the proper spirit and understand, and although Agile focuses on teams, that starts from the top.

“We want to be Agile to fulfil the rapidly changing requirements from customers through self-empowered and motivated employees” as opposed to, “We want our team to do Agile since everyone is doing it” is the true spirit of business agility transformation.

The journey begins with leadership

 While agility sounds like a bottom-up philosophy where individuals in the team are self-disciplined and self-empowered in achieving the common objectives, the journey starts with leadership through trust and leading by example. Leadership needs to understand the dynamics of the team and provide guidance since one size doesn’t fit all. Being transparent about the mission and vision is important to gain the shared commitment.

Optimization at all level

It’s a myth that agility is just for product development and support organization. Every individual in the ecosystem plays a vital role in transformation as we can’t expedite the delivery by optimizing silos. Visualizing and eliminating the waste in the value stream that translates an idea to implementation inclusive of process and people are essence for transformation.

Measurement

Both qualitative and quantitative measurements are important to understanding the health of business agility. While the organization can choose metrics that work for them, it is vital to measure throughput and cycle time of business outcomes.

Kaizen(Continuous improvement) and Kaikaku (Radical change)

Measure, refine and repeat — continuous and relentless improvements are important aspects to get better on our journey. The entire value stream requires retrospection in a reasonable timeframe to be able to adjust and move forward.

During the journey of transformation, there are a couple of myths to be considered:

Agile is not ad-hoc

In fact, there is a lot of planning and course correction when we adopt Agile but they are incremental and of short intervals. Since wait time is one of the key wastes, everything requires planning but not in detail just to ensure “roughly right.”

One size doesn’t fit all

In the name of Agile, we shouldn’t force fit the methodologies to a team. While Agile is all about incremental and iterative development, every methodology has its own merits and demerits based on the nature of work. For example, Kanban may work better than Scrum in an environment where scope of work changes daily.

Agile requires more discipline than we think

If a team feels there are too many meetings and ceremonies, it’s time to check the fundamentals. Every ceremony requires the purpose, pre-requisites and expected outcome clearly articulated to the participants. Time-boxing plays a critical role in Agile. Agile empowers everyone with a collaborative approach and taking consensus through working agreements, at the same time it expects every team member to adhere to what they committed to. Being proactive in raising the impediments, limiting the unfinished work through teamwork and self-organized are some foundation blocks for agility.

Beyond traditional leadership

The role of leadership becomes more of an enabler in unblocking impediments as well as bringing alignment within and across teams. The leader becomes frontrunner in transformation journey and guides team through continuous learning and mentorship. The leaders in Agile transformation don’t just show the way, they also travel along with the team, remove the hurdles, and enable teams to be successful.

Summary

To summarise, before the team embarks on an Agile transformation the leaders need to ensure the vision is communicated effectively for better collaboration and continuous support is provided through relentless improvement. We can be Agile without even following the ceremonies; what matters is how we convert the concept to cash for the customers in minimal predictable cycle time. 

Author:

Ramesh Manickavel, Director, Agile Program Management, CA Technologies

Ideal scrum team size, 5 to 7 +/- 2; why?

Free-Rider Problem? Ringelmann Effect

In 1913, Max Ringelmann, a French agricultural engineer, conducted what many believe was the first recorded social psychology experiment.

He carefully measured how much force people exerted when they pulled a rope alone, and when they pulled it with up to thirteen additional people.

He conducted additional studies in the lab and in the field and summarized all these results together.

His results were mind-boggling.

Applying his findings back to the rope experiment, Ringelmann found that when a person was added to the rope, everyone pulled with less strength.

When two people were on the line, they each pulled with 93 percent of the force of a person working alone.

Three people each pulled with 85 percent of the force, and so on.

By the time eight people joined the rope, they were each pulling with half the force of a single person.

As a result, a team of eight pulled the rope with no more total force than a team of seven.

In a set of simple rope pulling experiments he discovered that, in what is now known as the Ringelmann Effect, people’s efforts quickly diminish as team size increases.

Eight people, he found, didn’t even pull as hard as four individuals. He rationalized the decay in effort by suggesting it was difficult for team members to coordinate effort, and left it at that.

The Ringelmann Effect is another name for the dreaded free-rider problem. Free riders are people who try to hide in a crowd and let others do the work.

A summary of seventy-eight free-rider experiments published in the Journal of Personality and Social Psychology validated Ringelmann’s finding—that increasing the size of a group causes a decrease in individual effort.

But the study went a step further and examined the structural elements of cultures that cause free-rider behavior.

According to Ringelmann (1913), groups fail to reach their full potential because various interpersonal processes detracts from the group’s overall proficiency.

Namely, two distinct processes have been identified as potential sources for the reduced productivity of groups: loss of motivation, and coordination problems.

Part of Amazon.com’s behavioral code is the “two-pizza rule”: if a project team can’t be fed by two pizzas, it’s too big.

The rule exemplifies Bezos’s belief that real work should be managed by the smallest teams possible.

It is also a perfect illustration of a hunting party.

Less is more for team !! No body can hide !

Author: 

Chandan Lal Patary

The Agilist’s Guidebook-A Reference for Organizational Agile Transformation | Enterprise Agile Coach