The fear of failing to meet a due date can cause us to act in 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 is unproven and as such, it has no value to the end user. A plan and a design does very little to help us remove uncertainty and does 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. 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 does 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.
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 in order 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 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.
Learning in software, as outlined in the first post, occurs across many dimensions in 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.
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.
Every software effort brings together a unique group of people developing the product, using the product, and funding the product. The social interactions between the individuals is unique and must move through the social learning stages of forming, storming, norming, and performing1. 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 with their own unique specialties doing their own work. 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 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 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 are a technique2 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.
Alastair Cockburn describes a technique called the walking skeleton3 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 options, 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.
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 detailed 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 the future performance using a technique commonly referred to as “Yesterday’s Weather4.” 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.
Backlog scope uncertainty, estimate uncertainty, and team performance uncertainty must be accounted for when forecasting 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 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 date amidst uncertainty.
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.