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.