Constraints Drive Innovation
Constraints Drive Innovation
Join the DZone community and get the full member experience.Join For Free
The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.
On a recent vacation I visited the Mingei International Museum in San Diego. During a tour by the museum director we were looking at a mid-1930′s Santo Domingo Pueblo (New Mexico) necklace. “Interesting about this necklace,” the director said, “are the ‘nots’– not coral, not obsidian (but old melted phonograph records for the black element). During the depression the Native American artists were constrained by the lack of materials. Everyone thinks that creativity and innovation are driven by freedom. In the art world they are often driven instead by the constraints.”
His comment got me thinking about the Constraint point on the Agile Triangle. While the most frequent discussions are about Value and Quality, we can’t forget the role of Constraints and how they often drive innovation and design. Teams at Ideo, the highly recognized design firm, are often driven by time constraints. While they have great freedom and a highly collaborative environment, they operate under very tight time constraints–and usually deliver.
There are two key points here:
- Constraints are critical to innovation and creativity
- Constraints should be carefully constructed
The second point here is one that often eludes us. Constraints are often arbitrarily set, with little thought to their impact on product development. For example, as exploration factors get higher (greater risk and uncertainty), setting aggressive time constraints may be very useful. However, setting aggressive scope requirements at the same time are usually counter-productive.
In the Agile Triangle—schedule, cost, and scope—are identified as the main constraints. How we set these constraints has a significant impact on the development effort. Do we set constraints for one of these elements or all of them? Do we set aggressive targets, or looser ones? If we want the team to be innovative and creative, setting too many or too aggressive constraints can undermine our goals. One technique I’ve found effective is to create a Trade-off Matrix of scope, schedule, and cost along one axis, and then fixed, flexible, and accept along the other. Each constraint can then have one and only one value. So for example, “fixed scope, flexible schedule, accept cost” would indicate that scope was the most important constraint with limited leeway, schedule would be somewhat flexible (wider tolerances), whereas cost would be the least important with greater tolerances (but still within acceptable limits). This Trade-off Matrix is negotiated between development and product management, and gives the entire team a good idea about relative importance of the constraints. It helps “steer” innovation and design.
Another type of scope constraint is one that often occurs when replacing an existing system. The requirements are often, “duplicate the existing functionality.” While this may not be the most useful constraint in some circumstances (since much functionality may not be used so it should really be deleted), it is a frequent one for many projects. Another version of this scope constraint is building a product that has direct competition where the constraint may be to duplicate most of the competitors functionality before releasing the product.
The bottom line is that constraints provide the delivery team with critical information that helps them be innovative and effective. As such, constraints should be carefully considered because they can guide the team to an effective solution, or done wrong, to one that is awful. Don’t forget to think carefully about this third point on the Agile Triangle.
Published at DZone with permission of Jim Highsmith , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.