I read this book because Tom and Mary Poppendieck recommended it to me at XP Day 3 (Their book on Lean Software Development is a must read.). It is an important book because it places Return on Investment (ROI) at the heart of IT prioritisation and decision making. If your company is not doing this, then it will have lots of trouble with its IT projects. The book explains ROI and Net Present Value (NPV) and then presents a heuristic for delivering the optimal deliver of ROI. The heuristic depends on having groups of functionality with associated revenues (These groups are called Minimum Marketable Functions or MMFs). The book then presents a methodology for delivering optimal ROI that works with RUP or Agile. I’m tempted to try out the heuristic although I suspect that most decent project managers could work out the optimal delivery without the use of the heuristic (one of the approaches they suggest.).
The big question that the book leaves me with is “Where do the revenue figures come from?” The book gives an unsatisfactory single sentence answer along the lines that they are produced by marketing and the business. If you want my thoughts on this, contact me by leaving a comment and I will send the article that Andy Pols and I have just written on this subject.
Overall I liked the book, it is well written and easy to read. My one contention is that RUP comes before Agile. ;-)
When I was at school I had to write an essay on Lech Walesa. To do this I went to the reference library in my town. I went to the index cards, found three references. I then got the newsapapers with the articles in and photocopied them. It took me half a day to get the source material.
By contrast, I just did a search on Google and got ten pages of hits. The top link is a Biography. It took me less than 10 seconds to find.
We are now in a world where getting the answer is much much easier. No longer is the answer the difficult thing. Its now about getting the Question.
This means we need a new set of skills. One of these in analysis is detecting bad smells. We sniff out the source of bad smells by poking around where we are least comfortable. This is contrary to the traditional business analysis role where we tried to skate over problem areas. Now our job is to look for exactly the things that previously we chose to ignore in order to spend time polishing our weighty analysis documents.
The business coaches role can be thought of as being broken out into three tasks, Learning (Analysis), Issue Resolution and Knowledge Transfer (Coaching).
The outputs from each task are:
Analysis - A set of questions in an issue log (Excel or similar lightweight tool).
Issue Resolution - The answers to the questions.
Knowledge Transfer - Developers trained in the business domain and the problem/opportunity specifically.
Answering the question is often best done by the developers as it improves their relationship with the business because they can ask sensible and insightful questions that demonstrate understanding. The business coach should only find the answer to the question if they feel it will open up further questions or if getting the answer will require facilitation of a group of people to answer it.
The real value that the business coach adds is by knowing which questions to ask. "Is this a single currency or multiple currency application?", and not by getting the answer.
This is a bit of an aside. I thought I'd have a break from Agile for a few minutes.
Anyone who has ever worked in financial services will have come across the concept of a position. For example, say you by 10 shares in yahoo, then sell 5 and buy another 20, you will end up with a position of 25 shares. Seems pretty simple. In fact its not. A position is simply a summary value, the aggregation of a number of trades. Most financial systems have a position entity / object that they persist. Why? For speed. In actual fact, having a position entity that is persisted normally causes a lot of heartache.
What is a position? If you are dealing on your own account, then its all your shares in a particular company. If you are writing a system for a financial institution, then you need to put a lot more thought into it. It could be at the book level (i.e. a group of shares managed as a book), at the trader level, company level or even across companies. In my "Tell a Story" blog, I present a model for the organisation structure of a financial services company. In fact the position could be the aggregate position of trades selected at any level in the structure. It is therefore best not to persist it as it causes lots of computational business logic problems, keeping the value up to date.
FYI, in most companies, the position normally refers to the aggregate value at the book level.
The business analyst and business coach role can be divided into three parts:
1. Learning (including the use of analysis tools.)
2. Issue resolution
3. Knowledge transfer to other of the information gained.
A traditional business analyst will use documentation for knowledge transfer whereas the business coach will aim to coach instead. Writing documentation takes considerably longer than coaching. Any small changes require documents to be revised.
From experience, a traditional business analyst will spend about 80% of their time producing documentation, 15% on issue resolution and 5% on learning (and using the analysis tools). The business coach aims to spend 50% of their time on coaching, 20% on issue resolution and 30% on learning. This is a shift of emphasis away from documentation to learning in the role.