Predictability in Software Development – Part II

My previous post asserted that predictability at the business or organizational level is having teams that consistently deliver solutions that enable desired business outcomes. These organizations and business are predictable in the large.  Predictable organizations have the ability to change course even as the ecosystem they are a part of changes.  Ergo,  my second assertion:

Your company values adaptability over predictability 

This is not to suggest that predictability is not important.  In fact, it is quite the opposite. In the ever-changing business landscape that now confronts us, organizations are required to adapt in order to survive.  In order to be predictable, organizations must be able to adapt.

(I will concede that it is possible that your business cares about predictability more than it cares about anything else.  I just don’t interact with a lot of those organizations these days.)  

Organizations that possess a high degree of adaptability have the capacity to change course in a largely frictionless manner.  They have the characteristic of responding to changes in the ecosystem and changing direction as needed, effectively and efficiently.

An organization can only adapt as quickly as its component parts can adapt.  More specifically, a product organization’s ability to adapt is a function of their individual product development teams ability to adapt.

Agile places tremendous value on teams being able to adapt as change emerges.   In fact the Agile Manifesto states that we value:

Responding to change over following a plan

and backs that up  with following the principle of:

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage value number

Many Agile practices enable teams be in position to respond to change in a productive manner.  Here are a couple of them (in case you’re not familiar with Agile practices):

  • Focusing on the “what” over the “how”
  • Working in small increments of value (days not weeks or months worth of work)
  • Short delivery cycles; weeks over months
  • Stakeholder feedback on a regular cadence
  • Pair-programming/test-driven development
  • Continuously running automated test suites that validate product suite
  • Feature teams developing features
  • (I’m sure you can add more to this list)
  • Etc etc etc

Teams that leverage all these practices (and more) are in a position to respond to change very effectively.  I find however that many organizations that claim to “be Agile” are only partially committed to a few of these practices and then wonder why it’s so difficult for them to change direction.  Coincidentally, these organizations seem to also believe that Agile is about delivering software faster.  (If that’s you, it’s possible that you’ve been misled).  To top it off, these organizations often respond to their inability to adapt by instituting heavy processes and protocols that are focused on ensuring that they won’t have to adapt!

Here is a thought exercise for you: If at this very moment, your team was asked to stop working on a particular initiative and release it into production so that your customer could start using it and the team could start working on a different mission, would your team be able to do it?  How many days, weeks or months would it take for your team to be able to release a product increment at this very moment?  Would you be able to release anything at all?

If an organization desires to be predictable in the large, its teams need to be able to effectively adapt in the small.  When teams holistically adopt Agile-based approaches to software development, they place themselves in a position where they can respond to change in a predictable way.  Could your organization and teams benefit from this ability?

But wait, we’re not done yet.  There is the little matter of predictability in the small. My next post will be about that.  Stay tuned!

Advertisements

About Ebenezer

culture hack. contrarian. change artiste. speaker. writer. silo-connector. entrepreneur. totally human. ff at your own risk. :-)
This entry was posted in Software Development and tagged , , , . Bookmark the permalink.

2 Responses to Predictability in Software Development – Part II

  1. Pingback: Velocity is NOT about Productivity | Ka anyi kwuo okwu (Let's Talk)

  2. Pingback: Predictability in Software Development – Part III | Ka anyi kwuo okwu (Let's Talk)

Leave a Reply

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