Agile Consistency Without Reams of Specs

My first actual article on this site was explaining my take on three tiers of consistency within software and assuring that a software program provides an experience where a user can expect things to be consistently intuitive and behave based on the user’s expectations.

Consistency in the Waterfall

Putting on the old man costume, one might muse a bit about the good old days of waterfall software development when everything worked out perfectly because we had reams of specifications for each project. The specifications must be right because they had sign-off by someone important and we had a big stack of change control paperwork for each modification!

Stepping off the sarcastic soapbox for a moment, I will note that implementing consistent behavior wasn’t likely easier in the waterfall days, but it was probably less ambiguous. One could always look up requirement 11.4.5.8 where it specified how something should work and compare the software to the letter of the requirement.

The Agile Consistency Dilemma

When we transition to a more agile way of building software, where we value

Working software over comprehensive documentation

how do we ensure consistency in the absence of pile of specifications?

Consistency by Communication and Familiarization

Looking at the three aspects of consistency I wrote about previously, we have:

  • Consistency within a given application
  • Consistency across applications within the line of business
  • Consistency with industry norms and trends

Within an application or across a line of business, we can help facilitate consistency by enabling and facilitating communication within the development team. Developers that chat and communicate about how they’re solving problems are likely to solve those problems in similar fashion.

Familiarization with products can help prevent reinvention of the wheel. If your company has six products, a developer ought to have end-user knowledge of all six such that when implementing a new feature they would know how that feature, interface, or workflow might already be in place in a different program. This seems like it would be obvious, but I can recall several cases where I’ve raised an issue of inconsistency across products (by the same organization) and the developer indicated that he or she had never seen that other product.

Consistency failures are often failures of innocent ignorance… the developers aren’t being inconsistent with intent. They’re being inconsistent because they aren’t aware. Increasing awareness increases the consistency.

Take that day or two that you might have spent reviewing specifications and go work with the software.

As an added bonus, that time spent communicating about consistency? Your developers will also communicate about other things and build a more cohesive team.

Advertisements

One thought on “Agile Consistency Without Reams of Specs

  1. Hi Aaron,

    I thought this post was about the consistency of Agile as a methodology – which is another issue that perhaps you’ll be able to cover in a future post.

    Agile is inconsistent because it’s a set of good practices – and not by-the-book methodology (such as the PMBOK).

    In any case, I would like to republish your post on PM Hut – please either email me or contact me through the contact us form on the PM Hut website in case you’re OK with this…

Chime in with your thoughts

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s