Agile or Not Agile

When is an Agile development effort not so agile?  When you haven’t clearly defined the ultimate objective.  I freely admit that I am not an expert in Agile development so my expectations may not be appropriate but come on now how can one expect to be successful if they don’t know what the ultimate goal is and haven’t defined the key integration points. 

 Ok first a little background:  First my experience is in a more classic waterfall style of product development and this is my first real experience with Agile.  I recently started working with a team that has some fairly aggressive deadlines and they have decided to use an Agile like program methodology to run the program.  We have teams from two different organizations developing code and they need to be integrated together before the product can be released.  Finally, the effort was started several months ago so I’m sure I don’t have all the background.

Now, as I understand Agile development you break the overall program into multiple smaller elements (sprints) such that you can deliver features at the end of each sprint.  At the beginning of each sprint the team determines what features can be developed during the next sprint and the features are moved from the product backlog to the sprint backlog. 

Without question the Agile model should maintain a high degree of focus for the team and if you are meeting on a daily basis it is hard to believe the team could be out of synch at any point in time.  The team I’m working with is holding daily scrums and sprints every two weeks and we are certainly making a lot of progress in a very short time.  However, we seem to be missing our release date, had to make a major architectural upgrade less than a month before delivery and key requirements are not fully understood even though we are within weeks of delivering our product.   I can’t help but ask why is this? 

 Reviewing the program and talking to a number of people who have been on the program since the beginning I have learned the following:

  • The PRD still has not been completed
  • No long term plan was put together to identify when elements from each group needed to come together

 I realize that in an Agile project you can release features at any point in time and in any order.  However, if you are releasing a new product there is am minimum baseline that must be achieved in order for the product to be viable.  If the Product requirements have not been fully defined and agreed to then how do you know if you are meeting the minimum requirements.  What’s more, if you haven’t defined the minimum requirements how do you transfer them from the product backlog to the Sprint backlog.

 Summary:  In talking with others who have participated in successful and unsuccessful Agile efforts as well as waterfall efforts it turns out that inexperienced teams seem to make the same mistake; they forget to fully define the product and the definition of success.  Remember, regardless of what product development model you choose define your product and measures of success first and then if you choose an Agile model Scrum and Sprint until your hearts content.

Share

4 thoughts on “Agile or Not Agile”

  1. User Avatar

    I completely agree with Pradeep. You need a target product defined at least minimally to keep from straying off course. The biggest danger with a completely ‘agile’ approach where customer feedback determines direction is that highly vocal customers can take you away from your product vision and original purpose. Customers don’t care what your business model is, they just want their ideas implemented so they can solve ‘their’ problems. It is very easy to lose sight of the big picture when you are sprinting your way to that next set of key features for that important customer. You need at least one strong visionary in a position of influence to keep this from happening, or you need great processes that force you to check new feature requests against the big picture. This is why guys like Steve Jobs are so important to a company.

    1. Just a point of clarification and a few comments. In well-formed, functional agile teams, the product owner develops and prioritizes the backlog. A good product owner will always balance customer requirements with those of the business and the market.

      Also, agile teams that are working on delivering large pieces of functionality (hopefully, the exception, not the rule) should be driving those releases with both a release plan and release vision.

      Agile has grown up. In the early days (I was there), it was relegated to small co-located projects and teams. Today, agile practices and tools have matured and its being deployed in companies with many 100s (and some cases 1000s) of resources/projects.

      Regards,
      John Scumniotales
      http://www.twitter.com/jscumniotales
      http://agile.scumniotales.com
      http://www.serena.com/products/agile-software/

  2. Hi Ed, two things stand out for me from your article. Firstly the incomplete requirements cannot be compensated for by a development methodology. Agile is better than waterfall in this situation, if you have a close involvement on a daily basis with the customer who can help you refine requirements as you go. The problem appears to be one of scope, which is why the project is overrunning but how do you estimate when you don’t have the whole picture? You are correct in mentioning that you do need a minimum level of requirements to refine before you begin.

  3. Hello Ed,

    I picked up this post indirectly through a tweet I received. It sounds like the program you discuss above is following some of the agile best practices (incremental development / sprints at least). But the thing to remember is that agile is a system of related activities. To get the hyper-productivity that is possible, you’ve to consider all of them. Check out my post at http://agile.scumniotales.com/2009/07/why-scrum-isnt-enough-for-agile-success-.html for more info.

    It also sounds like the “Product Owner” role is not being performed effectively (responsible for defining requirements / user stories and prioritizing the work for the team).

    You may want to consider an Agile Coach for the team. Depending on the scale of your project, the tool my team has built (which has a built-in coach!) may help as well.

    Best of Luck,
    John Scumniotales
    http://www.twitter.com/jscumniotales
    http://agile.scumniotales.com
    http://www.serena.com/products/agile-software/

Leave a Comment

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

Scroll to Top