One of my favorite shows to watch is improv theater. It wasn’t until this most recent show that I realized why I like it so much. There is something a wee bit magical in experiencing highly intelligent and creative people make you laugh uncontrollably when faced with the most bizarre of constraints. Need to make a talk show with an elephant set in the 1950s funny? I bet an improv actor could do it.
What’s interesting to me from an intellectual perspective is that the reality of the constraints don’t really matter. The time frame could be the 1950s, the 1970s, the 1800s or the 2020s. All that matters is that the actors and audience have some level of shared understanding of what that constraint means so that the audience “gets it” when the actor does something bizarre on the stage. Without the constraint that bizarre activity might be just bizarre and not really funny.
What also makes improv compelling is that there are many possible ways to be funny within a given set of constraints. I’m sure each actor has their own ideas or could create several possible skits, each having their own particular merits and their own laugh factor. But they typically only get one chance on stage.
So what does this all have to do with software? I’ve recently been making good on my new year intention to get caught up with some of the more recent literature out there, starting with Mary and Tom Poppendieck’s Lean Software Development. The authors describe part of Toyota’s design process. In an effort to design cars that are also efficient to produce, there tends to be a lot of back and forth between design engineers and production engineers. The typical process is for a design engineer to propose multiple solutions and the product engineer to provide feedback on what can be efficiently produced. This can lead to what a laborious feedback loop of back and forth until a sub-optimum solution is finally accepted.
What Toyota does is different and is called point-based development. The production engineers all provide checklists with constraints for their particular area, whether it’s how the bumper can be produced at a certain cost, or whatever measures the final design is trying to achieve. The design engineers are then given complete freedom to design a solution that meets the constraints.
Sounds a lot like improv theater to me and support behind the idea that properly defined constraints support the creative process and encourage creative thinking.
So what does this tell us about the requirements process? What would it look like to involve a deep understanding of constraints upfront? How could we be more creative if we did so?
My memory lingers back to the “constraints” section of the big-thick-document that lists a few things we will not change to keep the project scope in check. As constraints on the project they didn’t provide the information needed to really constrain the design. For example, we might have listed, “no changes to a certain sub-system will be made” but unless you have a possible solution to talk about you didn’t really know if what you were designing was going to require such a change. And this leads to a back and forth requirements process much like the typical car design process. In fact, I can think of many examples (as I am sure you can too) where we started this sort of design ping-pong as one stakeholder idea after another is found to be impossible to implement given the schedule or budget constraints.
What Toyota did, if I understand it correctly, was elevate the information about constraints to be boundaries on the design process. The design and production engineers shared a common understanding of the constraints, just like improv theater is successful because the audience and actors have a shared understanding of what it means to host a talk show with an elephant set in the 1950s. A real design constraint is very different than a project constraint.
My hunch is that this information is what surfaces in those magical problem-solving sessions where you turn impossible requirements into possibilities. We reach a shared understanding of constraints that allows us to be more creative as a team. But could we bring this knowledge to the forefront and enable our stakeholders to get even more creative with their ideas as they understand the boundaries in which they can work? These are some ideas I’m starting to ponder. I don’t have the answers. But I’m looking forward to hearing your ideas, resources, or feedback.
|
By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg |
Related posts:
Loading ...
.jpg)
{ 4 comments… read them below or add one }
Nice article, Laura. Another thing to realize is that the constraints of a requirement are continuously refined and narrowed until the “feature” (door panel, alternator, software system) is good enough and the cost of the next step exceeds the benefit.
– It would make life so much easier, but GM has had a long time to look at Toyota and is still baffled. Indeed, most American manufacturers are running in the opposite direction, outsourcing manufacturing for cost reduction.
– I think the ‘constraints’, are more like optimization constraints: less than, greater than or between conditions.
Can you say some more about how it is applied to agile?
a few related works that might be interesting:
Design Rules, Vol. 1: The Power of Modularity, Carliss Y. Baldwin & Kim B. Clark, MIT Press 2000
and
Star SL & Griesemer JR (1989). “Institutional Ecology, ‘Translations’ and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39″. Social Studies of Science 19 (4): 387–420
The first develops the theory of design rules (very similar to the Toyota constraints) that put a dependency matrix into block diagonal form (or nearly so). What this means is that each “block” represents a module that can be developed independently as long as the overlap with other modules (in it language the sub system interface
is respected. It turns out that many broad dependencies can be factored and fixed to create modular systems out of apparent chaos. More recent work has focused on software systems, particularly the difference between open source and proprietary development approaches.
The second is all about the notion of “boundary objects”. A boundary object is tangible that is shared between two domains but which has different semantics in those domains. The situation described in the paper is about the communication between hunters and trappers and academic museum naturalists and biologists. The boundary object is the pelt and the condition of the pelt. For auto designers, the car and its various models (both physical and computer generated) are the boundary object. Designers (in this case visual style design) and think about systems of shape and color while the manufacturing designers think about rigidity, draw depth, and waste material. This, implicit, concept is crucial to the operation of the “big room”. In theory, a structured facilitation like JAD depends on focus around boundary objects, but representations are ID derived (disadvantaging one side) and have a misplaced focus on working as a team, rather than as an inter-domain discussion where each domain needs to go off and discuss among them selves. For example, to we really want the subcutaneous fat scraped off the skunk skin before we get it?
If you put these together with the “don’t make any decisions until you really have to” rule, I think you get much of the design process.
btw … I would point out that requirements make very poor boundary objects.