Choosing Methodologies

These days, most professionals have a few, if not several experts in their profession they follow with blogs, LinkedIn articles, tweets and any publications they make.  Outside of that, when a particular need arises, most use the typical search engine of choice to find all relevant topics to get a sufficient answer in the shortest time possible.

Well, if you ask Uncle Google or Brother Bing about how to choose a software delivery methodology, you will likely get the following:

  • Short blogs that are out of date and give fragments or partial advice
  • White papers that don’t seem to provide any clear direction (just descriptions), are out of date with current methodologies or not enough detail to truly follow

So, you are likely wondering why can’t one find that “prescription for success”.  We all realize that it’s not that easy and will never be since methodologies should be based on unique enterprises with unique engagements.  There is no such thing as a “silver bullet” in methodologies.

If you go to the sites of popular methodologies such as PMI.org, scrum.org, scrumalliance.org, Scaled Agile or Less.works to name only some, they promote their own methodology to the removal of all other options.  Even when comes to the “winning guidelines”, consulting agencies that should have the most experience providing this won’t because even though they will usually say, “we have the better methodology”, they don’t wish to give away their trade secret, since that is often one of the primary competitive differences and short of the talent of their consultants.

However, organizations all the time have tried Agile and failed.  So, why are there so many delivery failures?

That’s a huge question with a myriad of answers.  Answering that question fully is far beyond the scope of this simple blog, so will zoom the focus into process delivery, still a huge swath, but more reasonable to cover.

The main point heard by Agile Practitioners is that “Agile is easy to understand, but hard to master”.  If it was easy to master, everyone would have successfully adopted it over 15 years ago.  So some key factors as your guidelines to that mastery includes the following derived from the Agile Manifesto:

  • The process MUST ALIGN with the business
    • Don’t break the business processes, but instead transform them
  • If a methodology is followed too rigidly, it will break
    • Flexibility must be “baked” into the mindset of delivery to respond rapidly to change
    • For instance, rigidly requiring all standard scrum ceremonies without inspecting and adapting would be a poor practice
  • Never stop changing and improving
    • The global economy and hence down to your organization is always changing
    • So is your processes which must always be in flux
    • Be bold and don’t settle on only micro-changes

Often, many people within an enterprise are threatened by Agile and activity attempt to sabotage it.  This typically involves middle management and traditional project managers.  Having gone through that transition myself, I can understand the fear and uncertainty of taking a previously proven process and attempting to adopt something new, especially when it requires a fundamental change in delivery which threatens positions and one’s career.  Why would I support a new methodology if it may threaten me my job?

However, the wheels of progress inevitably rolls on and as the new generation and future employees embrace Agile methodologies, existing management will have to adjust or be forced out.  This is a fact, not a belief.

Advertisements

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