Services have business value

When you are on a project which is about evolving a set of services from an existing application, or building from scratch, there is always a lot of talk on the architecture and service governance aspects.

But if you are a Business Analyst on this piece of work, and you are asked to write stories for these services, you will wonder.. "well how can we showcase just services ?". If you have never done this before, you might even conclude that writing stories without a consumer of the service is not such a good idea. A lot of Agilists might argue that having a services story is a bad user story.

This happens because the fact that "Each Service has business value" does not become very apparent. If you look at Amazon WebServices it becomes immediately evident that each of the services have a set of features which can be sold to customers.

Services are a reality in today's world on the web, and people make money by selling services. A story which builds a service to search a book based on ISBN has business value. It does not need to have a pretty front end consumer for you to write a good user story. A temporary client/UI would be sufficient or maybe even functional tests/specs. It is still a good user story. This essence needs to be spread across the entire team, so that BAs and Devs are on the same page on "Good User Stories" for this kind of project.

Both BAs and QAs have to embrace this along with the developers on the team, and look at ways to apply Agile principles considering this, rather than being dogmatic in their approach towards Agile and SOA.

Challenges in applying Theory Of Constraints to Agile Software Development

After finishing Goldratt's first book, the Goal, I immediately jumped to David Anderson's book on Applying TOC in Agile Management. Preetam also has left some interesting comments on my blog on the differences between s/w and manufacturing which should not be neglected.

One important thing which is still puzzling me at this stage is, if you have to account for throughput, how do you measure value. Value here is the value of a story or a feature. If you are a services shop building an application for a customer, it is upto the customer to determine this business value of a story. Quite often this is not easy to determine, specifically for people like Subject Matter Experts you are dealing with to gather your requirements, who do not deal with sales at all.

In a manufacturing plant, if you have signed a contract to deliver 10 cars for say $100,000. The cost of an engine still waiting in the queue (work in progress) is almost equal to the value of 1 car, $10,000. However the similar analogy is not easily applicable to a software development team. If a story is in progress, it cannot be easily translated to how much $$ is part of inventory.The story might be part of a bigger feature. Also, determining the business value for that feature in $$ itself can be tricky

David's book touches upon in-house IT shops providing IT services (eg: SaaS) or implementing a software product. In these cases, revenue from Sales can be directly mapped to what is being developed. Which is what should happen, in order to increase the throughput of the system, and hence increase the revenue. This is not the case when you are providing IT services to other clients (not in-house).

Some might say you can use story estimate (ideal days or points). Again this represents cost and not value. The iterative nature of Agile also makes it difficult to apply the same principles as a manufacturing plant.

While I am still looking for some answers, the learning on how to deal with bottlenecks, optimizing the whole system, and applying the same to software development, from both the books, are still quite useful.