XNSIO
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Agile is not about Rapid Software Development

Time to time, I keep running into people who think Agile is about rapidly developing software. With all good eXtreme programming practices, we should be able to churn code at a rate never before. Some even claim its faster than some of the model driven code generation approaches. Based on my experience and understanding I think this is a big fat lie. IMHO, people in this camp, clearly don’t get it.

To me, Agile is about Rapid Business Value delivery. It is not about delivery more software, its about delivering more business value. In fact, I would go to the extent saying, in Agile, we resist delivering more software. We constantly try to identify and prioritize highest business value delivering features. In this process, we try to eliminate low priority, low business value features. We strive to provide max value for the buck. This is very different from rapid software development mentality. Where the focus is more software. I actually tell people, that when it comes to software development, I’m a lazy person who want to do the least amount of work and get max ROI on it. Prioritizing, focusing on what the business needs first, delivering the same, taking the feedback from its use and adapting our plan accordingly is a great way to achieve this. Even though I say I’m lazy, this is a lot of work and needs a lot more rigor and discipline. Being Agile really helps me strike this fine balance.

Having said that, clearly Agile can help deliver software faster, coz we eliminate a lot of waste [unwanted features, useless process documents, hand-overs, etc]. But that is not the goal. Its a nice benefit of this approach but not the driving factor.

Now that we agree Agile is not about Rapid software development, why do most [if not all] projects track velocity as the measure for progress? Isn’t velocity just a planning tool, that helps us forecast based on yesterday’s weather? How does it matter that we completed 60 story points or we completed 310 hrs out of 320 estimated hrs? Somehow we don’t seem to be measuring business value delivered?

Having said that, I can think of a couple of reasons why we don’t do that:

  • Business value is only delivered when business uses the software and benefits from it. Unfortunately a lot projects’ iteration/sprint boundaries are way earlier than the point at which the software is being used. In fact, a lot of teams end their iterations/sprints with a QA/BA/Customer Sign-off. After this, the features sit on a shelf and wait for few more to accumulate. Finally when a hotchpotch of few more such features accumulate, teams do more testing [performance, usability, insatiability, stress, load, blah..blah..blah]. When all this is fine, they show it to more customers and do a user acceptance test. Finally it goes thru all the jazzy Configuration management steps, it gets packaged and deployed. Plus there is a user training and support training phase also involved. Basically, what I’m trying to highlight is for a lot of folks, the world ends at the iteration/sprint boundary. For some people it might extend to the release boundary. But there is so much that needs to happen once the feature is QA/BA signed-off. Hence when we end the iteration/sprint, there is no way to know if we actually delivered any business value or not. I’m not saying there is not value in this approach. It is a good risk-mitigation and to some extend feedback mechanism compared to the tradition approach. But if we really want to focus on business value and measure that, then we need to be deploying every iteration/sprint. Is this feasible? I don’t know. On one of my projects, our time to production was 3 days. It was possible, coz the system was already in production, had a mature code base, had great test coverage and most importantly we had the customer’s buy-in. It really felt great to get concrete feedback in a week’s time. May be this is possible on all projects, we can at least try. Also don’t forget there is a cost associated with each release, but automation is a great way to reduce the cost and time.
  • Business value is a vague concept. Unfortunately there is not easy way to know the actual business value. In fact when I say business value, I really mean estimated business value. We may only know the real business value once the business uses the software. None of my customers could tell me feature A is 30,000 USD and feature B is 20,000 USD. The best the customer could tell me was, I think feature A had more value than feature B. This was helpful for prioritization, but not for measurement. We could not really say if the team was giving ROI at the end of the iteration/sprint. Does that mean we should not bother about business value? I can think of one solution. This problem sounds very much like developer estimation problems. For a given story the developers don’t really know how long it’s going to take to complete the story. For years we tried estimating in real hours. That did not work. Then we tried estimating in Ideal developer days or story points. I don’t know if this works or not, I’m do not believe in this approach. But teams seems to be using this approach. The story point approach is interesting. Developers claim that it is difficult to tell exactly how much effort, but based on their experience they can relatively size stories. They can tell if story A feels as big as story B or it feels bigger than story B and smaller than story C. This way we assign points and then track points. Once the iteration is done, we can do a projection based on all the story points and how long it took to complete x number of story points to get a rough estimate of how long all the stories are going to take. Some people refer to this as a pure estimate. Where they separate the effort from the complexity. Efforts can vary depending on the technology, tool, ton of other reasons, but the complexity remains the same. [I don’t quite buy this. But I’m para-phrasing what others claim]. Anyway, that’s not the point. The point is can we use a similar approach for estimating business value? Can the business estimate business value in relative points? Let’s say we call it Business Value Points? Making a big assumption that this is possible, now we could have a way of measuring/tracking how much relative business value is being delivered. We might still not be able to give a concrete Dollar amount, but we could see a trend in team’s performance.

Well I think its worth trying these 2 things, it might take us to something new to explore. But I guess you can see where I’m headed. I’m interested in measuring business value also and not just effort alone.


    Licensed under
Creative Commons License