Failure is an option… as an ongoing process in design and learning

Testing software can be thought of as a highly organized experimental method.  Those of us who work in software development, are generally interested in maximizing the possibility that a software product or service is fit for purpose and meets the expectations of the customer.

We use a range of testing techniques that are appropriate to the technology and business context: from risk assessment to formal reviews, static and dynamic testing, manual and automated, progression and regression, functional and non-functional, requirements-based as well as exploratory testing techniques.  Testing should provide valuable feedback about whether the design after a particular iteration meets the various stakeholders’ expectations.

But what about the psychology of managing teams when testing reveals a quantity of problems and incidents that were not anticipated? How can you cultivate an atmosphere, which encourages looking for errors, mistakes and defects as a means to learning and improving the whole development process?

The problem is that frequently people do not want to confront errors or feel threatened by them. They may feel affronted or offended.   However this is missing an understanding of the fundamental reason why errors and mistakes are necessary to learn from, not only  in software development, but indeed any process of design and innovation.

I like to get inspiration from a range of sources and different modes of design.  For example, one of the most famous architects in the last 50 years, Frank Gehry says this about mistakes in the design process of large commercial buildings:

“So as you are working in real life and in real time you are constantly having small victories and small mistakes….the important thing is to keep moving ahead and learning from the mistakes and building on it, building positive momentum from that. Because it is a very complex endeavor.”

Large-scale enterprise software project transformations can be of comparable in terms of scale and complexity of commercial building projects so I think there is a parallel.

In the book Fail Fast, Fail Often, Michael Bloomberg, the billionaire who developed the financial software tools including analytics and an equity trading platform, is quoted on the process of developing software for his financial software:

“We made mistakes, of course. Most of them were omissions we didn’t think of when we initially wrote the software. We fixed them by doing them over and over, again and again. We do the same today. While our competitors are still sucking their thumbs trying to make the design perfect, we’re already on prototype version #5….It gets back to planning versus acting: We act from day one; others plan how to plan – for months.”

Bias Towards Action And Agile Iterations

Bloomberg’s quote reveals a keen insight about the bias towards action versus being paralyzed by excessive planning. The agile movement is a response to limitations of traditional project management in part where according to Mike Cohn in his book Agile Estimating and Planning:

“At the start of each new iteration, an agile team incorporates all new knowledge gained in the preceding iteration and adapts accordingly.” (Cohn, 2006, 26)

The process of testing software is one of the main methods in which new knowledge is acquired and unexpected behavior of the design is observed during each iteration. Therefore finding errors is a necessary way to obtain information which assists the development team to adapt to this new knowledge.   As Frank Gehry suggested “the important thing is to keep moving ahead and learning from the mistakes and building on it …”

So to inspire and uplift a team from uncomfortable feelings of perfectionism or threatened by mistakes, errors or omissions or even misjudgments in the software design and development process, a manager can do a number of things to cultivate a positive environment for creativity and productivity:

1. Build an atmosphere of safety, where it is OK to make mistakes, ask crazy questions, find errors and this is, in fact, a necessary part of the evolutionary nature of the development process;
2. Facilitate discussions around shared risks which promote trusting cooperation;
3. Tell a narrative which creates a sense of shared goals, values and purpose and in doing so builds a coherent working environment.

Sprints as a structure for prototyping to aid design and product development

“If you already know what you are doing, you wont do it.” Frank Gehry

Part of the benefit of establishing a short timeframe for a sprint in software development, is that the time sets in motion a constraint for the team to create a boundary for focused effort. This creates a space for prioritizing development activity in a very focused way. It is well-known that sprints also assists in the relative measurement of velocity of the team between sprints.

Regular Feedback and Double Loop Learning

But there are other benefits. Short duration sprints ensure that there is regular feedback. As one of the original creators of Scrum, Jeff Sutherland describes, in his book of the same name, a more evolutionary, adaptive and self-correcting system of software development than its predecessor, waterfall was needed. He writes:

“And so my team embarked on what we called “sprints”. We called them that because the name evoked a quality of intensity. We were going to work all out for a short period of time and then stop to see where we were.” (Sutherland, 2014)

Teams can become more efficient by examining how they can improve their performance during retrospectives. Retrospectives mean double-loop learning, or generative learning, which may involve updating mental models, modification of goals or decision-making in the light of experience. This is particularly relevant when there is a high level of requirements uncertainty or technological complexity.

Encourage Problem Solving Through Prototyping

But depending on the level of requirements uncertainty and innovation, short iterations or sprints can provide a disciplined structure to encourage prototyping and problem solving. The advantage of a multi-disciplinary team providing regular feedback on a rough prototype of software or product cannot be overstated. The sort of inquiry that should result include such questions as:

1. Are we building the right product?
2. Is this what the client wants? Is it suitable?
3. Is it usable?
4. Is it functional?
5. What about its non-functional quality characteristics such as performance?

Prototyping- Build In Order To Think

But sprints, or short iterations leading to early prototyping in product development (not just in software) can also provide a framework for a problem-solving method. Prototyping is an approach to doing in order to think rather than thinking in order to do. This can make visible thought processes and initial intuitions through building multiple concrete prototypes or models of the final product.

Famous Architect Frank Gehry’s Working Method

Frank Gehry is perhaps best known for his iconic architecture including his idiosyncratic design of the Guggenheim Museum in Bilbao, Spain and the Walt Disney Concert Hall in Los Angeles. Building an extensive number prototypes was his working method which formed the backbone of his design process.

“Disney Hall did not appear to Gehry as a fully developed image, or a single idea. It emerged through a process of little bets through which Gehry and his team worked within constraints to frame and identify thousands of problems….Gehry and his team would, in fact create eighty-two prototypes models, working closely with the planning committee, until they arrived at the final form of the hall.” (Sims, P, 2011)

Disney Concert Hall

 

This philosophy reflects the Design Program at Stanford where the maxim, ‘building is thinking’ is an organizing principle of learning about the design process. Architecture, design and software development are activities that thrive on rapid prototyping to facilitate thinking, feedback and problem solving.  Sprints are a way to structure time and create constraints to focus effort and provide a continuous feedback loop which creates an adaptive, self-correcting system.  Design prototypes in order to think and solve problems.

References

Sims, Peter, (2011) Little Bets: How breakthrough ideas emerge from small discoveries: 79

Sutherland, Dr. Jeff, (2014) Scrum: A revolutionary approach to building teams, beating deadlines and boosting productivity: 73

Image By Carol M. Highsmith https://commons.wikimedia.org/w/index.php?curid=4544231https://en.wikipedia.org/wiki/Frank_Gehry#/media/File:Disney_Concert_Hall_by_Carol_Highsmith_edit2.jpg