Book Cover

 

This week we re-read Chapter 3 of Thinking, Fast and Slow by Daniel Kahneman. One of the core themes in this chapter is the concept of ego depletion.  Ego depletion is a theory that self-control, as a form of system 2 thinking, draws from a finite pool of mental resources. When the pool is low, so is self-control. I did some research on the topic and the evidence is mixed whether there is an ego depletion impact. Regardless, from the point of view of Chapter 3 the idea is that heavy mental and physical loads on a person spread their ability to think and make decisions thin is not a stretch (and we should not expend a significant cognitive load on the topic). Whether the triggering mechanism is ego depletion or something else is not as important as the observable impact – when people are under mental stress they don’t always make the most thoughtful decisions.    (more…)

Kafka Statue

Are you measuring a team effort?

**Reprint**

Productivity is used to evaluate how efficiently an organization converts inputs into outputs.  However, productivity measures can and often are misapplied for a variety of reasons ranging from simple misunderstanding to gaming the system. Many misapplications of productivity measurement cause organizational behavior problems both from leaders and employees.  Five of the most common productivity-related behavioral problems are: (more…)

A significant amount of transformation and leadership literature centers on establishing or changing the culture centered on values. Instant problem.  According to the Harvard Business Review online article on organizational culture (May 2013)  “there is little consensus on what organizational culture actually is.” There are two common threads in the definition of organizational culture; definitions that center on value, and definitions that center on behaviors. Many change leaders espouse value-centric definitions.  This decision causes them to focus their efforts on changing values in order to change the culture. These change programs are immediately starting in a difficult position. Values are amorphous.  Every individual interprets specific values differently.  For example, I asked several friends to define creativity.  Each person had a different definition.  Some of the differences were more than mere nuances.  Our individual interpretations would make the outcome of embracing the value of creativity unpredictable.  The variability of how we interpret values make it difficult create a common vision and then elicit a common outcome. Diversity makes this issue even more problematic.   As someone schooled in the need for measurement and feedback, the lack of a clear definition makes monitoring and measuring a change in the values at best difficult and often outside of the expertise of most internal measurement groups.  Without a clear definition and without a mechanism for monitoring change, talking about values is merely window dressing. (more…)

Kafka Statue

Are you measuring a team effort?

Productivity is used to evaluate how efficiently an organization converts inputs into outputs.  However, productivity measures can and often are misapplied for a variety of reasons ranging from simple misunderstanding to gaming the system. Many misapplications of productivity measurement cause organizational behavior problems both from leaders and employees.  Five of the most common productivity-related behavioral problems are: (more…)

You don't need to define the roles if everybody knows who should be in the driver's seat.

You don’t need to define the roles if everybody knows who should be in the driver’s seat.

There are four basic topics that Agile charters address. Each category addresses different concepts that are important to help a team or a team-of-teams in a scaled effort to act in coordinated manner.  The four categories are:

  1. Envisioning Success
  2. Behavior
  3. Timing
  4. Constraints

There are any number of ways to address the concepts in each of the categories, and often a few teams and organizations use multiple approaches to address a specific concept. For example, some charters include a release plan and a set of milestones, both sections provide guidance on when things will happen during a project. Summarized below are the most common components used to address the concepts of behavior and timing. Each item includes a quick definition and a recommendation whether the component should be used for either a scaled Agile or team charter. Yes means the component should typically be used and no means don’t. (more…)

Organizations with a product perspective generally have an understanding that a project or release will follow the current project reducing the need to get as large a bite at the apple as possible (having tried this a child, I can tell you choking risk is increased).

Organizations with a product perspective generally have an understanding that a project or release will follow the current project reducing the need to get as large a bite at the apple as possible (having tried this a child, I can tell you choking risk is increased).

The concepts of product and project are common perspectives in software development organizations. A simple definition for each is that product is the thing that is delivered – software, an app or an interface. A project reflects that activities needed to develop the product or a feature of the product. Products often have roadmaps that define the path they will follow as they evolve. I was recently shown a road map for an appraisal tool a colleague markets that showed a number of new features planned for later this year and areas that would be addressed in the next few years. The map became less precise the further the time horizon was pushed out. Projects, releases and sprints typically are significantly more granular and with specific plans for work that is currently being developed. Different perspectives generate several different behaviors.

  1. Roadmap versus plan: The time-boxed nature of a project or a sprint (both have a stated beginning and end) tends to generate a focus planning and executing specific activities and tasks. For example, in Scrum sprint planning, accept and commit to the user stories they will deliver. There is often a many-to-one relationship between stories and features that would be recognized at by end-users or customers. Product planning tends to focus on the features and architectures that meet the needs of the user community. Projects foster short-term rather than long-term focus. Short-term focus can lead to architectural trade-offs or technical shortcuts to meet specific dates that will have negative implications in the future. The product owner is often the bridge between the project and product perspectives, acting as an arbiter. The product owner helps the team make decisions could have long-term implications and provides the whole team with an understanding of the roadmap. Teams without (or with limited) access to a product owner and product roadmap can only focus on the time horizon they know.
  2. Needs versus Constraints: Projects are often described as the interaction between the triple constraints of time, budget and scope. Sprints are no different; cadence – time, fixed team size – budget, and committed stories – scope. There is always a natural tension between the business/product owner and the development team. In organizations with a project perspective, product owners and other business stakeholders typically have a rational economic rational to pressure teams to commit to more than can reasonably accomplished in any specific project. Who knows when the next project will be funded? This behavior is often illustrated when the business indicates that ALL requirements they have identified are critical, or when concepts like a minimum viable product are met with hostility. Other examples of this behavior can be seen in organizations that adopt pseudo-Agile.  In pseudo-Agile backlogs are created and an overall due date generated for all the stories  before a team even understands their capacity to deliver. Shortcuts, technical debt and lower customer satisfaction are often the results of this type of perspective. Organizations with a product perspective generally have an understanding that a project or release will follow the current project reducing the need to get as large a bite at the apple as possible (having tried this a child, I can tell you choking risk is increased).
  3. Measuring Efficiency/Cost versus Revenue: Organizations with a product perspective tend to take a wider view of what needs to be measured. Books such as The Goal (by Goldratt and Cox) make a passionate argument for the measurement of overall revenue. The thought is that any process change or any system enhancement needs to be focused on optimizing the big picture rather than over optimizing steps that don’t translate to the goals of the organization. Focusing of delivering projects more efficiently, which is the classic IT measurement, does not make sense if what is being done does not translate to delivering value. Measuring the impact of a product roadmap (e.g. revenue, sales, ROI) leads organizations to a product view of work which lays stories and features out as portfolio of work.

These dichotomies represent how differences in project and product perspectives generate different behaviors. Both perspectives are important based on the role a person is playing in an organization. For example, a sprint team must have a project perspective so they can commit to work with a time box. That same team needs to have a product view when they are making day-to-day trade-offs that all teams take or technical debt may overtake their ability to deliver. Product owners are often the bridge between the project and product perspectives, however the best teams understand and leverage both.

 

Learning to pour sidra (cider) - product or project?

Learning to pour sidra (cider) – product or project?

A product is something that is constructed for sale or for trade for value. In the software world that product is often software code or a service to interface users to software. Typically a project or set of projects is required to build and maintain an IT product. If we simplify and combine the two concepts we could define a product as what is delivered and a project as the vehicle to deliver the product. The idea of a product and a project are related, but different concepts. There are several differences in common attributes:

Untitled

Agile pushes organizations to take more of a product than a project perspective, however arguably parts of both can be found as the product evolves. A sprint (or even a release) will include a subset of the features that are included on a product backlog.  The sprint or release is a representation of the project perspective.  As time progresses, the product backlog evolves as customer or user needs change (the product perspective). In the long run the product perspective drives the direction of the organization.  For example, a friend that owns a small firm that delivers software services maintains a single product backlog. In classic fashion the items near the top of the backlog have a higher priority and are more granular. The backlog includes some ideas, new services and features that won’t be addressed for one or more years. The owner acts as the product owner and at a high level sets the priorities with input from her staff once a quarter, based on progress, budget and market forces. The Scrum master and team are focused on delivering value during every sprint, while the product owner in this case is focused of building greater business capabilities.

IT in general, and software development specifically, have historically viewed work as a series projects, sometimes interlocked into larger programs. A project has a beginning and an end and delivers some agreed upon scope. When a project is complete a team moves on to the next job. A simple and rational behavior for a product owner who might not know when the next project impacting his product might occur would be to ask for the moon and to pitch a fit when it isn’t delivered. Because the product owner and the team are taking a project perspective it is impossible to count on work continuing forcing an all or nothing attitude. That attitude put the pressure on a team to accept more requirements than they can deliver leading an increased possibility of  disappointment, lower quality and failure. Having either a product or project perspective will drive how everyone involved in delivering functionality interact and behave.

All types of teams have biases.

All types of teams have biases.

The second class of biases affects how we behave or how we tend to group. How we group into teams effects decision making which completes the cycle and reinforces how the individuals in a team behave. Many of the filters and shortcuts that we develop help us to successfully interact with the environment, however, they can negatively impact team effectiveness. A sample of common biases that affect IT teams include:

A zero-risk bias reflects a team preference for mitigating a small risk down to zero rather than dealing with the mitigation of a larger risk that they can’t drive to zero. This bias can be seen not only in risks but when developing difficult (therefore more risky) stories. This can lead to a team to do the easy pieces of work early in a sprint leaving the more difficult work until late in the sprint, including the likelihood of not completing stories during an iteration.

The bandwagon effect occurs when there is a tendency to adopt an idea (or to do something) because an external group or crowd believes the same thing. For example, when a particular concept is touted on the cover of all the industry journals a bandwagon effect can build to adopt the idea.  When I was a child I used the “everybody is doing it” refrain to try to convince my mother that staying out all night was a good idea; she did not buy it. The bandwagon effect is more common with teams that exhibit ideological homogeneity because there are fewer alternative perspectives to provide resistance. Where a common core belief is strongly held, groupthink can make adopting new ideas difficult because it is easier to adopt.

I am firmly convinced that if I watch my alma mater play football on television they will lose (my wife suggests that I am not that powerful). This bias is called the illusion of control, which is defined as the tendency to overestimate one’s (or a team’s) degree of influence over external events.

The social desirability bias can be problematic, especially during retrospectives. The social desirability bias is the tendency to over-report desirable behaviors while underreporting undesirable behaviors. Team or individuals that fall prey to this bias tend not to be able to identify and deal with the tougher people issues that can occur on teams. When this bias is present in a team, a coach or leader needs to safely expose behavior problems or risk deep-seated dysfunctions developing.

Team composition is important. Most of us would agree that team members should have a broad set of capabilities and that members should push each other intellectually. When a team is assembled by a leader with a social comparison bias, membership decisions are made so that those who are on the team don’t compete with the leader’s strengths. This type of bias (and there are a number of biases with similar impacts) leads to teams that will rarely challenge the leader’s perception of the status quo.

Biases drive behaviors. When biases generate poor behaviors, such as only believing data that support your ideas (expectation bias), the effectiveness of the team and its members will be reduced. When the behavioral biases are benign, a coach or leader can help the individual and team sort out problems. However, some biases generate behavior that is far less benign. Where bias is causing serious team issues, I strongly suggest involving a trained human-relations specialist.

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. 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.

Team In An Agile Class Is Born, Collaboration!

A team is born through collaboration in an Agile class!

Agile is not just frameworks, methodologies and characteristics. It is a culture, or maybe it would be better to say that Agile can become an organization’s culture.  Organizational culture is a common pattern of behaviors and the meaning attributed to those behaviors within the organization.  Agile, if embraced, reforms organizational culture. The culture of an Agile organization features three distinct clusters of behaviors: learning, collaboration and business-driven behaviors.

Learning is personal behavior, a project behavior and an organizational behavior.  Alistair Coburn, in his keynote at the Scrum Gathering in Las Vegas, said that Agile helps projects and organizations to learn quickly.  Short iterations and rapid feedback loops give project teams and the organizations the ability to find out quickly if a solution or alternative is viable or not, and get a better handle on what they know and don’t know.

Collaboration is central to teams becoming more than a loose set of individuals. Collaboration includes the ability to take the first step, work out loud, share credit, listen and respect others. These behaviors are also an important foundation for creating self-directed and self-organized teams.

Business-driven behavior includes behaviors like embracing change. One of the core benefits of Agile is improved customer satisfaction generated by embracing change.  The inclusion of the voice of the customer by someone that is not an IT proxy is a major change in behavior for most companies. The product owner in Scrum is an example of this “new” role. A second business-driven behavior is a embracing changes to requirements. Using a disciplined approach to embrace requirements keeps the project (and by default the organization) focused on the current needs of the business.

Embracing Agile means embracing change for most organizations, which is usually pretty hard. Most Agile and Scrum coaches say that unless there is pain involved you are not tackling all of the behaviors that need to change. It is easy to believe you are Agile, but it only counts if you behave Agile.