Tuesday, October 5, 2010

Delivering features based on Business Value

Agile software development emphasizes on delivering functionality on highest business value. What this means is, to prioritize the product backlog based on features that are most valuable to the end customers.

I often give this example to new teams transitioning to Agile development. Taking "Microsoft Word" as an example, I ask the team if I consolidate overall functionality in Microsoft Word to 100 features what percentage of features do you think you use on daily basis? The poll within the team normally reveals 25 to 30 features. So, for all intense and purposes Microsoft could have released "Microsoft Word" to production with 30% of the functionality and satisfied the mass customers - thus delivering features based business value.

If Microsoft used the traditional waterfall (which they mostly did) or Spiral approach of generating all requirements upfront, designing, coding, testing, etc they would spent years working on the project before making the first release. In the Agile approach, keep delivering features in a time-boxed interval that the customers value most and once product is deemed feature-rich, release the same for general consumption.

There are several advantages of delivering features based on business value.

  1. To meet one of the 12 Agile principles from the Agile Manifesto, "Simplify: maximizing the amount of work NOT done".
  2. To work only on features that adds most business value to the customers.
  3. To collect quick feedback from the customers to ensure functionality delivered to the customers meets their requirements to satisfaction.
  4. To release product with fewer or no defects to the customer as only minimum features with highest business value to the customer is coded and shipped to the customer.
  5. To beat the competition by getting to market first.
To summarize, product owner should prioritize the product backlog with features based on business value, and teams should only work on features that add value to the customers.

Sunday, October 3, 2010

Diminishing ROI with NO Automation in Agile development

My interaction with various clients that are in process of transitioning to Agile often ask this question - Is it ok to skip automated Unit and Acceptance testing and only perform manual testing? The reservation normally arises due to old school of thought where manual testing was tolerated and where CLIs and API needed for testing are normally an after thought. Sometimes it is also because QA engineers are manual testers and have no needed programming skills. And at times people tell me Automation takes time off from active feature development and is an overhead.

No matter what is the reasoning, I always preach to these teams, "Automation is a rule and not an exception" and I try to justify my statement using the example below.

The diagram below, "Agile with No Automation" helps illustrate the impact of skipping automation totally, causing diminishing ROI. The goal of each sprint should be a running software that is fully tested, integrated and potentially ready to ship. To meet this goal all features have to be regression tested at end of each sprint.


For the purpose of this example let's assume Scrum team is able to do the same amount of work each Sprint and each feature is of same size.

  • In Sprint 1, the scrum team completed 3 new features without any automated tests. All testing is done manually to meet the sprint goal.
  • In Sprint 2, the team is only able to complete 2 features as the time needed to develop the third feature has to be used to perform manual regression testing of 3 features developed in Sprint 1.
  • In Sprint 3, the team will be able to complete only one new feature as the time available for remaining features will be used for manual regression testing of 3 features from Sprint 1 and 2 features of Sprint 2 in addition to performing manual testing the new feature delivered in the current sprint, i.e. sprint 3.

As you see in the above example, every new sprint team is spinning wasted cycles doing manual regression testing the old features which could have been totally eliminated if all tests are automated.

Now, let's consider this scenario where all tests Unit and Acceptance tests are automated each sprint with illustration in the diagram below, "Agile with Automation".


  • In sprint 1, the scrum team completed 3 features and all test are automated. When the team says done, they are indeed done - everything coded, tested, integrated and working software.
  • In the following sprint, i.e. sprint 2, the scrum team will be able to complete additional 3 new features as regression testing is automated. Remember, it is machine time as opposed to laborious human time spent running manual regression tests.
  • In sprint 3, the team develops 3 additional new features without worrying about regression testing the old features.

Automation gives developers and quality assurance engineers enough confidence to make the necessary changes in the code base thereby generating a potentially shippable product every sprint.

The above example shows that ROI without automation is 6 features and in the same time frame the ROI is 9 features with automation.

Remember, to reap benefits of Agile Software development, "Automation is the rule and not an exception".