Agile pondering: Why use an agile approach?

The theme of the blog this month is “Getting a Fresh Start.”  In order to get a fresh start it is important to know WHY you want to do it!  I’ve seen many presentations over the years about why agile is something a software development organization should use.  I’ve seen this sort of presentation called “The Business Case for Agility” and several other names.  I’ve seen people walk out of those presentations, go back to their organizations, implement agile – and fail miserably.  Clearly having a reason for using agile is not the only important thing.  I think many of these presentations are presenting some possible reasons for using agile, but they sometimes miss a key point – WHY are those reasons important.  In the spirit of Agile For All’s second agile belief, I’m going to try to explain WHY some of the popular reasons are important to consider.

Know why, not just how. Too many people are learning the “hows” of agile and not the “whys” that drive successful process. This causes much more failure than is necessary. We always teach whys and not just hows.

Having worked with clients that range from very small to very large I’ve observed an unusual trend.  Each client believes their problems and issues are unique because of their corporate culture, industry, people or something else.

However, I’ve also observed another unusual trend which goes directly against the first one.  Most of the time my clients are wrong in the belief they are unique!  Certainly there are some differences.  That has to be true or every company would be identical.  Many times even the ways the problems manifest themselves are different.  I know that sounds strange.  How can the problems be different if I just said the problems aren’t unique?  I’m not looking at the problems, I’m looking at the CAUSES!  The underlying causes are the same or very similar but the way those causes manifest as problems may be different!

Below are 5 of the popular reasons given for switching to agile (and one extra I added because I could).  I’ve added the problems typically addressed, but I’ve also added some underlying causes and WHY an organization would might see those results and want to address them.

Reason Problems Causes
Better team morale and job satisfaction
  • Team beaten down
  • Lack of collaboration
  • Us vs. Them mentality
  • Project failures
  • Company culture
  • Recent layoffs
  • Not co-located
  • Time zone differences
  • Organization structure
  • Poor management
  • Poor metrics
  • Improper incentives
  • Poor estimation
  • Lack of product success
  • Lack of accountability
Higher customer and stakeholder satisfaction
  • Late product delivery
  • Missing features
  • Broken promises
  • High defect rate
  • Difficult to use product
  • “Not what we expected”
  • Unrealistic deadlines
  • Scope creep
  • Lack of product vision
  • Lack of project focus
  • Poor work prioritization
  • Over promising
  • Poor metrics
  • Poor management
  • Organization structure
  • No way to collaborate
  • No customer involvement
  • Lack of accountability
  • Big bank delivery at end
  • Lack of acceptance criteria
  • No concept of project value
Improved product quality
  • High number of defects
  • Defects found too late
  • High support costs
  • Difficult to deploy
  • Testing late in the process
  • Lengthy dev cycle
  • Lack of support training
  • Lack of dev unit testing
  • Lack of automated testing
  • Organization structure
  • Different dev and QA orgs
  • Big bang delivery at end
  • No attention to defects
  • Features first attitude
  • No standard SCM
  • No deployment standards
  • Lack of documentation
Faster time to market
  • Late project delivery
  • Losing market share
  • Fast changing market
  • Customers are fickle
  • Fast moving competitors
  • Behind on features
  • Unrealistic dealines
  • Scope creep
  • Organization structure
  • Improper incentives
  • Lengthy test/fix cycle
  • Testing late in process
  • Big bang delivery at end
  • Intolerant to change
  • No customer involvement
  • Poor estimation
  • Change is difficult
  • No ability to kill projects
  • No concept of project value
More tolerance for change
  • Missing features
  • Can’t react in time
  • Features never right
  • Chasing competition
  • Everything treated as priority 1
  • No customer involvement
  • Unrealistic deadlines
  • Poor estimation
  • Organization structure
  • Lack of product vision
  • Lack of project focus
  • Too many “shiny objects”
  • No feedback during dev
  • Big bang delivery at end
  • Too reactionary
  • Inflexible planning
  • Lack of risk mitigation
  • Poor work prioritization

We aren’t insane!
Doing the same thing over and over again and expecting a different result is the definition of insanity.
  • Everything already listed
  • Everything already listed

This list is FAR from exhaustive.  I am sure there are 20-30 items in causes I have not listed.  I just wanted to make the point that the obvious problems being “solved” by agile actually trace back to potential issues which may are may not be directly addressed by an agile process.  For example, will organization structure be addressed by switching to agile?  Probably not, but it WILL be exposed as an issue if agile is done properly.  Organizations need to be prepared for 2 possibilities for each problem: 1) it is caused by agile, or 2) it is exposed by agile.  Most problems will be of type 2 and very few will be of type 1.  Some things may be caused by agile, such as the stress it causes as teams get used to meeting iteration deadlines.   However, most problems will be of type 2.  Are you ready to admit it and deal with those as they are exposed??? [note, this technique is based on a blog entry by Vikrama Dhiman where even more details for a good retrospective can be found]

I know the table above has a LOT of entries in it.  If you don’t understand one please leave a comment and I’ll try to clarify it.

Are you depressed now?  Don’t be.  Agile really can help solve most of those problems simply by exposing them!  It is often too easy to hide the elephant in the room.  Get it exposed then deal with it and your organization will get better!

Until next time you should look at the list of causes and see how many fit your organization.  After doing that exercise maybe you should call (303-766-0917) or email me so I can help you in Making Agile a Reality® for your organization!  I’ll offer 30 minutes of free agile or scrum coaching to the first 10 people who email me mentioning this blog entry.  The coaching will start out via email questions, but will include a phone conversation if necessary.  If your organization is struggling, let me help!

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Bob Hartman

Known as Agile Bob, brings over 30 years of experience and broad industry knowledge cultivated by serving in almost every role in the software industry including developer, tester, documentation writer, trainer, product manager, project manager, business analyst, senior software engineer, development manager and executive. Over the past 15 years Bob has grown from being an early adopter of Agile to his current status as a Certified Scrum Trainer® (CST) and Certified Enterprise Coach℠ (CEC) and an expert in training, coaching and mentoring across all areas of Agile development. Bob is a popular speaker, having spoken at numerous major conferences, seminars, workshops and user group meetings where his engaging style, holistic view of development and personal anecdotes are always well received by attendees.

Connect

bob.hartman@agileforall.com Twitter LinkedIn Subscribe to RSS Feed Blog posts by this author