Earlier this week, I discussed the common misunderstandings related to the first two statements made in the Agile Manifesto — Individuals and Interactions over Processes and Tools, and Working Software over Comprehensive Documentation.  In that discussion, I focused on how important it is to remember that the Agile Manifesto itself was written largely in response to traditional “Waterfall” methods of product design and development.  There was never any intent on the part of those who created the Manifesto to shift the focus entirely to the “left side” of the spectrum — but rather to propose a spectrum that was more responsive to change and that could accelerate the delivery of value to interested stakeholders.  While these original concepts have brought forth many different specific approaches, the fundamental purpose of the Manifesto remains important in understanding when, where, and how to implement such practices, and why you should do so.

Customer Collaboration over Contract Negotiation

One of the hallmarks of traditional Waterfall approaches was the manner in which requirements were seen as a “contract” between the business and the development team.  And, much like how contracts are created and used in the business world in general, so were these contracts the subject of hard-line, strong-arm negotiations, using money and resources as bargaining chips.  And, once finalized, these contracts were strictly abided by – unless there was something “approved” by change management, the requirements were what was delivered – no more and no less.  Line by line, note-for-note, every single enumerated value was executed against, whether it made sense or not.  There was no flexibility, there were no variations accepted.  And everyone was judged not on the success of the product or the project, nor on how the users accepted it — but on whether or not the contract was delivered as agreed.

With that in mind, one of the primary purposes of adopting an Agile (or even “agile”) approach to your products is to get as much information about your efforts as soon as reasonably possible — the more time and money you spend to test something, the bigger the waste involved if it winds up not meeting the market’s needs.  This is why it’s important to have your daily scrums be open to anyone who wants to attend; why you invite stakeholders to sprint demos; why you involve your development teams with your customers, prospects, and stakeholders on a consistent basis.  You want to know what’s going through the minds of your users, your customers, and your stakeholders.  This is not to say, however, that you don’t have requirements — you do.  And it’s also not to say that there aren’t some level of negotiations that go on — there are.  The point here is that the goal is to work in a collaborative fashion, so that the development teams can get the information that they need, when they need it, and from the people who know best what should be done.  Ideally, this is the customer themselves; failing that, it’s an internal customer proxy, or at absolute worst the opinion of the Product Owner.

Responding to Change over Following a Plan

You would think that this particular precept of Agile wouldn’t be terribly controversial — it’s always better to be responsive to change than it is to strictly and blindly follow a plan that becomes useless upon further analysis.   The days in which companies could create a 12-month or 24-month plan that was specified down to the exact feature level are gone — though, as anyone can tell you, they never really existed in the first place.  Such “plans” gave the business a false sense of security — the belief that the future was predictable, that customers could be promised things, and that the market would remain stable enough over that time that what you thought would be important in the future actually would be two years from now.  In today’s hyperactive markets, that’s simply impossible — things change too fast, competitors pop up overnight, and customers’ needs change just as quickly.

On the other hand, there are those in the world who seem to think that you can create successful software without any long-term planning — that you can iterate over and over and just pick the most important thing at the time you have to execute to succeed.  And, they’re right — you can build successful software that way.  Unfortunately, most software isn’t being built just to build software, nor just for the whims of the developers.  Rather, software is being built as part of a business, with the intent to monetize that software in some way — and to be a successful business requires some concept of a plan.  Businesses require investment, they require customers, they have investors that want to feel like their money is being spent well.  All of these things require some level of planning — something between “nothing” and “24-month, feature-specific” plans.  The goal here is to have a good enough idea of where you want to go (a “product vision”) that you can make prioritization decisions based on those ideas, but to not take it so far that you’re bound to specific deliverables.  In another post, I discussed how one can create a 60/90/180-day view of what you want to do and where you want to go.  The idea here is that you can plan on what you are currently executing, you can queue up you next set of priorities, and you can predict what major themes you’re likely to target in the further future.  This balance between having a plan and adjusting to change is what was in mind when this statement was made by those who created the Manifesto.

In Closing…

As I hope I’ve demonstrated in these articles, it’s really important when considering what Agile “means” to recall its origins, and what those who created the Manifesto were reacting to.  Further, we should all realize that going too far in one direction or the other creates problems when we apply those principles to the operation of a business.  Finding that proper balance between the “left side” and the “right side” of each spectrum is essential to creating valuable software that customers will be willing to pay for and that investors will be willing to buy into.