Get certified - Transform your world of work today


Agile and Its Value: Part 2

A Case Study

24 September 2013

In typical Waterfall model projects, there is up-front time spent laying down the requirements as thoroughly as possible. We want the business teams to provide every single need/requirement for the tool they want created.

They try to do that. But later, when they come back with some required changes for the product, usually so much time has elapsed and so much tight stitching has happened that it leads to lot of ripples in the project.

I will give you a simple example.

I was searching for a bookshelf to buy for my home. I have quite a few management and other books, which I collected before I got into Kindle way of reading and stopped buying physical books.

After looking into the market, I decided to go to the carpenter store nearby.

  1. Simple: I could have bought a nice one ready-made from the market.
  2. Other: Had I seen a great bookshelf design, and had I wanted a replica of it with some customizations, I would have just given a picture and some specifics to the carpenter, then taken an estimate on cost and delivery. Imagine: This scenario would have been exactly like a Waterfall implementation. Everything would have been known in terms of requirements and, bang, the implementation would just happen. (This approach has an inherent flaw, which I will discuss at the end.) In my case, though, I only had few concrete needs in my mind, but I definitely wanted something better than what I was seeing. Therefore I could only present a rough sketch.
I went to the carpenter and I drew the rough sketch on paper. I told him I needed four equally spaced shelves. He then began to put the basic structure in place. He gave me a very high figure (in cost and time required), and I told him that as long as the cost stayed below X, it would be fine.

Feedback mechanism
Next morning, while going to office, I stopped the carpenter's shop. He had started a basic wooden structure, like a box. Seeing this, and thinking of something I'd seen in a store, I asked him if he could use two-thirds of the total space for shelves and one-third at the bottom for storage with doors. I could imagine that such a setup would be useful for my needs. He immediately picked up small doors he was working on for someone else and held them in front of the bookshelf to show me how it would look. It was fantastic, much better than what I had started with. We agreed, and he course-corrected while I left for the office.

I went to him again after two more days and saw that he was now almost done with both the shelves and the storage at the bottom. He had put some paint on a small patch for me to view, so I could choose my preferred color. This helped me make up my mind and, at my request, he swapped the paint color as well as the color of the storage-door handles (replacing gold with dark brown, which better matched the painted wood).

Thus my project was completed, exactly to my needs. Had I instead given him a photo and then asked to him make some changes late in the game, it might have caused some friction, because he would have had to rework a finished product. This might have pushed the cost higher, since, at the least, he would have needed to repaint and rewax the bookshelf.

The flaw I mentioned earlier concerns the timing. The longer it takes to build and deliver the solution/product, the higher the chance that the initial need for the solution diminishes or changes. This means there are more chances of reaching the end of the project and finding that either it doesn’t do what's needed or that it needs changes that are in line with the changing market. Hence it now costs a fortune. It's always better to build in smaller chunks and in close collaboration, as Agile/Scrum suggests, to ensure that the most important features are always being built first.

Observations to note
  1. I always knew which direction the project was going. As the customer, I was in the loop and collaborating.
  2. I always knew the work the carpenter was doing. This ensured that before every major decision (paint, door handles), I was in consultation and agreement.
  3. I knew that this way of working meant I still had control over certain modifications to the build, if I wanted them. Rather than choosing standard brown or orange handles, for example, I could have easily brought in custom-made handles and paint and gotten them put on. I didn't need to think about this detail on first day.
  4. I also knew that my spending was protected, since we were acting together in a controlled manner.
What I'm trying to say is that in typical IT projects, there is enormous amount of time spent on requirements gathering, detailing, and definition. The design is solidified before the development can begin, and this way a lot of time is used. While this model works in areas where the requirements are very clear or when you have good amount of time at hand, it may not work when the requirements are not clear, or the customer is not sure of what they need, or market is extremely dynamic or business domains are complex.

In today's business scenarios, rapid changes happen daily. One day Facebook and Twitter are ruling the roost; another day Pinterest has become a major social media gathering point. One day cheaper hard drives and portable drives are driving the market; the next day the cloud takes over and changes everything for good.

In such a dynamic environment, assuming/expecting/thinking businesses to know exactly what they want is like assuming that their managers have a crystal ball in which they can see the future and tell us an exact blueprint of it.

Agile principles instead rotate around an empirical model of delivery and give control back to the business team, while still delivering value to the business -- which is the goal of these projects, not just building a tool or spending money. How I got my bookshelf built was likewise about delivering the value for the customer in a controlled way.

I have written two articles covering the topic of Agile and its value. I have assimilated them with the most important piece, about how Agile does it, in a white paper. Please find the whitepaper available here:

Do share your thoughts on the whitepaper. I would be happy to hear from everyone.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 1 (1 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up