The following article on experimentation is part 4 of an 8-part series on the Agile Mindset 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, map the requirements to determine 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.
Or so the analogy goes.
On the surface, this analogy seems to make sense. However, held to more scrutiny, the comparisons unravel.
A Closer Look
In the analogy, the architect designs a house. A lot of elements come into play in this phase. The architect knows how the materials are sold (e.g., drywall 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 number 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 vary 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 changes. 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 from software built today; and it will completely change again within the next few months or years.
You can’t count on those same constants like a construction architect can.
Summarizing the Differences
Here is the bottom line: between construction and software development, the underlying act is similar – we are 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 ten floors.”
Putting Together Complex, 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 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, backward, 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, and 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 the 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, and recreational life. Experimentation can be useful everywhere in empirical-based scenarios.
So, what things in your life are complex and require you to find your way to a solution? What are the recent experiments that you have tried out? If you aren’t experimenting, you're missing out on progress and that’s not too complex to figure out.
Thanks for reading.
Being > Doing