Agile AdoptionAgile MethodsscrumSoftware Development

Reducing Risk and Avoiding Pain – Agile Lessons Learned (Part 2)

Hello All,

As you might remember from my previous article, we were reviewing the lesson’s learned that are covered in Jim Dempsey’s Webinar presentation entitled “Agile Lessons Learned.”   His next webinar is currently scheduled for May 17th, 2011.  Click here to register for Jim’s Webinar on the ITMPI Website.  To see a full listing of the scheduled webinars in 2011 through ITMPI go to

If you remember, Jim’s webinar presentation identifies 19 lessons that he has learned over the past five years implementing Agile development projects.  In my last post, Reducing Risk and Avoiding Pain – Agile Lessons Learned (Part 1) we covered the first 3 lessons:

  • Lesson 1 – Agile is Difficult
  • Lesson 2 – You Need an Evangelist
  • Lesson 3 – Train the Business

In this article I will cover 3 more of Jim’s Lessons Learned:

  • Lesson 4 – Determine if your project is a good candidate for Agile
  • Lesson 5 – Prepare the Product Backlog before Sprint 1
  • Lesson 6 – Build a Release Plan

Lesson 4 – Determine if your project is a good candidate for Agile.  I bet you thought that Agile was the solution to all of your project needs!  But the truth is, Agile is not always the answer.  If the organization is not ready for an Agile implementation, there is a strong chance that it will not be successful.  A number of key factors must be considered in determining if the project is a good fit for Agile.  Some of these are:

  • Sponsor/Executive buy-in
  • Team buy-in
  • Team’s experience using Agile
  • Team size
  • Level of geographic distribution
  • Level of expected requirements change
  • Availability of customer resources to support Agile
  • Requirements familiarity
  • Regulatory requirements
  • System complexity
  • Technology familiarity

Construx Software developed a scorecard for determining if your project is a good fit for an Agile implementation.  This type of scorecard should be considered prior to any project initiation.

Lesson 5: Prepare the Product Backlog Before Sprint #1.   You might be inclined to begin developing your Product Backlog during the first Sprint Planning Meeting.  We made this mistake in some of our early projects and got us off to a rough start.  You should hold a separate planning activity to create your Product Backlog prior to the start of Sprint 1.  This should be done with the Product Owner and the entire team should be involved in estimating using a technique like Planning Poker.  The initial Product Backlog should then be prioritized and each story should have a clear statement of what constitutes “Done” for each of the stories.

Lesson 6: Build a Release Plan. Engaging in an Agile project does not mean that you throw planning out the window.  In fact, that could not be further from the truth.  We do an enormous amount of planning in our Agile projects and one of these plans is the Release Plan.  Alistair Cockburn states that:

The purpose of release planning is to establish a plan and goals that the Scrum Teams and the rest of the organizations can understand and communicate. Release planning answers the questions, “How can we turn the vision into a winning product in the best possible way? How can we meet or exceed the desired customer satisfaction and Return on Investment?” The release plan establishes the goal of the release, the highest priority Product Backlog, the major risks, and the overall features and functionality that the release will contain. It also establishes a probable delivery date and cost that should hold if nothing changes. The organization can then inspect progress and make changes to this release plan on a Sprint-by-Sprint basis.”

In creating your release plan you should consider the following key points:

  • The Release Plan will be used to determine if the project will generate enough ROI to make it worthwhile;
  • You should specify a Release 1 Go-Live Date;

–      Fixed date determined by business, or

–      Date determined by projected completion of critical functionality.

  • You should continually revise and refine the Release Plan.

In part 3 of this series, we will cover the next 4 Lessons Learned from Jim’s Webinar series:

  • Lesson 7 – The Sprint Planning Meeting will Make or Break the Project
  • Lesson 8 – Manual Tools and Techniques Work Great
  • Lesson 9 – Requirements are Still Important
  • Lesson 10 – People are More Important than Process and Tools

Have a great week!


Related Articles

Back to top button

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.