Velocity Issues
Early yesterday evening I got a call from a long time client with what turned out to be a fundamental agile UP problem. I know, consultants never get rich by giving free advice, but sometimes it helps to get new business - you never know. He introduced me to a PM with a problem project.
I listened to the young lady for about ten minutes while she explained the gist of the project. I cannot reveal the features of the application, so I will make a parallel in a bank loan application. The business wanted to manage a relatively small list of "clients", including all their personal details, account balances, work history, financial data etc. OK, so there is use case #1, Manage Client. Sounds pretty straightforward so far.
She went on to explain that when a client came in looking for a loan, they had to fill out a long application form including details of the property, where it is located, what kind of neighborhood, the property price, what equity they are putting down etc. OK, again sounds like a pretty straightforward use case, #2, Manage Loan.
"Now", she said, "This is where it gets tricky. There are all kinds of rules around this loan process. Firstly there is a rule that certain criteria have to be met before the loan will even be considered. Then, depending on various factors in the loan it will go to different departments to be processed. For example, if the client is not a bank customer it will go to one department; if the loan is for less than $100,000 it goes to another; between $100,000 and $500,000 to another; over $500,000 to another; if the client is a Veteran to another; if the equity is less than 15% to another." She continued with a long list of processes that may or not be followed depending on the situation. Having applied for a number of mortgage loans in my time I can see what is happening.
"Oh", I said, "Getting lots of business rules from the stakeholder. That makes life interesting, but not that difficult, just lots of rules engine stuff. Keeps the programmers on their toes." In total there appeared to be about 10 or so use cases of similar complexity. Pretty straightforward but with a reasonably complex set of business rules that would create many alternate flows.
Still I did not see much of a problem, so I asked about the architecture. Maybe there was lots of risk there. Turns out it was a straightforward web application using a common application server and even more common database. So, straightforward use cases and low risk architecture - where was the problem.
"So where are you in the process?" I asked, and got the response, "Somewhere in Elaboration." That obviously seemed strange since an application such as this was maybe one iteration in Elaboration to really kick those requirements to make sure there were no gremlins hiding in them and a chance for the developers to fire up the app server and the database and create a few clients and loans to prove it could be done. The demonstration would enable the stakeholder to see some screens of the application actually working. Pretty straightforward.
Indeed, they had built one use case during the first iteration, but were now actually in their third iteration, with no additional code written. They were still struggling to add more detail to the 9 remaining use cases so they could refine their cost estimates and justify proceeding to Construction. I had given them a rule of thumb that by the end of Elaboration you should have about 75% of your requirements known. That would enable you to refine your initial Order of Magnitude estimate and produce a Budgetary Estimate. Since they had main and alternate flows for only a couple of use cases, there was a dilemma. How much longer will the project take?
In my mind I reviewed the situation. For whatever reason they had worked for two one-month iterations and completed the development of one use case. They had a total of 10 use cases of about the same complexity. Let's assume that things will get easier, but that two other use cases will appear from out of nowhere to counterbalance that. Using my advanced mathematical skills I quickly said, "18 more months. You spent two months completing one use case and you have nine to go, that's 18 months. Make it a two year project!"
The phone went silent for about 15 seconds and then a small voice said, "I'm screwed!"
The reality is that their velocity was a disaster, about the same as my first 1963 mini on a good day. Being the helpful consultant that I am, I decided to dig into this a little more. There was nothing obvious in the complexity of the application or the architecture that could be the cause of this velocity problem. What else could be going on? Through some more conversation about the process I discovered the answer. The stakeholder was very overworked with her normal day-to-day business of processing loans, and she could not spare more than four hours per week working on this project. Either a single four-hour meeting or two two-hour meetings were scheduled each week to review and debate the use case scenarios. I can imagine the meeting discussions, but won't go there at this time!
The root cause of the poor velocity was that the most critical team member was only available 10% of the time. The biggest problem in this application is the complexity of the business rules, and the person with all the knowledge is too busy!
Have you ever driven down a small country lane - England is full of them, and got stuck behind a slow moving vehicle. The line of traffic may extend for hundreds of yards, but it is always the slowest one that controls the pace of the rest. The same thing happens on software projects. You may have the most efficient and fastest team, but if the one with the critical knowledge is off working on other things for 90% of the time, then the whole team will suffer.
Even assuming that the BA can make some intuitive guesses in many areas, the overall efficiency of the team cannot be better that 15-20%. That's why what should be a four or five month project quickly turns into 18-20 months.
Sadly lucking just around the bend is another efficiency impediment! Management looks at this situation and sees that his people are only working 15-20% of the time, which is a big waste. He therefore gives them five other projects to work on. Instead of removing work from the stakeholder so that she can work on the project closer to 100% and be more efficient, management compounds the problem by making the rest of the team even less efficient. Efficiency drops to around 40% when working on five or six projects at the same time. 1
I don't know how the problem will be resolved, but unless it is this relatively simple project will drag on forever and IT will be blamed for their poor efficiency. The most efficient project team should be dedicated 100% of their time to the project and preferably collocated. Ken Schwaber indicates that order of magnitude increases in efficiency can be achieved in this manner. 2
1 Clark, Kim B. & Steven C. Wheelwright, 1993. Managing New Product and Process Development: Text and Cases. The Free Press.
2 Schwaber, Ken, 2003. Agile Project Management With Scrum. Microsoft Press.
These pages contain various thoughts and ramblings that travel through my brain cells from time to time. Most are the result of a conversation with a client, a problem with a project or just something that occurred to me while I had nothing better to do.
The content is free for you to do as you wish. If you publish excerpts please reference me and this web site. You never know, I may get more clients that way.
If you disagree with anything I have said, please contact me. If you don't like it, then consider what you paid to read it.