Remove Date-driven Behavior to Achieve Agility—Learn More By Doing

Action trumps the best plan and design.

The fear of failing to meet a due date can cause us to act in an overly cautious manner and encourages wasteful date-driven behavior. To counteract the fear, we plan for every contingency. We use logic to detail the design of a solution that is perfect on paper and can handle all possible scenarios we can enumerate. Then, we create a step-by-step plan to implement the design.

This flaw in this approach is significant—we have not built what is planned and designed. Nothing exists. A plan and design are unproven and as such, they have no value to the end user. A plan and a design do very little to help us remove uncertainty and do not increase learning. We learn by trying small experiments, evaluating the outcome, adjusting, and repeating until the right solution emerges.

This is the second post in a series on removing date-driven behavior. The first post illustrated why date-driven behavior results in waste and inhibits agility, and why you should, therefore, minimize it.

This second post focuses on replacing fear with safety and learning more by doing versus planning and designing.

Learning Pattern Prerequisite: Safety

Without safety, trying something new without detailed planning and designing is highly unlikely. Trying something minimally planned and designed in an unsafe environment may work for a while, but as soon as failure occurs, the wrath that typically ensues will ensure future careful, detailed planning and design before taking any action.

The pressure is even greater when a due date is present as there is no room for mistakes. In attempting to avoid failure to meet the date, a team performs even more careful detailed planning and designing. The irony is that planning and designing do nothing to reduce the chance of failure in the complex and uncertain world of software. Only trying something will allow you to find problems fast and fix them early.

Creating safety and motivating a team with something other than a date is critical.

Creating Safety

Teams must feel safe to try things that may or may not work regardless of the presence of a date constraint. As a leader, you should encourage the team to breathe, innovate, and discover the right design and solution through an experimental approach. In the uncertain realm of software development, a date constraint does not obviate the need to iterate and find problems fast.

We must remove the fear of finding problems and accept the possibility of the resulting rework as an investment in learning that leads to the right solution. An experiment that fails is not a waste or a cost. Early learning that a potential path does not work is invaluable and we must celebrate it.

As a leader, celebrate learning versus assigning blame when problems emerge. Expect problems. Accept things don’t go as planned and encourage your team to try out ideas in a low-fidelity manner to assess the merit or applicability of the idea.

Motivating a Team

If you have a valid date constraint, so be it. However, you should remove manufactured date constraints put in place as an attempt to motivate or focus the team.

Instead, demonstrate Agile Leadership to motivate the team. Do this by crafting a shared vision, helping the team understand the “why” behind the work, and providing adequate support for removing obstacles the team faces in achieving the vision.

Corrective Pattern: Learn More by Doing

Software development is not simple and is not a repeatable activity. It is not like following a recipe. It is more like painting and requires early learning through experimentation.

Software Development is Like Painting

Software development is complex, uncertain, creative, and custom. An iterative and incremental approach proves extremely effective for software development. Iterative implies experimental. Iterative build, measure, and learn loops are critical. Incremental implies small and rapid. Small reduces risk.

This process is similar to how an artist paints. An artist might sketch the composition of the painting first. The sketch is low on detail. This is crucial as most sketching is not right on the first try. The artist evaluates the sketch and refines it until the composition is right. It is likely the artist throws out the first few sketches. Then, the artist might focus on an area of the painting and follow a similar iterative addition of detail, finding problems and correcting until it looks right. This iterative and incremental process continues until the masterpiece is complete. The masterpiece emerges.

Contrast this to the act of someone who traces or copies an existing piece of artwork. This process is not iterative but it can be incremental and performed by following a set of predefined or planned steps. A similar comparison is paint-by-number. There is no creative aspect to the work. This is not comparable to software development. Like the creation of the masterpiece by the artist, software development is a creative, custom, and emergent endeavor.

Strive for Early Learning

Whether you have a date or not, software development requires learning. Do not try to get it right by planning and designing. Plan to get it right by trying something and learning if it works.

This is what is meant by “fail fast.” However, failure is a strong word. If you try something in its simplest form in a small increment, you will learn fast on a small investment. Even if what you try does not work, you have eliminated a path that you otherwise would have not known to eliminate.

In Figure A, this early learning strategy contrasts against the late learning strategy of big planning, design, and development up front without testing or measurement and iteration along the way.

Figure A: Late Learning Versus Early Learning

Learning Patterns

Learning in software, as outlined in the first post, occurs across many dimensions of software development—scope, social, technical, and effort. This learning best happens in small increments. In the presence of uncertainty, the goal is to try small experiments to find problems fast and discover the right solution. Outlined below are patterns for learning across the four learning dimensions of software development.

Scope

For scope, start simple. Do not be tempted to start with the best version you can imagine. First, try to create a good and simple version of a solution. Get feedback. Iterate based on the feedback and try a new, improved version. As illustrated in Figure B, continue this cycle until the “right” solution emerges.

Figure B: Emerge the Right Solution Through Iteration

Social

Every software effort brings together a unique group of people developing the product, using the product, and funding the product. The social interactions between these individuals are unique, and the team must move through the social learning stages of forming, storming, norming, and performing¹. This social learning can only happen by the team members starting to work together. It does not happen by planning or designing the perfect team.

As such, stable, long-lived teams are socially strong as they have learned how to be high-performing, having moved through the social learning necessary to reach the performing stage.

Promoting teamwork within the team will also enforce social learning. A team is not a collection of individuals each working alone in a unique specialty. Rather, a team works together to reach a common goal. You will know a team is socially maturing when you hear less, “that is not my job,” and more, “how can I help?”

Like-minded or like-skilled individuals do not make the best teammates. Constructive tension and different perspectives will build a stronger team.

A cross-functional feature team is multi-faceted and can deliver all aspects of a feature to a user. The highest-performing teams control all aspects of delivering a solution to meet a user’s need.

A team working together and learning from each other to deliver the work is best demonstrated by swarming or one-by-one production of the work.

Technical

Technical learning is not achieved by constructing a well-considered design and comprehensive design documentation. When the technology solution is uncertain, there are three typical options for rapidly removing the uncertainty, which have nothing to do with big design and documentation up front. These are described below.

Spikes

Spikes are a technique² described by Alistair Cockburn and Kent Beck that allows a development team to remove uncertainties before commencing work.

Essentially, the developer performs a time-boxed development activity to implement a simple proof of concept to research and learn if a technical approach is correct. This research should be the simplest thing the team can do to test an approach or hypothesis. Typically, this activity is less than a day in duration.

As an example, if a team has never used a particular technology needed for a feature, they may choose to implement a spike before sizing and bringing a user feature into a sprint.

Walking Skeletons

Alastair Cockburn describes a technique called the walking skeleton³ where a small lightweight implementation of the system is built end-to-end to link together the main architectural design components.

Significant learning emerges from taking a complete end-to-end pass through the architecture. This technique resolves many technical uncertainties and gains valuable learning on the viability of the end-to-end architecture for the task at hand.

A / B Testing

When evaluating more than one technical solution option, a team can choose to implement multiple options and evaluate each, selecting the one that proves to be the best solution.

These options should be the simplest, low-fidelity implementations that will answer the uncertainty of the two options. Low fidelity is critical as one or both options will be discarded.

Effort & Forecasted Delivery

Effort and performance are team specific. They are also influenced by the uncertainties of software development mentioned above. Techniques for rapidly estimating effort, team performance, and uncertainty are illustrated below.

Relative Sizing

When a team sizes work in Scrum, it is a relative size estimate rather than a detailed level of effort with a work breakdown structure. Typically, teams use a modified Fibonacci series to apply a relative size to work.

Teams use relative sizing to provide estimates of work based on its similarity to other recently completed work. A team will utilize rapid sizing techniques such as Planning Poker to quickly assign the relative size. The beauty of this technique is in the conversation and alignment around the work rather than the actual resulting size. However, the sizes prove to be quite accurate and quickly generated.

If you have just formed a new team or you are starting work with no prior reference for relative sizing, it is important to resist the temptation to dive into a detailed analysis of what steps are required to complete the work with intricate level of effort estimates. Simply apply a reasonable size to the work and move on. Once work starts and the team begins to normalize and understand the work, sizing will become easier as the team aligns on its sizing context.

Forecast Using Yesterday’s Weather

When forecasting how quickly a team can deliver a backlog of work, it is best to take an average of the team’s recent performance and use that to forecast future performance using a technique commonly referred to as “Yesterday’s Weather⁴.” Just like a meteorologist uses yesterday’s weather to predict today’s weather, the team will use recent performance to predict future performance.

If a team is new with no past performance to consult, resist the temptation to run simulations or guess about a team’s ability to move through the work. If there is no past performance to consult, creating a forecast is meaningless. To forecast a team’s ability to move through the work, let the team start working. This will provide real historical and recent data to calculate the forecast.

Uncertainty

Backlog scope uncertainty, estimate uncertainty, and team performance uncertainty must be accounted for when forecasting a delivery date for a backlog of work.

It is best to account for backlog scope uncertainty by applying a low and high range around the sizes of backlog items to account for the new scope that emerges through iteration and learning.

Typically a team will reflect uncertainty in their estimates by selecting a higher size in the Fibonacci series. Also, the non-linear nature of the Fibonacci series provides a natural uncertainty between two larger items. For instance, there is not much uncertainty between 1, 2, and 3 on the Fibonacci scale. However, there is uncertainty between 8, 13, and 20.

Finally, team performance uncertainty should be applied as a low and high range around the recent past performance average. In Scrum, perhaps the low and high velocities of the past few sprints are used as the range.

A future post will dive deeper into forecasting delivery dates amidst uncertainty.

Conclusion

Dates drive us to plan and design more before taking action. We must fight against this behavior. Regardless of the presence of a date, we only learn by doing and software development requires early learning to arrive at the right solution.

This post illustrates how we can learn more by taking action and doing the work. Key patterns for taking action in the key areas of software learning were outlined—scope, social, technical, and effort learning.

Stay tuned for future posts in the series on how to break the date-driven behavior anti-pattern.

Reference

Developmental Sequence in Small Groups, Psychological Bulletin 63, B W Tuckman (1965)
Spike Solution – C2 Wiki, Ward Cunningham, August 30, 2010
Walking Skeletons – C2 Wiki, Ward Cunningham, August 22, 2008
Published Pattern: Yesterday’s Weather, Scrum Published Library of Patterns

Coach Lankford

Todd Lankford unlocks Lean Leverage in organizations to cultivate powerful, engaged product teams who maximize outcomes and impact.

His articles share his experiences and learnings along the way. Join the mailing list to get them in your inbox.

Blogs