17322084523_7ce372fd98_oDunbar’s number represents a theoretical limit on the number of people in a group that can maintain stable social relationships. Stable social relationships are needed to support application of Agile values, principles and techniques. Dunbar’s number is often quoted as 150 people. However, the limit for any individual group is a not only a reflection limits like Dunbar’s number but also context. If we accept there is some theoretical limit that we can’t scale past such as Dunbar’s number, we need to ask how other project or environmental factors further constrain the maximum number of people working on a problem.  Why go to the trouble of scaling up the number of people working a problem? Many Agilistas would suggest that a single small team is optimal. However, many problems will require a larger collation of teams to deliver value and functionality. Additional contextual drivers that modify the theoretical maximum number of people in a group or a team-of-teams include at least four factors. They are:

  1. Cohesion, or how well people stick together. There are many attributes that can generate cohesion. Examples include: big ideas, goals, nationalities, religions and even corporate identities. Cohesion fosters a common relationship, which helps make groups more willing to put forth effort to achieve an end. For example, it often is hard to achieve a cohesive group when members come from multiple external consultancies. Each organization involved in the group have a different set of organizational goals that will reduce cohesion unless they are subjugated to the project goal.  Reducing the number of people below Dunbar’s number makes the use of techniques like peer pressure to institutionalize a project vision to increase cohesion easier.
  2. Complexity is a measure of the number of properties for a project that are outside of the norm. The complexity of a problem reduces the optimal maximum number of people that can be bear because complexity generally requires either more control and coordination or alternately smaller teams to ensure collaboration.
  3. Uncertainty occurs when teams are searching for an answer to a business or technical problem. When a team needs to tackle an unknown business problem or new technology research is often required. Research generally is constrained to small teams with specialized skills reducing the optimal maximum group size for this type of endeavor well below Dunbar’s number. As concepts and ideas are discovered they can be rolled out more broadly to be fleshed out, prototyped and implemented increasing the group working on the project closer to Dunbar’s number.
  4. Dependencies between components often mean that work needs to be single threaded (or at least spread less broadly). Dependencies reduce the number of people or teams that can be effectively leveraged.

The idea of increasing the number of people and teams working on a project often appears to be a mechanism for delivering value more quickly. When adding people to is suggested remember the number of people working on a problem is a constraint than can not be dealt with by linearly increasing the number of people applied to a problem until you reach a limit such as Dunbar’s number.  Context directly impacts how large any group can before overhead and other constraints reduce effectiveness.    It is often said that you can’t get nine women to have a baby in a month. In addition to Dunbar’s number, context plays an important role in defining overall team size.

How many people is too many?

How many people is too many?

When determining how large an Agile program can be, one of the oft quoted “facts” is that the number of people involved in an Agile program is governed by Dunbar’s number. Dunbar’s number is the limit of the number of people in a group that can maintain stable social relationships. The term, social relationship is a reflection of regular interactions, the ability to recognize another member as part of the group or are committed to a common goal. These attributes are important to any project and are perhaps more important in Agile projects because they rely on team cohesion to minimize bureaucracy and control mechanisms.

The concept of Dunbar’s number is based on research originally performed through the observations of primates and then extended to humans in the early 1990’s. In June of 1992, Robin Dunbar  published “Neocortex size as a constraint on group size in primates” in the Journal of Human Evolution (Volume 22, Issue 6, June 1992, Pages 469–493). In the paper Dunbar noted a correlation between the size of a primate brain and the average social group size. From the abstract, Dunbar wrote:

Group size is found to be a function of relative neocortical volume, but the ecological variables are not. This is interpreted as evidence in favour of the social intellect theory and against the ecological theories. It is suggested that the number of neocortical neurons limits the organism’s information-processing capacity and that this then limits the number of relationships that an individual can monitor simultaneously. When a group’s size exceeds this limit, it becomes unstable and begins to fragment. This then places an upper limit on the size of groups which any given species can maintain as cohesive social units through time.

While group size of 150 is often quoted as Dunbar’s number, 150 is an approximation. As noted in the “Limits of Friendship” by Maria Konnikova (October 7, 2014) Dunbar’s number can range from 100 – 200 (ish) people based on factors such a social gregariousness. Other limits of group size have also been published for example Drs. Peter Killworth and Russell Bernard have published numbers in excess of 200 people.

Based on Dunbar’s number, the Scaled Agile Framework Enterprise (SAFe) suggests that the largest Agile release train (ART) should include approximately 150 people. The ART is supported by a framework (SAFe), hierarchy (release train engineer and Scrum masters) and bureaucracy (product management and product owners). Agile being practiced by a single team of 5 – 9 people would not require this degree of overhead to ensure coordination.

Scaling agile is a balancing act between the efficiency of team-level Agile techniques and the concessions made to control when Agile is scaled up to deal with larger efforts. Historically, very large projects tend to be less efficient. Capers Jones in Applied Software Measurement, Third Edition[1] (p295) indicates that productivity falls for all types of projects as they exceed 1,000 function point points. Function points are an ISO standard method of measuring software size based on a standard set of rules. Simply put the larger a project is in function points the larger the team (or team of teams) needed to deliver the project which yields the need for more control processes all other things being equal. He further makes the point (p 307) that as project size increases, so does the probability of cancellation.

Scaling Agile leverages many of the techniques used by team-level Agile, such as small team size, small batch sizes and Scrum. These techniques are are very lean but are perceived limit the amount of value that can be delivered within a specific period of time. As Agile projects grow in size additional techniques are needed to maintain control. Dunbar’s number (or similar ideas) provides a limit to try to avoid letting a piece of work become too large to manage. The number act as limit to the number of people involved in a piece of work. Applying additional constraints, such as releases or SAFe’s program increment, add a dimension of time as constraint. The combination of constraints on the number of people and the how long those people will be working provide an explicit constraint on how much work can be delivered.

1 Applied Software Measurement, Third Edition, T. Capers Jones, McGraw Hill, 2008

Listen Now

Subscribe on iTunes

Software Process and Measurement Cast 342 features our interview with Ellen Gottesdiener and Mary Gorman.  We discussed their great book, Discover to Deliver: Agile Product Planning and Analysis, requirements and Agile.  Ellen and Mary provided penetrating insight into how to work with requirements in an Agile environment, from discovery to delivery and beyond.

This is the second time Ellen, Mary and I talked Agile requirements.  After listening to this interview turn back the hands of time and listen to SPaMCAST 200.

Ellen Gottesdiener is an internationally recognized leader in the convergence of agile + requirements + product management + project management. She is founder and principal of EBG Consulting, which helps organizations adapt how they collaborate to improve business outcomes.

Ellen’s passion is helping people use modern product requirements practices to build valued products and great teams. She provides coaching, training, and facilitates discovery and planning workshops across diverse industries. Ellen is a world-renowned writer, speaker, and presenter. Her most recent book, co-authored with Mary Gorman, is Discover to Deliver: Agile Product Planning and Analysis. Ellen is author of two other acclaimed books: Requirements by Collaboration and The Software Requirements Memory Jogger.

Here’s where you digitally connect with Ellen: Blog | Twitter | Newsletter | LinkedIn

Mary Gorman, a leader in business analysis and requirements, is Vice President of Quality & Delivery at EBG Consulting. Mary coaches product teams, facilitates discovery workshops, and trains stakeholders in collaborative practices essential for defining high-value products. She speaks and writes for the agile, business analysis, and project management communities. Mary is co-author with Ellen Gottesdiener of Discover to Deliver: Agile Product Planning and Analysis.   

A Certified Business Analysis Professional, Mary helped develop the IIBA®’s A Guide to the Business Analysis Body of Knowledge® and certification exam. She also served on the task force that created the PMI Professional in Business Analysis (PMI-PBA)® Examination Content Outline. You can reach Mary via: Twitter | LinkedIn

Call to action!

Reviews of the podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Next up on Re-Read Saturday: The Mythical Man-Month

Get a copy now and start reading!

Upcoming Events

2015 PROFESSIONAL DEVELOPMENT & TRAINING WORKSHOP
June 9 – 12
San Diego, California
http://www.iceaaonline.com/2519-2/
I will be speaking on June 10.  My presnetaiton is titled “Agile Estimation Using Functional Metrics.”

Let me know if you are attending!

Also upcoming conferences I will be involved in include and SQTM in September, BIFPUG in November. More on these great conferences next week.

Next SPaMCast

The next Software Process and Measurement Cast will feature our essay on Commitment, Part 2. Is commitment anti-Agile?  We think not!  Commitment is a core behavior for effective Agile!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

IMG_1249

This week I attended and spoke at the CMMI Global Congress. It was a great conference, and as with most conferences, the conversations in the hallways were as interesting as the presentations (including mine). I had a lot conversations about lean, Agile and scaling Agile, and while the attendees as a whole saw the value, there are still a few that view Agile and lean concepts with derision. These conversations, in conjunction with today’s re-read segment of The Goal, led me to consider whether much of the underlying resistance was being generated by fear; in particular the fear of discovering that what you know is no longer relevant. People facing that fear generally react in one of two ways: reinvention or rejection. In today’s segment Hilton Smyth chooses one of those options. . .

Part 1       Part 2       Part 3      Part 4      Part 5      Part 6      Part 7      Part 8    Part 9   Part 10   Part 11 Part 12

Chapter 31 Alex appears for the plant review, which is being chaired not by Bill Peach (Alex’s boss) but rather Hilton Smyth. Hilton is the assistant division controller. When Alex suggests that they wait for Bill Peach, Hilton indicates that he will not be coming and that his (Hilton’s) report will tip the scales on whether the plant stays open or not. The early exchanges clearly establish that Hilton does not buy into the turn around that Alex and his team have engineered. Alex reiterates the three core findings that have driven the turn around.

  1. Instead of balancing capacity with demand, they are focused on maintaining and improving the flow through the plant.
  2. For resources that are not bottlenecks, the level of activity from which the system is able to profit is not determined by individual capacity, but rather by some other constraint.
  3. Utilization and activation are not the same.

Hilton believes that Alex’s deviations from the tried and true formulas for batch size, capacity utilization and per unit costing are hiding problems that will cripple the plant in the future. Those tried and true formulas are central to Hilton’s perception of his own relevance, and he can’t see that with both profits and plant throughput up and inventory down that the plant is now on very solid footing. The report to Peach will be bad.

After the meeting, Alex decides to confront Peach. Peach listens as Alex tells him that Smyth would not listen to reason. Peach summons Jons (head of sales), Ethan Frost (division controller and Smyth’s boss) and Smyth. When they are assembled, Peach announces that Jons, Frost and himself have been promoted, and that Alex will also be promoted to head the division. While unstated in the book the inference is that recent profitability and the new orders from Bucky Burnside have made quite the stir at corporate. (In my head I could hear Smyth blustering, as much of his previous knowledge and experience became less relevant).

The chapter ends with Alex reaching out to Jonah to ask for help running the division. What he receives is a congratulation and advice to learn to trust his own judgement rather than to needing outside support.

Chapter 32 uses Alex’s and Julie’s celebration dinner as a backdrop for a discussion about the promotion as part of a journey and Johan’s method of coaching. Johan didn’t just provide answers to the questions Alex posed, but rather pushed Alex  in the right direction and made him and his team work for the answers, much like the Socratic method of generating critical thinking based on asking and answering questions.  This journey helped Alex generate ownership in new concepts that flew in the face of what he and his team previously thought to be true. The struggle to generate answers gave Alex and his team the courage to implement their new ideas. It should be noted that the feedback that their early successes generated also helped generate the courage to try further experiments (this dovetails nicely to the ideas in Kotter’s Leading Change – an earlier re-read).

Remember that the summary of previous entries in the re-read of The Goal have been shifted to a new page (click here).   Also, if you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast. Dead Tree Version or Kindle Version

Many of us have a cognitive bias toward eating scorpions!

Many of us have a cognitive bias toward eating scorpions!

Cognitive biases are patterns of behavior that reflect a deviation in judgment that occurs under particular situations. The phrase cognitive bias was introduced by Amos Tversky and Daniel Kahneman in 1972. Biases can affect how information is perceived, how teams and individuals behave and even our perception of ourselves. Biases are a part of nearly every human interaction, so we need to understand the potential biases that are in play if we are going to help teams grow and evolve.

Project teams make decisions on continuous basis. Most decisions are made based on how the decision maker perceives the information he or she has at hand. One bias that can affect how information is perceived is the illusory correlation. The illusory correlation is the perception of a relationship between two or more variables when no relationship exists. An example would be that a team that works more hours a week has higher productivity because working longer gives the perception of creating more output. The perception of a relationship causes you to pay less attention to other factors, such as the higher level of effort they are expending. There are numerous biases that affect how information is perceived, and these biases can impact the outcome of decisions or even whether we make needed decisions at all.

Biases can affect behavior. Neglect of probability is a type of cognitive bias common in IT organizations that are planning and estimating projects or in risk management. For example, most estimates should be represented as a range based on probability. Techniques like Monte Carlo analysis can be used to generate a range of probability based estimates to address type of bias.However, almost all estimates are represented as a single number and regardless of all the caveats attached, and the continuum of probability is ignored. Lottery ticket sales are another reflection of the neglect of probability bias; buying one or 10 doesn’t materially affect the probability of winning, but that does not stop those who think buying ten tickets increases their chances of winning. In both cases neglecting probability affects how we behave and make decisions.

Biases can affect our motivation. For example, a self-serving attributional bias, occurs when success is attributed to internal factors and failures are attributed to external factors. This type of bias can occur at an individual level or at the team level. While self-serving bias can improve self-esteem (or a team self-esteem) it can also cloud judgment by causing an overestimation of capability. For example, if a team is able to deliver more than their long-term productivity or velocity would predict, the team might then perceive that they have increased their capability to deliver. If no fundamental changes have occurred such as an infusion of knowledge, training or new tools, the higher velocity may not be attributable to the team. A good coach will help teams examine these types of biases during retrospectives.

Bias are powerful psychological filters that affect how both individuals and teams perceive the world around them and then how they behave. Biases reflect shortcuts in how we interpret and react to stimuli. In many cases these reactions are valuable; however they can also cause problems (as many shortcuts can). Understanding how biases impact how individuals and teams perceive the world around them can help team make better decisions and therefore deliver value more effectively.

10390127_10152452543289484_3916202870628506345_n

No methodology or framework is 100% perfect, like weather prediction.

Agile was born as a synthesis of many minds and many frameworks. That synthesis yielded a single philosophy; however since each person and framework brought a perspective to the table that philosophy has been implemented as a wide variety of methodologies and frameworks. No methodology or framework is 100% perfect for every piece of work. Perfect is binary – when the answer to is that a specific framework isn’t a perfect fit, organizations need to either find another approach or to tailor the approach to make it fit. Scaling is a form of tailoring. Process frameworks always have recognized the need to tailor the process to meet the needs of organization and teams doing the work. For example, even the venerable CMMI, often lambasted for generating heavy or static processes, actually includes practices for tailoring across the model and the process created to implement the mode. In Agile scaling often requires tailoring the processes used at the team levels to support larger efforts. While all sorts of factors can drive the need to scale or tailor Agile frameworks, typically the size of the work is the single most critical driver. Other typical attributes that combine with size and affect how scaling is approached include complexity, risk and organizational politics.

Size of an effort is influenced by the amount functional, non-functional or technical requirements required to solve a specific problem. How related or integrated those requirements are will affect how work is organized, and therefore the number of teams required to deliver the work. A large, highly-related effort will required coordination, which will require added processes such as a Scrum-of-Scrum meetings or other forms of program management.

Complexity is is made up of a huge number of attributes that include (but is not limited to) how difficult the technical problem will be to solve, whether the team has ever used the technology before, how many disciplines will be involved in solving the problem and size. Complexity directly relates to how difficult the work will be to deliver. All things being equal, the more complex the more effort will be required. The larger the effort or the more disciplines needed to deliver the project typical means more teams and more coordination. More effort, more disciplines or more people leads to a need for techniques to scale team-level Agile.

Risk is reflection of uncertainty. Any event that could have a negative (or positive) impact that the team or organization can’t predict is risk. A risk that can have a significant impact on work or the organization as a whole needs to be monitored and managed. Risk management techniques are commonly added to scale Agile frameworks.

Organizational politics might be considered specialized type of complexity. Typically organization politics generates higher need for oversight and reporting in advance of typical team-level Agile techniques. The added organizational requirements that are required generate the need to add steps, processes and reviews, which will require scaling basic team-level Agile.

Not all projects are exactly the same. This is why we need to scale team-level. Team-level Agile smoothes some of the required process differences out through the use of techniques such as time boxes and user story grooming.  However despite of these techniques, variability of work effort (examples of work efforts include projects, programs, release or products) are not all the same. Size, complexity, risk and organizational politics generate a need to add steps and processes on top of team-level Agile to scale up to meet the needs of larger, more complexity or riskier work.

Listen Now

Subscribe on iTunes

Software Process and Measurement Cast 341 features our essay titled Agile Team Decision Making. Team-based decision-making requires mechanisms and prerequisites for creating consensus among team members. The prerequisites are a decision to be made, trust, knowledge and the tools to make a decision. No one should assume that that team members have the required tools and techniques in their arsenal to effectively make decisions.

Remember:

Jo Ann Sweeney, author of the Explaining Change column, is running her annual Worth Working Summit.  Please visit http://www.worthworkingsummit.com/

Call to action!

Reviews of the Podcast help to attract new listeners.  Can you write a review of the Software Process and Measurement Cast and post it on the podcatcher of your choice?  Whether you listen on ITunes or any other podcatcher, a review will help to grow the podcast!  Thank you in advance!

Re-Read Saturday News

The Re-Read Saturday focus on Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement began on February 21nd. The Goal has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. Visit the Software Process and Measurement Blog and catch up on the re-read.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

I am beginning to think of which book will be next. Do you have any ideas?

Upcoming Events

CMMI Institute Global Congress
May 12-13 Seattle, WA, USA
My topic – Agile Risk Management
http://cmmiconferences.com/

DCG will also have a booth!

Also upcoming conferences I will be involved in include ICEAA in June and SQTM in September. More on these great conferences next week.

Next SPaMCast

The next Software Process and Measurement Cast will feature our interview with Ellen Gottesdiener and Mary Gorman.  We discussed their great book, Discover to Deliver, requirements and Agile.  Ellen and Mary are provided penetrating insight into how to work with requirements in an Agile environment from discovery to delivery and beyond.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Follow

Get every new post delivered to your Inbox.

Join 4,352 other followers