You Can’t Call Yourself Agile If…

Is your business Agile? If you answer “YES” to any one of these, there’s work to do.

  1. Teams are organized around software components or network elements. (e.g. O/S, middleware, application)
  2. Teams are specialized around competencies like design, architecture, test, and product management.
  3. Phase gates exist where a team hands-off partially completed work to another team (e.g. coded features handed off to test teams).
  4. Teams commit to a set of features months in advance of the delivery date.
  5. There is detailed up-front planning.
  6. Command and Control management. Managers at different levels make the decisions and assign the work.
  7. Teams are interrupted and asked to do something new before they finish work in progress.
  8. Time is spent defining terms and conditions for hand-offs of work between teams. (i.e. Internal contracts)
  9. Product defects are tracked in a backlog and fixed later.
  10. There is more than one “Priority 1” work item.

I’ll bet you can think of many others!

The challenge of enterprise Agile transition can be daunting. But if you truly value:

  • Individuals and Interactions over Processes and Tools
  • Working Software over Comprehensive Documentation
  • Customer Collaboration over Contract Negotiation
  • Responding to Change over Following a Plan

…then you can make value-based decisions that will help you create an Agile business.


2 thoughts on “You Can’t Call Yourself Agile If…

  1. Nice list of smells! As you say, one can easily list many more.

    But, I don’t fully agree with “9. Product defects are tracked in a backlog and fixed later”. Sometimes I think that this can be the correct behavior. If it’s a defect found in code developed by the team right now (in the current sprint), of course it should be corrected and re-tested immediately (within the sprint before sprint demo). If it is a serious blocking life (or money) threatening defect found in a live production environment, of course the team should drop whatever they are doing, fix it and deliver a patch ASAP. Everything in between should be converted into a User Story, given a business value and put into the Product Backlog. I don’t think all defects should be fixed by default. What if the work effort is huge and the business value low for the defect-fix – shouldn’t the team focus on delivering other Stories of higher value?

    As long as the Product Owner makes a conscious prioritization decisions (and a risk/consequence analysis for NOT fixing the defect) I think it is ok to track some defects in the product backlog and [possibly] fix them later.

    Best Regards
    /Jimmy Janlén

  2. Hi Jimmy,
    I distinguish between defects, field issues, and “defects” that should be User Stories (new features). I could have been more clear. Known defects that are not fixed in-Sprint and then added to a defect tracking database for later fixing “when we have time” is what I was referring to. I also had waterfall on the brain when I thought about # 9.

Leave a Reply

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

You are commenting using your 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