Agile Zone is brought to you in partnership with:

Jim Highsmith is an executive consultant at ThoughtWorks, Inc. He has 30-plus years experience as an IT manager, product manager, project manager, consultant, and software developer. Jim is the author of Agile Project Management: Creating Innovative Products, Addis Wesley 2004; Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Dorset House 2000 and winner of the prestigious Jolt Award, and Agile Software Development Ecosystems, Addison Wesley 2002. Jim is also the recipient of the 2005 international Stevens Award. Jim is a DZone MVB and is not an employee of DZone and has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

Constraints Drive Innovation

  • submit to reddit

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, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Ian Mitchell replied on Sat, 2013/07/06 - 3:37pm

That's an interesting article, and invites comparison with Goldratt's "Theory of Constraints" on throughput, operational expense, and inventory. Perhaps those particular constraints are more applicable to "business as usual" (BAU) work, whereas the triangle of scope/cost/time might be more relevant to projects.

I think it's interesting that (for project work) quality is generally held to be invariant, while it isn't necessarily the case for BAU. Quality of Service, for example, is often allowed to flex.

Constraints do help to drive innovation - necessity being the mother of invention - though sponsorship and competitiveness are often needed to translate these efforts into wider success. For example, agile ways of working are unlikely to gain traction without organizational sponsorship, and a healthy marketplace which underpins the demand for these new skills.

Let's remember that the European Renaissance took place in a society that was operating under enormous constraints, and may not have happened at all without the sponsorship and competitiveness of elite Florentine families. I can't help but think that if those Native American artists (whose work you saw) had received similar sponsorship during the Depression, the product lines of Cartier and Tiffany might have been rather different.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.