Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How Fast Can You Change?

DZone's Guide to

How Fast Can You Change?

A lot of people think agile is all about faster deliveries, and then they set unreal expectations that are not feasible.

· Agile Zone
Free Resource

Speed up delivery cycles and improve software quality with TestComplete. Discover the most robust automated testing tool for end-to-end desktop, mobile, and web testing. Try TestComplete Free.

In my talks, I often ask a trick question – what is the most important part in a bicycle and a formula one racing car?

I get all kinds of answers – wheels, engine, chasis, tyres, steering, even the driver…. No doubt, they are all right answers.

However, my favorite right answer is the brakes! Why? Because they make us go faster! 

Let me explain.

Imagine you are riding a bicycle without brakes. You won’t be able to go faster because you have an in-built fear in your mind that if you pick up pace beyond some ‘reasonable limit’, you won’t be able to control it lest it becomes important for some reason. Now imagine riding the same bicycle with the best brakes that your money can buy (or, even better, that you can build!). You not only can ride the same bicycle with much more confidence, you can actually imagine going much faster than before. Of course, you can take the analogy much further and argue that you could go even faster if there was a better helmet, a better kneecap, jacket, leather gloves, even the insurance to make the rider free themselves up from the worries of a possible accident…then you might zoom even faster and potentially reach closer to the Peltzman Effect, but we will stop at just having the right brakes in this blog post.

Now the mental model about brakes is that they keep a stationary object at rest (at least on a downslope), or slow down or stop an object in motion, but never make anything go faster. And yet, that’s what they do – they give the courage and confidence to the rider to go faster than without those brakes. In that sense, the brakes are the feedback and the control mechanism rolled into one. Without a brake, you still have access to the same power (or the engine power in case of a formula one car) as before, but your decision to use it judiciously as opposed to using it as unbridled raw power is based on your ability to get that feedback and adapt to it. In general, the sharper the ability to get the feedback, make a decision and execute it, the faster one could go.

Of course, one can (rightly) extend the argument that it eventually depends on the rider/driver of the vehicle – for the real ability to handle a machine lies not in the machine but in the mind (and the hands) that operates it. We will get to that in a moment.

A lot of people think agile is all about faster deliveries, and then they set unreal expectations which often sound something like this – let’s do agile so we can ship the product in 3 months which today takes 9 months. Like they say, you can’t put ten pounds in a five pounds sack, I have a bit of a bad news for them – the quantum of work that takes 9 months to ship can’t be shipped in 3 months without seriously undercutting either the breadth (i.e., the scope or quantity of work) or the depth (i.e. the quality, performance, usability, reliability, etc.) of the deliverables. Agile isn’t quackery (even though it has been oversold as one by some overenthusiastic souls!). 


Speed is not fast you can go, but how fast you can change!

Speed is not fast you can go, but how fast you can change!

For me, brakes are the metaphor of agile. They provide the feedback and enhance the ability to manoeuvre, even more so at high speeds. The more real-time and actionable (i.e., more “byte-sized” than “brick-sized” to clearly understand and identify the cause-and-effect relationships that allow the feedback to be “meaningfully actionable”) a feedback is, coupled with the internal ability of the machine to rapidly absorb and assimilate it, the sooner it can respond and adapt to a potential event. Remember – making a third-stage spacecraft change its position even by a few micro-degrees is much more difficult and perhaps valuable than a car changing its lane on a highway. Just like any serious competitor who will adapt the brakes based on weather and other operating conditions, there is no one-size-fit-all brake here. The term “agile process” is a fairly useless one, for it creates a mental model of a laminated process that will enable people to operate with (guaranteed?) agility out-of-the-box, and yet, it is hardly ever going to be that! If you have already nailed down every single nook and cranny so that the resultant process is a certified “agile” one, than one must only be smoking pot. Neither the creator of that uber-agile process could have anticipated every possible future condition (the last time I checked, I was told that job description was reserved for God!) nor anyone knows enough to prescribe a single templated solution to all kinds of problems. Net-net, everyone must create their own “agile process”. Of course, they can start with what we know today, but remember – what is know today can only be a (better) starting point and not the limiting rate factor for what you must eventually accomplish. In that sense, an “agile process” is like “best practices” – you can’t simply copy someone else’s best practices and expect them to 10x your results. Rather, you must painstakingly solve the hard problems, and evolve your own best practices – to that end, best practices are things that are created as an outcome of a problem-solving activity by smart people, and not really something that others can use as a shortcut. Sure, some of these might be very universal, but I guess most all have been already discovered long back, and we are mostly rebottling and recycling them these days.

So, there you have it. There is no such thing as a universal agile process that will solve all maladies. Like Edison said we are able to see further by standing on the shoulder of giants, we simply take what exists today as a starting point and create our own agile process. Nothing more, nothing less.

And just like the picture in this blog, agility is not something that takes you faster, but it enables taking you to new, unknown and exciting places when you think there might be something interesting there. If you don’t find the cheese interesting, you can always come back to the last stable state, and start another journey, till you find something better!

Speed is not how fast you can drive and deliver. It is how fast you can change and adapt. And life and product development have more hairpin bends than you think…

Release quality software faster with TestComplete. Discover how to decrease testing times and expand test coverage with the most robust automated UI testing tool. Try free for 30 days.

Topics:
agile ,project management ,change management ,change

Published at DZone with permission of Tathagat Varma, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}