One of the main strengths of agile methods is their focus on value-driven development. Whether we are planning releases, prioritizing features, or writing tests, we need to always ask the question: does what I'm doing provide any business value? Because if it doesn't, we simply should not be wasting our time doing it. For example, after long battles with traditional practices like elaborate documentation of requirements and design, we have come to know that writing lengthy documents in itself does not provide business value.
But what is business value?
Different academics and practitioners have their own perceptions as to what constitutes business value. The most common understanding I have seen though is that business value has to mean something to your end-user. Somewhere in the definition you need to find the word 'customer' or 'user'. For instance, a work item X is said to have business value if it provides usable and useful functionality to the 'end user.' A test T has business value if it provides a guarantee that the system will not crash when the 'end user' attempts to do a given task. A document has business value if it enables the 'customer' to prove their conformance to ISO 9000 for example.
Keeping business value in our radar is as important as any other principle in agile development. A good understanding of what creates business value to the customer reflects good requirement elicitation practices, effective communication with the customer, and a higher probability of delivering something that is useful and usable.
Estimating/measuring business value
Ask anyone who went through the exercise of estimating the business value of something, and they would tell you it is not an easy ride. Putting a value tag on a story card or a feature is very tricky. For one, we need to have an excellent understanding of the big-picture in order to measure value in relative terms. What seems very valuable to someone who just joined your team may seem to you absolutely valueless given the other things you have in the backlog. The second reason why estimates may be difficult is due to the concept of 'total value'. Mike Cohn did an excellent job explaining this concept. But in summary, the value of certain parts (e.g. stories) of a larger entity (e.g. system) may be too difficult to measure because without these relatively small parts, the entity as a whole is useless. Think about the value of the screen of your laptop!
I strongly recommend that you read Mike's blog post on this topic.
Does business value have to be customer-centered?
I believe it should not. I will explain this further.. not today though.
So..
If you want to take one thing from this short summary of business value, then here you go: question everything you do in your software development to determine whether it is worth the effort or not. Be it a feature, a process, or any other thing that consumes your time, always ask: Does what I do have any business value? I have a colleague who conducted research in a major IT company to study the flow of information through the organization. He traced a lengthy report that was regularly produced by one department in the company and had to go through a number of review processes. Eventually the report would land in Juan's drop box. Juan had left the company 2 years ago.
Friday, March 30, 2012
Thursday, March 29, 2012
The software looks good... All you need to change is what it does!
It is not fun when projects go miserably wrong. Luckily enough for us, software engineers, we got used to it. In a recent project I have been involved with as a volunteer developer, we had to face a very brutal reality as we were getting ready to release the product. The product did not meet the expectations of the user group in the organization. For one, it was perceived as counter-intuitive. And secondly, major objections arose by different members of the organization. It was too late to fix all the issues in time, and therefore, we had to postpone the public release.
What went wrong?
Well.. It is difficult to blame the failure on a single reason. And there is really no point of pointing fingers. What matters here is that we have all come out of this learning many lessons. Here is a few off the top of mind:
- Iterative development was called "iterative" for a good reason. Because it should be. While we were in fact developing our project in iterations, we were not effective at showing the actual end-product to the user group to obtain their feedback at the end of every iteration. So at the end of the day, the iterative notion was not REALLY there. When we finally demoed the product, we got bombarded with comments and questions about the absence of certain features, and the inclusion of others.. etc.
- The main business processes should be clearly defined. The flow of certain key processes and the financial aspect of the product were not clear in the minds of the business representatives. Being agile enough to accommodate changes in the process is absolutely important. But when the key processes are vague, chances are we are going to build the wrong product.
- Business decisions should be taken and owned by business people. Because of the previous point, some business decisions were taken during technical meetings by the business representatives in a very ad-hoc and informal manner. It turns out that the decisions had not been sufficiently discussed with the people involved in the process. When the product was demoed, you could see all kinds of facial expressions. Surprised.. amused.. disappointed.. indifferent.. tearing. Most importantly, nobody owned the decisions that had been taken and therefore we were simply asked to wait for a reconsideration of such decisions.
God bless Agile methods! They are there for a reason. And you will never get to appreciate the thoughtfulness of the Agile approach to software development until you experience a not-so-agile one.
What went wrong?
Well.. It is difficult to blame the failure on a single reason. And there is really no point of pointing fingers. What matters here is that we have all come out of this learning many lessons. Here is a few off the top of mind:
- Iterative development was called "iterative" for a good reason. Because it should be. While we were in fact developing our project in iterations, we were not effective at showing the actual end-product to the user group to obtain their feedback at the end of every iteration. So at the end of the day, the iterative notion was not REALLY there. When we finally demoed the product, we got bombarded with comments and questions about the absence of certain features, and the inclusion of others.. etc.
- The main business processes should be clearly defined. The flow of certain key processes and the financial aspect of the product were not clear in the minds of the business representatives. Being agile enough to accommodate changes in the process is absolutely important. But when the key processes are vague, chances are we are going to build the wrong product.
- Business decisions should be taken and owned by business people. Because of the previous point, some business decisions were taken during technical meetings by the business representatives in a very ad-hoc and informal manner. It turns out that the decisions had not been sufficiently discussed with the people involved in the process. When the product was demoed, you could see all kinds of facial expressions. Surprised.. amused.. disappointed.. indifferent.. tearing. Most importantly, nobody owned the decisions that had been taken and therefore we were simply asked to wait for a reconsideration of such decisions.
God bless Agile methods! They are there for a reason. And you will never get to appreciate the thoughtfulness of the Agile approach to software development until you experience a not-so-agile one.
 |
| http://dilbert.com/strips/comic/2006-01-29/ |
Wednesday, March 28, 2012
Open Access: Reality or Delusion?
The open access (OA) initiative rocks! There is nothing that could advance research and science more than providing unrestricted access to peer-reviewed work at no charge. At a personal level, I have been so excited about this movement which is all about free exchange of scientific results.
Until now.
This morning, I was following up with a publisher regarding a journal article I will have published soon. And I was intrigued to see on one of the forms that the publisher is giving me the invaluable opportunity of making my work publicly accessible. To everyone. At no fee. To be precise, at no fee to the reader, simply because I, as an author, will have to pay the bill on behalf of virtually every reader. $3000 is how much I was asked to pay in order to sponsor my open access article!
I admit I was too naive to think that the open access initiative would incur no cost on me as a reader nor as an author. At the end of the day, someone has to pay the bill. But it came to me as a surprise that the open access model simply transfers the cost from the collective audience to a single entity. That is, instead of charging individual readers $10-$20 for access to my article (which is the case in non-open-access journals), I as an author will have to pay a wholesome of $3000! And that is even before anyone has actually showed interest in reading my article. When you think about it, this model is even more profitable to publishers than restricted-access models which for a long time have been described as "greedy". In restricted-access models, publishers take a risk in assuming most of the cost of publishing an article in hope that enough readers will subscribe at a cost to get access to the article. In the supposedly more beneficial open access model, the publisher guarantees a revenue of at least $3000 per article even if the article goes unnoticed.
I still believe that the open access initiative is promising in principle. But we can't be blind to the fact that so far it has been poorly implemented. The reality is that for such a movement to succeed, authors, readers and most importantly publishers all have to chip in. They all have to compromise. We cannot simply shift the financial burden to a single entity and wait for free and open exchange of information to magically happen! This is a delusion.
Until now.
This morning, I was following up with a publisher regarding a journal article I will have published soon. And I was intrigued to see on one of the forms that the publisher is giving me the invaluable opportunity of making my work publicly accessible. To everyone. At no fee. To be precise, at no fee to the reader, simply because I, as an author, will have to pay the bill on behalf of virtually every reader. $3000 is how much I was asked to pay in order to sponsor my open access article!
I admit I was too naive to think that the open access initiative would incur no cost on me as a reader nor as an author. At the end of the day, someone has to pay the bill. But it came to me as a surprise that the open access model simply transfers the cost from the collective audience to a single entity. That is, instead of charging individual readers $10-$20 for access to my article (which is the case in non-open-access journals), I as an author will have to pay a wholesome of $3000! And that is even before anyone has actually showed interest in reading my article. When you think about it, this model is even more profitable to publishers than restricted-access models which for a long time have been described as "greedy". In restricted-access models, publishers take a risk in assuming most of the cost of publishing an article in hope that enough readers will subscribe at a cost to get access to the article. In the supposedly more beneficial open access model, the publisher guarantees a revenue of at least $3000 per article even if the article goes unnoticed.
I still believe that the open access initiative is promising in principle. But we can't be blind to the fact that so far it has been poorly implemented. The reality is that for such a movement to succeed, authors, readers and most importantly publishers all have to chip in. They all have to compromise. We cannot simply shift the financial burden to a single entity and wait for free and open exchange of information to magically happen! This is a delusion.