Tag Archives: Alistair Cockburn

How to Absorb Changing Requirements in New Product Development

Posted on by
Reply

This post explores several approaches to prepare for absorbing changing requirements in product development projects. This post was inspired by Alistair Cockburn’s recent remarks.

Project Requirements

Many development projects have formal requirements. Most often these are found in projects that follow a waterfall methodology or those that embrace the Big Design Up Front (BDUF) approach. Typically, these types of projects contain requirements that include features that must be in the final product and constraints related to the schedule and budget. Sometimes the requirements change significantly as the project progresses. The changes may be frustrating to the development team.

Alistair Cockburn (@TotherAlistair) declared that he does not ‘welcome changing requirements.’ He sets up projects to absorb changes in requirements in the best possible way.

Cockburn made these comments on 2 July 2013 (VIDEO: the ‘set up to absorb’ comments are at at 38:30). The phrase ‘welcome changing requirements’ refers to one of the Principles behind the Agile Manifesto

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

To understand the context of his remarks, let’s review a few items from 2001.

Recollections from the meeting that produced the Agile Manifesto

Cockburn (pronounced Co-burn, the Scottish way ) was one of the 17 signatories of the Agile Manifesto in 2001. This meeting was not to develop something new. It served to summarize similarities in the approaches that had been used by the attendees for several years.

He recalled that the manifesto was crafted in one day. There was complete agreement over the wording. This includes the familiar phrases:

“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”

Work began on the Twelve Principles behind the Agile Manifesto the next day. His recollection is that there was not complete agreement on all of the wording for the principles.

During the one hour Q&A 2 July 2013 session, Cockburn playfully emphasized the word ‘welcome.’ It seems that Cockburn may not have been in complete agreement with the choice of the word ‘welcome’ in the ‘welcome changing requirements’ principle.

The Mindset Regarding Changes

Cockburn has been involved with enough development efforts to know that requirements change during projects.

Some changes occur because of incomplete research or misunderstandings. Some errors may be perpetuated in the documentation. Mismatches may be revealed because conditions in the marketplace have changed since the requirements were gathered.

Projects can be designed to respond to changing requirements. Cockburn has adopted an active approach to absorb changes.

When Cockburn spoke of ‘absorbing changes’ he was not suggesting something analogous to a sponge absorbing water. The better analogy is a shock absorber on a vehicle. It is a device designed to smooth the driving experience for the passengers. It improves comfort and safety.

Several Ways to Set Up a Project to Absorb Changes

There are many ways to prepare projects to absorb changes. In this post, I will summarize a few approaches that Cockburn has employed.

Information Radiators

When the team has access to relevant, emerging information, they are more likely to be able to absorb changes. One way to share emerging information is with an information radiator. Cockburn coined the phrase “information radiator” in approximately the year 2000. According to Cockburn, an information radiator needs to be large (easily seen), easy to understand, public, and changing. Information radiators promote interaction. Current development information, including problems, should be visible to everyone on the team so that specific problems are perceptible to the individual that may have the solution.

Often, information radiators are positioned on the team room wall or some other conspicuous place. An information radiator facilitates distributed cognition.

The opposite of an information radiator is an information closet. Cockburn cautioned against the tendency to store necessary information online and assume that team members are interacting with it.

Capture educational information from interactive sessions in rich formats

To efficiently and effectively facilitate information transfer to new or less experienced members of the team, Cockburn advocates a one-to-one interaction format that is recorded. For example, the expert on a specific item can meet with a new team member to explain specific items. A white board or flip chart can be used to visually capture some of the information. The session should be interactive with questions and answers. The session must be recorded so that when the next new team member needs to learn about this item, they can start by reviewing the recording.

Instead of an emphasis on formal documents or presentations, this approach relies on the interaction that results from dialog.

Overall, this interactive approach emphasizes the pursuit of activities that maximize the production of value and minimize the time spent on project artifacts.

Ensure that the team includes Ri-level practitioners

To maximize the potential to respond appropriately to changes in requirements, Cockburn advocates that development teams include Ri-level practitioners.

Cockburn uses the concept of Shuhari to characterize the stages of learning to mastery. For a particular set of skills, an individual can be classified in one of three levels:

  • Shu-level: An individual has learned a technique but is not aware of the limitations. They look for broad level clues.
  • Ha-level: An individual has collected multiple techniques but may not know why they are appropriate for every context.
  • Ri-level individuals invent and blend techniques. They insist on contextual clues before providing recommendations.

An individual can be a Ri-level practitioner in a narrowly defined area such as a particular programming language or in the broader context of product development. Having a critical mass of Ri-level individuals as part of the team improves the potential for selecting the appropriate options based on the specifics of the project.

In addition, individuals that have the insights to craft experiments and the skills to produce rapid prototypes are more likely to distinguish unvalidated inputs from validated inputs. They are more likely to distinguish opinions that may be unsubstantiated from refined information that can shape project requirements.

A Series of Cooperative Games

A cooperative team is equipped to handle changes better than a team that promotes non-cooperative functional areas (also known as silos). Cockburn envisions development as a cooperative game.

“I would like you to consider software development as a cooperative, finite, goal-seeking, group game. The goal is to produce a working system. The group, or team, consists of the sponsor, manager, requirements or usage specialists, software designers, testers, and writers. Usually the goal is to produce the system as quickly as possible, but there are other factors that affect the time goal: ease of use, cost, defect freedom, and liability protection. In general, it is a resource-limited game, which affects how the moves are made”

A cooperative game approach is consistent with a harmonious team effort toward a common goal. Within a cooperative game paradigm, changes to requirements are more likely to be viewed as a correction to achieve the common goal rather than a struggle to promote a particular perspective.

Development Experience

A team that has the benefit of items such as appropriate information radiators, efficient and effective training, an abundance of expertise that enables a variety of approaches to solve problems, and, a cooperative game approach is likely to thrive when presented with changes to project requirements. A team that has prepared for changes is more likely to thrive.

Cockburn advises teams to improve agility and adaptability. An environment that promotes the qualities of agility and adaptability is more likely to adjust to changes in requirements.
This type of team is more likely to enjoy better development experiences.

How to Absorb Changing Requirements This podcast is available on iTunes. Search for Development Experience.

How to Absorb Changing Requirements in New Product Development [ 10:58 ] Play Now | Play in Popup | Download

Reductionism and Recursion in New Product Development

Posted on by
2

Which approach to new product development will produce better results? Reductionism or Recursion?

Reductionism

According to Wikipedia:

“Reductionism is a philosophical position which holds that a complex system is nothing but the sum of its parts, and that an account of it can be reduced to accounts of individual constituents.”

In new product development, reductionism is rationalized as breaking development tasks into manageable pieces. Typical artifacts are seen in organizational charts or the roles assigned to individuals. For example:

  • Coders or Testers
  • Designers or Developers
  • Marketers or Sales
  • Project Managers or Product Managers
  • Front End of Innovation or Development

One of the potential advantages of reductionism is that it may provide focus to specialty efforts. Another potential advantage is that is may facilitate the interchangeability of resources (for example, one tester can be replaced by another tester with the equivalent qualifications).

Potential disadvantages of reductionism approaches include:

  • Degrades communication across functional groups
  • Acceptance of a hand-off mentality. This occurs when one functional area ‘finishes their job’ and presents their deliverables to the next group.
  • Increases the amount of explicit documentation
  • Sub-optimization. Too much effort may be devoted to certain tasks while others items do not receive sufficient attention.
  • Too much emphasis attributed to reaching milestones. Not enough emphasis on value creation.

Recursion

Recursion involves solving problems of the same form. In new product development, typical primary problems include:

  • Solving a customer’s problem. This is also described as providing a solution for the job the customer is trying to accomplish.
  • Increasing the organization’s revenue and/or profits
  • Positioning the organization for success in the future
  • Increasing the motivation of the development network. Dan Pink described this using the qualities of autonomy, mastery, and purpose. I describe this as improving the Development Experience [DX]

Recursion in the Development Network

For a recursion approach to flourish, an individual relates their short-term efforts (such as hourly, daily, or weekly efforts) to solve one or more of the primary problems listed in the previous section. For example:

  • Are their current efforts improving the ability of a customer to solve their problem? Has the learning increased so that individual contributors can determine if they are closer to solving the customer’s problem today than they were yesterday?
  • Are these efforts valuable to the customer? Are these efforts too bureaucratic?
  • Will the development efforts for the next project produce better results than the current project? Are the development capabilities being enhanced for future projects?
  • Will the contributors to the development network feel a sense of accomplishment? Will the predominant feelings relate to burn-out and frustration?

An environment that enables recursion to flourish ensures that individuals embrace opportunities to contribute to value creation during the current project and future projects.

Alistair Cockburn described this type of approach as a series of cooperative games. He stated:

“Software development is a series of resource-limited, goal-directed cooperative games of invention and communication. The primary goal of each game is the production and deployment of a software system; the residue of the game is a set of markers to assist the players of the next game. People use markers and props to remind, inspire and inform each other in getting to the next move in the game. The next game is an alteration of the system or the creation of a neighboring system. Each game therefore has as a secondary goal to create an advantageous position for the next game. Since each game is resource-limited, the primary and secondary goals compete for resources.”

Clinton Keith described it this way:

“For a cross-discipline team that is measured by value added to a working game, the role of an artist shifts to that of a ‘game developer’ who specializes in art. An artist doesn’t simply create an asset for someone else to put in the game and make fun.  The artist participates in the creation of an experience, where art has an equal value. By having a voice in the discussion about what is being created, the artist elevates the value of what they create and minimizes the cost of creating it.”

From the book “Agile Game Development with Scrum” by Clinton Keith (@ClintonKeith) page 227. Published in 2010.

Contrasting Recursion and Iteration

Iteration is repeating. Often, it involves executing the same process with new items from a long list of potential tasks.

In Scrum, Sprint is the term for an iteration. In Scrum, the duration of a typical Sprint is in the range of one to four weeks. During a Sprint, development is devoted to completing selected items from a backlog of items.

Common metrics for a series of Sprints may highlight factors related to the speed of execution. This may include items such as burn-down rate.

One of the potential problems with an iteration mindset is that the number of product features that are completed is associated with a proxy for the value produced by the project.

Which is Better?

Which approach provides better value from a project? Is it a reductionist approach or a recursion approach?

A tyrannical approach does not produce better project value. Debating over a development question that includes the word ‘or’ is not likely to improve qualities such as autonomy, mastery, and purpose.

Better value will be produced with the proper combination of reductionism and recursion. Some individuals excel as reductionists. However, the potential for project success can not be achieved when the reductionist viewpoint is the only viewpoint that is tolerated.

Maximizing the potential for project success requires that one or more of the primary problems is being solved. Solving these primary problems is best accomplished with the inclusion of a recursion approach. This requires more than assigning someone to a role such as Product Owner.

I have found that that potential to maximize success in new product development improves when there is a critical mass of individual contributors that embrace a recursive approach to development. This diversity in the development network improves the potential for harmonious plans, decisions, and actions throughout development. It improves the potential for the self-correcting analysis of feedback.

Vision and Version

The interplay of vision and version in new product development

The interplay of vision and version in new product development

The interplay of reductionism and recursion is similar to the interplay of vision and version in new product development. These approaches facilitate implicit coordination within a diverse group of individual contributors throughout development that will produce better outcomes than alternatives that enforce handoffs and explicit coordination during development.

With a synergistic approach, the customer’s problem is more likely to be solved. The Development Experience [DX] of the individual contributors is more likely to improve from one project to the next.

Podcast

 

Reductionism and Recursion in New Product Development (10 Minutes, 15.5 MBytes)

 

Reductionism and Recursion in New Product Development [ 9:52 ] Play Now | Play in Popup | Download