Referring to one of my earlier blog posts where I talked about how Agile welcomes change… today I would like to elaborate on WHY Agile tries to inculcate a mindset that accepts constant change using real life examples.
Have you ever, at any point in time during your lives, heard some of these phrases:
- “Gochange your clothes, you’ve been wearing them for 2 days now”
- “Dang, a flat tyre, now i’ll have to change it”
- “if you don’t change your eating habits, you’ll die of obesity”
- “Boy, your school is horrible, you better change it or it’ll ruin your future”
Now let’s try and change these sentences so that they negate change.
- “Don’t change your clothes, you’ve been wearing them for 2 days now”
- “Dang, a flat tyre, now i’ll have to keep using it”
- “Don’t change your eating habits, you’ll die of obesity”
- “Boy, your school is horrible, you better not change it or it’ll ruin your future” (this one doesn’t even make sense :S)
Now, I know some of my examples were loaded just to prove my point but still what I’m trying to show is that we cannot, I repeat we cannot plan for every little thing that may happen to us during any particular day. If we can’t plan every thing in advance for even a single day, how can we as human beings expect to plan in advance, the entire length of a project (that may span from weeks, to months to even years) and assume nothing would change along the way.
In Pakistan there are two methods of travel from point A to point B in a cab. Let’s call one method ‘the Alpha way’ and the other ‘the Beta way’. The Alpha way is to get charged via a fare meter on the basis of number of kilometers you travel from point A to point B. The Beta way is to do a rough calculation of the distance you would have traveled going from A to B, and negotiate on a price. Once that price is decided you sit in the cab, go to point B and pay the pre-settled amount.
Now, consider the following scenario. You opted for the Alpha way. The cabby starts driving but half a kilometer down there’s a blockade. He drives back half a kilo meter and takes another route, 2 kilometers down the road he runs into another road all dug up, and so he takes a third route (I’m not exaggerating, its an every day thing in Pakistan), all the while your meter is running like a high-on-dope gerbil spinning a small ferris wheel and you can’t help but stink the entire car with salt water dripping down from head to toe (in short you’re sweating). When you reach your destination, for what would have cost you 200 bucks, you end up paying 550 or so. You pay extra money for all the routes that you changed, just to get to point B which was your initial plan all the while.
If you had taken the Beta way, you probably would have had to settle for 300 bucks or so, but, road blocks or no road blocks ALL you would have paid was 300 bucks for going from A to B.
Do you see where this analogy is going? We as engineers, project managers, business analysts and especially entrepreneurs do the exact same thing with our customers. When we’re gathering requirements we expect the customer to:
A) know ALL the requirements that he’d ever have, day one!
B) somehow plug a mental usb flash drive and transfer all the knowledge from his brain to ours…again to the last detail.
And then we plonk all the requirements in a document, label it SRS (Software requirements specifications) in block bold letters and put a gun on the customer’s head saying, “These are the holy words spoken by you and inscribed till enternity in this holy book called the SRS. If you Godforbid tell us anything later which is outside this holy book of requirements you will pay for it~~~” *Loud devilish laughter MU HU HU HAHAHAHA*
And that’s that. If during the course of a project a customer runs into a ‘road block’ and HAS to change routes, even if the ultimate goal remains the same i.e. getting to point B, we the ‘helpers’, the ‘solution providers’ hold the customer by the scruff asking him to pay… Why did he not have the miraculous ability to anticipate the unknown we wonder… after all he is the customer!
On that note I’ll end my banter for today. I’ll continue from the same note next time I blog, explaining how if we start thinking like a customer we can really excel in the software development business.
Call it Agile… call it what you will… at end of the day, it’s commonsense.
My two cents.
Interesting analogy but taking into account every business requirement often requires on to adapt the changes the business user wants.
The article omits the point that- the users themselves in Pak are not really aware of how IT impacts their processes -they prefer to have the ‘AS -IS’ system mapped on to the newer system, they are not aware of the other benefits.
As far has holding a gun to their head, you are quite aware of the ‘khuawish’ scene of the management. Additional requirements are placed within the cloud of other requirements or are said that it was assumed that this would be completed.
Change management is a very important part of software development, it helps pay off the additional costs of paying the developer as well.
@Zeeshan: You’re absolutely right! Change management is very important, but sadly in practice the ‘management’ bit is often interchanged with change ‘resistance’ in almost the entire IT industry.
You’d agree, we often try and scare the customer by telling him the architectural repercussions he’d face for making a small change in the application… or that a change would cost him X amount of money, hence discouraging him to cater to his new, evolving, imperative business needs.
In short, we’re essentially closing the customer in a box where from the inception of the project till delivery, it’s ALWAYS a matter of you vs. me… Why should there even be a ‘versus’ situation between a customer and a vendor in the first place? What are solution providers without a customer?
Sure there will be and are cases where a customer would try to squeeze in his wish-list, but that’s where you negotiate with the customer on what features drive MOST value for his business and which ones don’t.
Instead of immediately start talking in terms of dollars and cents, the negotiations should be based on business values that each new request or requirement would drive FROM a customer’s perspective. You’ll see a marked difference in the customer’s attitude when he realizes you care more about his value/return on investment than about emptying his pockets.
Long story short, I agree with 110%, change management is an integral part of any development methodology Agile or not, it’s just a matter of understanding it and approaching it in a manner where you MAKE the customer realize you’re both on the same team. Agile has a very smart way of managing ‘Khwahishaat’ (wish-lists) that I would be blogging about real soon.
Cheers!
@Zeeshan: regarding the issue of “khuawish scene of the management” … how can we distinguish if it actually is a wish-list or a real business need? Most clients (world over) don’t know what they actually want until they see something in action. This means their requirements evolve over time. In order to avoid the “wish-lists”, we (software developers) love to bind the client over a set of written requirements document and we may end up delivering software which may not cater to all the business needs of the client. Also, we may be delivering something that contains features which are never used by the client thus producing waste. Why … because during the “requirements gathering” phase our client had a general idea where he wants to go but didn’t had finer details.
Dear Nadir,
This is my first experience to read really constructive comments about the behavior of developers, project managers or IT professionals, more interesting thing is “these content is submitted by an IT personal”.
I really appreciate your approach and direction, I am sure out of thousands or millions IT professional from Pakistan you will get an admirable position because you are concerned with your customers / clients.
May Success Follow You, Where you go!
Best Regards