The following article on experimentation is part 4 of an 8-part series on the Agile Mind-set Principles. These are principles that help you obtain, and maintain an agile mindset. Having an agile mindset is what makes everything else related to agile methodologies work. You can read part 1 here.
If you are in the business of trying to piece together a complex technical solution to a business problem, then you will need to employ experimentation as a tool to learn, progress, and find value for your clients or stakeholders.
An Analogy Gone Wrong
A lot of times, software development has been, wrongly in my view, compared to building a house. Much like an architect maps out what needs to be built, a software architect and a BA, if you have one, maps out the requirements to figure out what they are going to program. The workers purchase the materials, and begin constructing with slight variations to the original design. But, for the most part, the house that was in the blueprint reflects that house that was built. Developers, take the requirements outlined and build their solution like construction workers following a blueprint. And so the analogy goes.
On the surface, this analogy seems to make sense. However, held to more scrutiny, the comparisons unravel.
A Closer Look
Let’s look first at how the house is conceptualized. In the analogy, the architect designs a house. A lot of elements come into play at this phase. The architect knows how the materials are sold (dry wall is sold by 4 foot sections, carpet comes in rolls of standards widths). The architect uses this information to enhance the efficiency of the design and limit the amount of wasted cuts of material. The techniques used to construct a house stay pretty much the same with slight modifications over time.
Now, looking at software development, the analogy doesn’t hold. For one, the materials varies completely from project to project. A framework or technology that works for one set of business objectives may not fill the need for another set of objectives. Additionally, unlike construction, the way things are implemented constantly change. We’ve been putting houses together in much the same way over the years. However, the software that was built in the 90’s is far different than how it was built today; and will completely change within the next few months or years. You can’t count on those same constants like an construction architect can.
Summarizing the Differences
Here is the bottom line: between construction and software development, the underlying act is similar – it is creating something. However, creating something is the only similarity. When you compare how things are created between construction and software development, the analogy falls apart.
In construction, the process is typically repeatable, the outcome is known. If you design a house with specific dimensions, you can pretty much figure out how much raw material you will need and waste that will be produced. But, in the software development space, you are constantly figuring things out as you go. The solution that worked on a previous project may not yield the same results for a different project. Moreover, the outcome produced in software development often yields additional changes because new problems are uncovered; or, the problem you are trying to solve changes. This doesn’t happen in the construction realm. No one says, at the top of the iron framework of a skyscraper “well, I guess we should have added another 10 floors”.
Putting together Complexity, Empirical-based Work
Software development is empirical, complex and most times, complicated (for a greater explanation of what this means, go here). In complicated situations, you need to experiment to find value.
In construction, building things with material and methods that haven’t significantly changed over the years; it is complicated, but it isn’t complex (for additional information on these terms, see the Stacey Matrix explanation here). Construction plans break down to activities and deliverables that are known before the ground is even broken.
Conversely, with software development, there’s a definite fog of development that engulfs everyone before the first line of code is written. Pushing through the fog requires a different approach. You have to find your way to the solution incrementally, taking steps forward, backwards, and sideways, to deliver value. The basis of this progress is through experimentation.
Why Experimentation is Important
Trying new things, implementing new technology, changing ways of thinking, changing approaches are all the basics of employing experimentation in your efforts. Do experiments with how you run your meetings. Experiment with how your report the progress of your team. Try experimenting with different types of testing tools. The important thing is that you are conducting experiments with a goal of optimizing value and performance.
Experimentation challenges yourself and your team. You shouldn’t default to some canned solution unless it meets the needs and objectives of your stakeholders. Create proofs of concepts as a way to find the best value for your project. You should be creating experiments at the end of your retrospectives for improvement in the process of creating a solution or managing your team.
Applying Experimentation in Broader Contexts
The great thing about experimentation is that it doesn’t need to only apply to a development team. Perform experiments anywhere you have a complicated set of work where you have to figure things out. This applies to learning a new skill, a new concept, marketing campaigns, startups, business strategies, home life, work life, recreational life. Experimentation can be useful everywhere in empirical-based scenarios.
So, what things in your life is complex where you have to find your way to a solution? What are the recent experiments that you have tried out? If you aren’t experimenting, your missing out on progress and that’s not too complex to figure out.
Thanks for reading.
Being > Doing
David Bjarnson
2 Comments