Get certified - Transform your world of work today


From the LeSS Toolbox: Causal Loop Diagrams to Visualize System Dynamics

13 July 2016


When it comes to scaling, there is a common misbelief that “bigger always means better.” This misbelief is also traceable to the Agile arena, where companies look for ways to expand their Agile practices beyond a single organizational domain (e.g., many teams, numerous departments, multiple lines of business, etc.). Usually, it is an existing (inherited) organizational complexity that becomes the main reason why companies look for complex, multi-tiered scaling solutions. And, of course, if there is a demand, there will be a supply: A number of frameworks are out there that hand-hold companies to comfortably “embrace” their existing complexity and not feel too uncomfortable about their own internal dysfunctions.

However, not all scaling solutions are as “forgiving.” There are some Agile frameworks that intentionally expose and boldly challenge organizational deficiencies. One such framework is Large-Scale Scrum (LeSS). In order to set a stage for the rest of this discussion, I would like to summarize a few points about LeSS here.

I also would like to express my appreciation and acknowledgment to Craig Larman (one of the cofounders of LeSS) for helping me deepen and broaden my understanding of organizational design and improve my system thinking, which I have been developing over years.

Overview of LeSS

LeSS is a very easy to understand. I like to speak metaphorically, so in describing LeSS, I sometimes use the analogy of the legendary assault rifle AK-47, which has the following well-known characteristics:
  • It has very few moving parts and, therefore, its internal friction is pretty low; also, there are not too many small pieces that can jam or break.
  • It is simple to disassemble, inspect, and reassemble (inspection and adaptation).
  • It is very reliable and adaptable under tough conditions (it rarely fails in action).
  • If necessary, it can be modified and “expanded” at low cost and/or with low effort.
But there is something else about LeSS that makes its analogy to a weapon (probably not just to an AK) appropriate: It assaults organizational dysfunctions.

LeSS also has two important characteristics:
  1. It is very simple in design and rests fully on the core principles of basic Scrum (effectively, LeSS is the same as Scrum, as it is described in Scrum Guide, but performed by multiple teams).
  2. LeSS teachings rest on the pillars of:
    • Lean Thinking: “Watching the baton, not the runner,” visual management, cadence, timeboxing, managers being teachers, continuous improvement
    • Systems Thinking: Weinberg-Brooks’ Law, queueing theory, indirect benefits of managing batch size and cycle time, being customer-centric, explaining differences between local and system optimization
Thanks to these two key characteristics, LeSS is a very powerful mechanism that helps see an organization systemically/holistically, while identifying and exposing (the analogy to a high-power rifle scope is suitable here) the pain points that need to be addressed.

As a framework, LeSS is lean and transparent. It does not have any “secret pockets” or “special compartments” where organizational problems can find a safe haven. No dysfunctions escape the sharp focus of LeSS: ineffectively applied processes or tools, ill-defined roles and responsibilities, unhealthy elements of organizational culture and other outdated norms — all of these are vividly exposed when using LeSS. Interestingly, while LeSS is a scaling framework that allows us to scale up (roll up) efforts made by multiple Scrum teams, it first requires organizational de-scaling. The phrase I often use here is: “You can get more with LeSS.” To put it another way, in order to build up Scrum effectively, an organization must remove whatever extra/unnecessary muda (waste) it has already accumulated that gets in the way of scaling Scrum. It is almost like this: LeSS prefers a thin but very strong foundational layer over a thick and convoluted but unstable foundational layer; the latter is usually a characteristic of an orthodox, archaic organizational design.

Another metaphor that I use to describe LeSS is that it is an organizational design mirror. By adopting LeSS, an organization sees its own reflection and decides, depending on its strategic goals and appetite for change, on necessary improvements. Similarly, to a person who takes personal fitness training seriously and uses a mirror for “course correction,” an organization may use LeSS to decide whether any further reshaping or “trimming” is required to get to the next maturity level.

LeSS is also a great guide to technical excellence. I have used LeSS teachings extensively to coach the importance of continuous integration, continuous delivery, clean code, unit testing, architecture and design, and test automation as well as some other techniques that make Agile development so great. LeSS stresses that mature engineering practices are paramount for effective adoption of Agile across multiple organizational domains, not just IT.


So, how can an organization take advantage of both — the simplicity of the LeSS construct, on one hand, and its deep systemic views, on the other hand — to improve its organizational agility beyond a single team? How can the principles of Lean and systems thinking (together, and along with understanding “beyond-first-order” system dynamics) be leveraged to implement true Scrum without reducing, minimizing, or downplaying the importance of its core values and principles?

As an organizational and Agile coach and someone who has been using LeSS extensively in his daily coaching work, I frequently witness situations when companies have to deal with this serious dilemma. Here I want to share the magic “glue” that helps me bring my thoughts together and deliver them to my clients. This “glue” is one of the most effective tools that I have discovered for myself inside the LeSS toolbox. It is called Causal Loop Diagrams (CLD).

CLDs provide a great way to graphically illustrate cause-and-effect relationships between various elements of an organizational ecosystem. CLDs help me effectively uncover second- and third-order system dynamics that may not be as apparent to the naked eye as first-order dynamics. CLDs help me brainstorm complex organizational puzzles and conduct deep analysis of system challenges. Ultimately, I have found that CLDs are highly useful in communicating ideas to my customers, particularly to senior leadership.

Here are some elements of CLDs that I use in my graphics:
  • Goals — A high, overarching/strategic goal that needs to be achieved
  • Variables — System elements that have an effect or influence on other system elements (other variables)
  • Causal links — Arrows that connect two related variables
  • Opposite effects — “O” annotation near an arrow; suggests that the effect of one variable on another is the opposite of what could be expected
  • Delayed effect — “||” annotation that disrupts a causal link (arrow); it implies that there is a delayed effect of one variable by another variable
  • Extreme effects — One variable has an extreme (beyond normal) effect on another variable; it is represented by a thick arrow
  • Constraints — “C” annotation near arrow; implies that there is a constraint on a variable
  • Quick-fix reactions — “QF” annotation near an arrow; action that brings about short-term, lower-cost effect
At this point, I would like to provide an example of using CLDs to visually illustrate second- and third-order dynamics between key system variables that I often see causing harm and unrest to organizations: performance-driven, discretionary monetary incentives.

I would like to follow through the process of interaction between system variables as they come to play with one another and uncover the impact they have on the overall system.

Every year, a company (hypothetical Company X) has to distribute a large sum of money to many of its employees in the form of discretionary bonuses. In order to make the decision-making process less subjective, a company ties it to the employees’ individual performances via reviews and appraisals. People who have demonstrated better performance get more money; people who have demonstrated poorer performance get less (or nothing). This requires that every employee be evaluated by her line manager, usually twice every year, at which time the employee gets some rough idea about “how much she is worth as resource.” This serves as a guide to how much discretionary money the employee might expect to get as a bonus. While on its surface the process of performance evaluations and appraisals may seem to be more objective than a line manager simply deciding on his own, it is still very subjective in that the employee’s opinion is disregarded when making decisions. Furthermore, the process is harmful and causes deterioration of individuals’ morale and relationships, on multiple fronts. The undesirable effects and short-/long-term damage of performance evaluations and appraisals have been studied for years; lots of research and statistical data is available today. If you are not familiar with this topic or would like additional background information to deepen your understanding, you may refer to the following resources, prior to proceeding with reading: Moving along with this discussion, I would like to highlight the following three downstream “system variables” that are directly (first-order dynamics) impacted by individual performance reviews. This type of system variables integration is mainly observed among technology groups. Once we understand first-order dynamics, we will proceed to some other downstream (“beyond first order”) variables.

Employee happiness factor

Many research studies have proved that employees don’t like to be appraised. An appraisal is equivocal to slapping a price tag on someone and is hardly an objective process, as the only opinion that really matters is that of a line manager. Yet the official story at almost any company is that an appraisal helps an employee grow and mature professionally and offers a way to improve her individual performance toward some arbitrarily set target. Truth be told: Were the intent of appraisals to help employees grow and continuously improve, the process would not be implemented once or twice a year but rather more frequently, in ways that would allow an employee to make a necessary course correction more iteratively. After all, why wait for six months to tell a worker that she needs to improve?

At the time of appraisal, a manager delivers to an employee her final and practically undisputable decision. An employee has practically no effective way to challenge or dispute such decision. Frequently, even a line manager does not have control of the process (although this is rarely admitted): He or she is presented with a fixed “bag of cash,” coming from management above, and this bag somehow has to be distributed among lower-ranking workers. And just to be fair to line managers who are not delusional about the dysfunction they have to entertain, most of them also dislike the process, as it makes them resented by the employees they manage.

So, as time goes by, employees become less and less pleased with evaluations and appraisals. The impact may not be observed immediately, due to the fact that it usually takes time for an employee to mentally mature to the point where she begins to comprehend the unfairness of the process. (Of course, exceptions exist among people who have longer experience of dealing with this process and understand its ineffectiveness and harm.)

While leveraging CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

This graphic suggests that annual appraisals have a delayed and even opposite effect on employees’ happiness.

Peer-to-peer support

Peer-to-peer support, willingness to share knowledge with colleagues, collective ownership of assignments, and shared responsibility for deliverables — these are the hallmarks not only of feature teams’ dynamics but of any Agile environment. In order for employees to be mutually supportive, they must operate in a noncompetitive environment, where they don’t view each other as competitors or rivals. This is practically impossible to achieve when every employee perceives another employee (at least within the salary tier) as a competing bonus collector. And this is exactly what is observed in environments where bonuses are distributed based on individual performance: Employees compete for the same limited pool of cash. But everyone cannot be a winner. Even in a group of the brightest individuals working together, someone within that group would have to be ranked higher and someone else lower (and note that this is frequently explained to people up front). How could we expect people to be supportive of each other if, effectively, underperformance of one employee and her inability to collect extra money increases the chances of another employee to bring home more cash? Performance appraisals and discretionary moneys drive employees apart, not together.

Again, the adverse results of appraisals may not be immediate: pain points become more obvious after bonuses are actually paid (end of year/early next year) — this is when employees start developing resentment and jealousy toward each other over paid bonuses.

While leveraging CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

This graphic suggests that annual appraisals have a delayed and opposite effect on peer-to-peer support.

Both variables above directly define employees’ intrinsic motivation to work and their willingness to stay with a company. After all, can we expect that an unhappy employee, while being in constant competition with his peers and being deprived of an opportunity to safely experiment, would want to dedicate himself to that company for a long time? Probably not. As a result, employee retention should not be expected to be high. As has often been seen, good employees always leave first.

While leveraging CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

This graphic suggests that both employees’ happiness and their willingness to support each other are directly related to their intrinsic motivation to work and willingness to stay with a company; and, as a downstream effect, this increases employee retention. The opposite would be true as well: Lowering values of upstream (left-side) variables will lower values of downstream (right-side) variables.

“Environmental safety” and the desire to experiment

Innovation and experimentation are paramount for success in software development. This is what drives feature teams toward improvement. Scrum, for example, requires continuous inspection and adoption. It is expected that, while experimenting, feature/Scrum teams may run into roadblocks or have short-term failures, at which point they will learn and improve. But in order to be willing to experiment and take chances, teams need to be sure that they are safe to do so. In other words, they need to be sure that they will not be judged and scrutinized for their interim failures. Such “environmental safety” will be always jeopardized by individual performance appraisals. Why? Because individual success (high individual performance) of an employee is defined by her ability to precisely meet individual goals, set in stone early on during the year. The need to follow a “script” precisely kills any desire of an employee to experiment. After all, why would a person want to take any chances if her failures will be perceived by line management as underperformance?

Since appraisals make working environments unsafe and kill individuals’ desire to experiment, as soon as an employee is presented with her annual goals, she reacts self-protectively, by starting to “work to the script” and trying to document every personal achievement “for the record” (a.k.a. “CYA”).

While leveraging CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

This graphic suggests that when employees are safe and are not afraid to experiment, innovation and experiments take place in a workplace. Inversely, lack of safety in a work place and absence of desire for experimentation reduces chances of innovation and improvement.

In the sections below, I would like to take a closer look at system dynamics that are beyond the first order of interaction, by tracing some additional downstream system variables.

Team synergy and stability

In Scrum, we would like our teams to be stable and long-lived. We would like to see team members enjoy being a part of the same team, and doing so as happy volunteers, not as prisoners constantly looking for opportunities to escape. In fact, the best feature teams known have been created as a result of voluntary self-organization, not as a result of a managerial mandate.

Why do we want our Scrum/feature teams to remain stable? Here are some good reasons — they give rise to:
  • A collaborative environment and a desire to work together
  • Shared domain expertise and cross-pollination with technical knowledge
  • Predictable team velocity and the ability to plan/forecast more accurately
So how do performance evaluations and appraisals impact team synergy and stability? Here is how this happens, indirectly:

Via low employee retention. As employees leave a company, feature teams disintegrate. This brings together new team members that have never worked together and require time before they can “form, norm, and storm.” As feature teams get dis- and reassembled, velocities drop/become less reliable and system variability increases (estimation becomes less accurate). The effect is usually immediate. In my personal experience, I have seen many feature teams breaking loose and falling apart shortly after companies have announced annual bonuses.

While leveraging CLDs in my discussions with senior management, I use the following graphic representation to convey the concept:

This graphic suggests that high employee retention will lead to elevated team synergy and stability. Inversely, low employee retention in a workplace lowers teams’ synergy and stability.

Via high internal competition and rivalry. Once employees realize that they have to compete with their own teammates for discretionary dollars, collaboration deteriorates dramatically. Individuals stop supporting each other in pursuit of common goals. Instead, everyone strives to be a superhero and solitary performer, trying to demonstrate his or her own efficiency and hyperproductivity to a manager. Everyone wants to look better than other peers and teammates. The race to demonstrate the best individual performance has a high cost: It happens at the expense of overall team performance. Since collaboration, swarming, and shared ownership of work are critical for healthy Scrum, the obvious downstream effect of performance evaluations and appraisals becomes clearer: lowered team synergy and instability.

While leveraging CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

This graphic suggests that internal competition and rivalry will have an extreme and opposite effect on team synergy and stability.

Healthy Scrum dynamics

There are many known system variables that interact with one another and define effectiveness of basic Scrum. Assuming that most readers of this article are familiar with Scrum, and in order to keep my focus on other important downstream system variables, I am going to leave out detailed discussions of basic Scrum dynamics. It will suffice to mention that the following classic Scrum-specific variables always have to be considered: feature velocity, number of defects, dollar rate at which developers are hired (low vs. common), number of low-skill developers, cash supply, ability to guide and improve the system, etc. If the reader is interested in exploring this in depth, the “Seeing System Dynamics: Causal Loop Diagrams” section of describes these system dynamics, with the use of CLDs.

However, when leveraging CLDs in my discussions with senior management, I still use the following generalizing graphic representation and annotation to convey this commonsense, overarching concept:

This graphic suggests that team synergy and stability lead to healthy Scrum dynamics and a feedback loop that is positive (value increase on the left leads to value increase on the right). In my experience, the effect is sometimes delayed. A time lag is usually due to previously gained momentum.

So far we have used CLDs to explore system dynamics that primarily impact technology teams. At this point, I would like to shift my focus to the business side of the house and explore the part of system dynamics that involves customers. In particular, I would like to provide some examples of how CLDs can expose the adverse impact of individual performance appraisals and discretionary monetary incentives on product ownership in Scrum.

Identification of a GREAT product owner

Finding a good candidate for the role of product owner is one of the most challenging tasks in Scrum. Why?

The role of product owner combines certain characteristics that are not easily found within the same individual, and it is organizations of high organizational complexity and Taylorian culture where this challenge is seen most. On one hand, the product owner is expected to have enough seniority and empowerment to make key strategic business decisions. On the other hand, the product owner is expected to get intimately involved in day-to-day, and sometimes hour-by-hour, interaction with technology groups. When these two sets of characteristics come together in the same person, we hit a jackpot: We get a great product owner — a person who is both empowered and engaged. But truth be told, it is often challenging to identify a person who possesses both of these traits. In most Orange organizations (the predominant color of most modern corporations, as per the Laloux Culture Model), the definition of every job includes a fixed set of responsibilities that individuals are obligated to fulfill. If we look at most job descriptions, as they are defined by HR departments of Orange companies, we will hardly ever see a job spec that has ”slack time” for a person to take on the responsibilities of a product owner in addition to his primary job, let alone a job spec that is fully dedicated to the role of PO. For most organizations, the product owner role is still not well defined and, as such, it is not perceived by employees as a step toward career advancement. Today, many organizations that use Scrum have to experiment with the role of the PO by looking for the right individuals internally. Individuals who step up for the role of product owner have to make a conscious decision, with full acknowledgment that they will be taking on a very wide spectrum of new responsibilities. For most people, this is risky because it effectively means that attention and focus on primary activities (as per job specs) will be diluted by secondary activities — fulfilling the role of PO. Of course, this problem could be easily mitigated with full backing and support from senior leadership and HR, by redefining job specs and explicitly recognizing the criticality of the product owner role. But it hardly ever happens (mostly at product development companies, if there).

It is hard to argue that people have to be recognized for the work that they do. I doubt that anyone would object to the following statement: Nobody should be working two jobs for the same paycheck. People have to “feel safe” about stepping into a new territory, learning new activities, and developing work dynamics that they have not experienced before. This brings us to the same concept that we discussed earlier, when we looked at technology groups: Individuals need to feel safe in order to be willing to experiment with a new role. It would be unreasonable to expect an employee to take on more work that would not be “counted in” when a person gets evaluated for his contribution to an organization.

So, again, while leveraging CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

As the graphic suggests, when employees are safe and are not afraid to experiment, it will be less difficult to identify a good product owner. Inversely, the opposite is true as well: Lack of safety and inability to experiment makes the process of PO selection much more challenging.

At this point, it is worth mentioning one very common quick fix that organizations frequently make to compensate for shortcomings in finding a good product owner.

Empowerment usually implies that a person occupies a senior organizational position. As such, a business person’s career has progressed beyond a certain point; she no longer has enough bandwidth (nor desire!) to deal directly with technology. On reaching a certain level of seniority, a person has “bigger fish to fry,” and collaborating with individual technology (feature) teams is no longer her priority. So, while still retaining one of the “E's” (empowered), a person is not able to demonstrate another “E” (engaged). In order to compensate for the missing “E,” another person needs to be inserted into the system to fill in the gap between a real product owner and the technology teams. This poorly defined (even undefined) role is sometimes labeled “PO proxy” — a surrogate person tries to act as the PO but does not have the power. This role is usually occupied by someone from a lower organizational layer: a business analyst, system analyst, or another person more accustomed to working directly with technology and for whom the activity itself is not perceived as “below pay grid” This creates a serious dysfunction in the Scrum operating model, as communication between a true customer (empowered PO) and technology is now hindered: The surrogate role of PO proxy usually lacks strategic/holistic product vision and any power to make important business decisions within short time frames, as it is required by Scrum. It is worth noting that the functional expertise of a business analyst or systems analyst are both welcomed in Scrum and usually reside within teams (although single-specialty individuals are viewed as less valuable than multiskilled, a.k.a. T-shaped individuals). The reason the delegation of responsibilities described above is problematic is because it artificially creates unnecessary communication layers between end customers and technology. This type of organizational design causes a variety of additional dysfunctions (miscommunication, hindrance to information flow, confusion of priorities, etc.), and therefore is strongly discouraged.

While leveraging CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

As the graphic suggests, the difficulty in identifying a good candidate for the role of PO creates the need to look for quicker and cheaper solutions; introducing a powerless surrogate role of the PO proxy is a commonly seen but undesirable Plan B. The reason this fix is “quick” is because it usually does not take too long for a real PO to realize that he/she is not able (or willing) to handle the additional responsibilities of the role. In my practice, the risk of losing a real product owner and getting a proxy instead did not take too long to materialize: usually a few weeks after Scrum was introduced.

Effectiveness of product backlog management

Effective product backlog management is paramount in Agile product development. This fundamental concept has been introduced in simple Scrum, and it remains as valid in scaled Scrum. In fact, when an organization scales its Scrum, by involving multiple technology teams, POs, and lines of business, effective product backlog management becomes even more critical: Work coordination, resource management, impediment removal, alignment of business priorities, etc., are all part of the package.

As we can guess, effective product backlog management, including work prioritization, story decomposition, etc., can be done most effectively with participation of a real product owner. And conversely, if an organization is missing the critical figure of the product owner, product backlog management will become ineffective.

While leveraging CLDs in my discussions with senior management, I use the following two graphic representations and annotations to convey these two related concepts:

As the graphic suggests, product backlog management suffers from both: lack of true product ownership and presence of ineffective surrogate roles. In my personal experience, the effect is usually extreme.

Healthy Scrum dynamics (overall)

At this point, I usually provide senior managers with a partial summary of LCD by showing how “healthy Scrum dynamics,” while sitting much further downstream from individual performance evaluations, appraisals, and bonuses, are still impacted by the latter group via second-order dynamics (through secondary variables). CLDs do a great job of bringing many aspects of system thinking together and presenting them visually.

Below is the combined view of how four upstream system variables that we have discussed earlier relate to “healthy Scrum dynamics”:

As the graphic suggests, the nature of the effect (positive vs. negative), time of onset (immediate vs. delayed), and impact (casual vs. extreme) could be unique for each variable.

Scaling Scrum and organizational agility

In this section, I want to describe how I, with the use of CLDs, bring my discussions with senior management to culmination, by painting a bigger picture of organizational agility.

For most large organizations, success by a single team is not the end goal. Organizations look for “bigger” solutions. And their reasons are obvious: huge IT departments, many lines of business, many customers, multiple competing priorities, multiyear strategies, and many other elements that make organizational needs nothing less than huge. Luckily, most organizational leaders that I have met in my practice understand that the ability to effectively scale basic Agile frameworks (e.g., simple Scrum) will ultimately improve organizational agility and ensure that both customers and employees are happy.

Below is the graphic that summarizes this last, “commonsense” relationship:


Tying it all together

What I would like to do at this point is to take one step back and describe what it takes to scale Scrum effectively:

This is where another powerful concept of LeSS comes to the rescue: In order to scale Scrum, an organization must be descaled first (please refer to “Less Agile or LeSS Agile?” by Craig Larman). Other words, to construct a model of Scrum, performed by multiple teams, an organization must remove (deconstruct) its existing organizational complexity first. As it was stated at the beginning of this article, scaling does not imply making things more complex, but unfortunately this key concept is not always well understood. Mistakenly, many people still think that in order to support existing organizational complexity they need to look for multitiered, complex Agile frameworks that will provide “room and purpose” for every existing organizational element: roles, processes, tools, and techniques.

The analogy that I frequently use to deliver the concept of scaling to senior management is that building a sky scraper on a wobbly, porous foundation is dangerous because it will eventually crumble. The surface must be cleaned up first, flattened and hardened, and only then will there be a chance to build something tall and strong.

Below is the graphic that summarizes this concept:

At this point, the most common request I get from senior leaders is to elaborate on what I mean by de-scaling — and this is my favorite topic. This question is natural, but I usually resist answering it immediately, since the topic is inherently large, complex, and, at times, inflammatory. Therefore, I request a dedicated discussion for it.

I still produce a CLD graphic illustration of the concept, as shown below, but offer a follow-up discussion to explore details:

Ultimately, when this discussion is held, I always tie it back to the present discussion and explain why Goal: Distribute discretionary incentives becomes so trivial with the identification and removal of system/organizational waste. This discussion is usually long, and it requires challenging many outdated organizational norms and principles that some senior leaders are not willing to give up easily.

The CLD graphic illustration is a high-level generalization of the concept of the opposite (inverse) relationship between the two system variables:

As mentioned above, the variable in the dotted circle can be decomposed further into many smaller system variables that have up- and downstream relationships with one another.


The best summaries are short. Therefore, I would like to summarize this post briefly, with one comprehensive CLD diagram that brings together the variables, relationships, and annotations that have been discussed:

Although it may take hours, or sometimes days, of brainstorming to produce a CLD, when complete it becomes a great communication vehicle. A diagram like this one can be created in real time, in collaboration with others, on a whiteboard. Alternatively, it could be created ahead of time by a coach or trainer and then be used as a “cheat sheet” when appropriate. CLDs can also be shared with a wide audience ahead of time, to solicit questions and provoke interesting discussions at a later point.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.8 (6 ratings)


Gene Gendel, CEC,CSP,CSM,CSPO, 7/13/2016 11:31:48 AM
To provide a more expanded reference to my own post, i would to offer the following page:
Adrian Miranda, CSP,CSM, 12/16/2016 3:01:41 PM
Great article. Very informative.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up