Innovation in Software Development Is Leveraged by Laws

This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group.


Pendulums swing between extremes. Agile started out as a freewheeling movement in which there was little place for either management or for “laws;” i.e., cause-and-effect relationships like gravity-and-falling. Everything was to be invented by the “self-directed team,” which, it was assumed, would be more innovative as a result and would always end up doing things the best way.

However, nature, science, and history all tell us there are things to be learned without reinventing the wheel…without breaking the strengths that make Agile so effective. This article discusses how knowing and following “laws” of creativity will release innovation in any level of an organization. 

Main points

  • Following “laws” (or “rules”) can increase innovation in an organization.
  • An innovator needs to know the laws (both for software development and for organizational dynamics) before choosing to break them.

Laws support innovation rather than constrain it

There is a lot of talk these days about software being a craft and programmers are artists.  An artist friend described the similarities between creating art and creating software. There are fundamental laws that apply. In art, there are laws involving how pencil and water colors interact with paper. In software, there are laws like coupling and cohesion.

While I believe there is a great deal of innovation in software development, I also believe there are a lot of laws of software development that one must be aware of in order to be effective.  Most of these laws are very contextual, but many pretty much apply everywhere.  The important thing to me is to take the attitude that these laws are not constraining but instead create a framework for achieving your goals quickly.

This is not just true in software but most any field of accomplishment I am aware of.  The best example I can think of is in the 1960s when NASA was trying to put a man on the moon.  In those days NASA engineers were considered the smartest, most creative people on the planet.  Now, I wasn’t there so I guess I don’t know for sure, but I’m pretty certain the NASA scientists paid attention to gravity and didn’t complain that attending to it was hampering their creativity. In fact, if asked, I’m sure they would have said the knowledge of the rules of gravity gave them the framework from which to be creative.

In the software world I believe it’s the same thing with design patterns.  They don’t constrain you, rather they give you heuristics in order to think both better and faster.  They create a framework from within which to think that can actually enhance your creativity.  In the process arena understanding the laws of product development flow will help software developers do their work more effectively and with more innovation.  I’ll be presenting many of these laws later in this book, I wanted to set the stage as to why they were so important.

Rules enable us to innovate even in music

This concept is especially true in music, another arena many developers point to in an attempt to show we are artists.  Next time you hear two musicians who have never played with each other before jam, pay attention to what they do before they start their jam.  If they are not playing music familiar to each other, you’ll hear them create a common language.  This is often not necessary when musicians have played together before as their past experience is their common language.  Also, when musicians are familiar with a particular type of music, such as jazz or blues, the rules of notes, chords and the type of music provide this common structure.

Music is not just random frequencies, but rather a language and when playing together only certain frequencies (called notes) are allowed.  The key of the music define how different possible notes will sound. Some will sound in key, others off key.  You can get an experience of what I mean by listening to Dueling Banjoes[1].  At the beginning the two players are “talking” in the common language of chords (certain combinations of notes in a particular key) and riffs.  The key and allowable chords are being ‘discussed’.  A banjo can literally play an infinite number of sounds but only a few hundred will make good music.  Even if you slide your hand to get a rise or fall of music you will always start and end on a relatively few places. These are the rules the two players were ‘discussing’ before they started their jamming.

So when musicians jam, they are being creative, but they are also attending to the rules of the type of music they are creating in.   Even in art, the freest form of creation of all, there are rules.   There are rules around paint, color, and more.  There are few areas in art that are truly just a free-for-all.  Most of the impressionists painted very exact real-life paintings until they learned the rules of paint.  But art is a typically a solo innovation.  Rules often exist that enable us to create and collaborate.   Even in comedic improve, there are rules.  Humor is based in tension and surprise – to simply talk without guidance would just be two people babbling. There are rules to comedy and they know this.  Good comedy, of course, doesn’t have you think about it.

Just as rules or “laws” make for better music and comedy, two of the most creative things people do , so too they also release innovation in software development and organizational operation.


You can’t get away from the rules, but you can learn them and use them.  This holds true both for the rules of software development, as well as those for how organizations work.

All that being said, the common adage of “rules are meant to be broken” also holds truth.  There are times you are willing to violate rules to achieve a particular result.  But rules are also meant to be understood before they are broken.