Tuesday, October 28, 2014

Method in the madness

Twice previously I have posted about how things work in the software industry. One was about planning, and the other on how appraisals are done.

Those were written at a time when I was an individual contributor, and the helpless frustration was evident in the sardonic tone of the posts. Then, I was forced to do what I was told, and in a way in which I was told to do.

Times changed, and so did my role. Slowly I got to lead a small team which slowly scaled up to be a fairly large large team of 8 - 9 members. Which meant, I got to be on the other side, where I was expected to do the planning for the project assigned to me, and take care of the appraisals part.
Planning and execution were something that I was always good at, even from my school days.

But appraisals are something that I absolutely loathed. Anyway, more about force fitment in some other post perhaps.

When I joined this industry, a lot of organizations followed the waterfall model. But as times progressed, companies with a strong engineering background figured out that it was not the best way for product development and moved to various forms of agile software development. It works or not, is entirely another topic.

I got introduced to agile development by my previous manager, but was able to learn the proper methods and techniques through a certification course.

What's it that you are reminded of when you read "Agile"? Cheetah ? Or an elephant?

Cheetah is undoubtedly the fastest animal on the ground, but what makes it agile is not just its speed, but its ability to quickly change directions even at that speed.

As with most other posts of mine, to connect to various different people with diverse backgrounds, I have taken general examples with intentional oversimplification.
Let me try to explain "Agile" for you. Mind you, this approach is applicable to people in many fields, even day to day life and not just software development. Whether it works for you or not, you need to try out and decide for yourself. But since this is a continuous evolving and self organizing process, which needs time and patience to perfect.

Let's say, you to go to a restaurant and order a thali. Most of the items are laid out on the plate at the beginning. Even though the variety and the quantity of food dished out overwhelms you, would you still gulp down all of it down your throat at once?
You slow start with the starters, proceed to the main course and then cap it all off with the dessert. The end result is that you have a nearly empty plate, assuming of course that the food is great.
This is really oversimplified version of agile for you.

Now, lets get back to the school/college/engineering days.
Most of the time we used to enjoy doing a lot of things which were not related to studies, sports, games, movies, mindless chatter, philately, ornithology and what not.
Come test/internals/exams time, then we would slog it away, burn the midnight oil, spend sleepless nights to cram in all the information at the nth moment. Finally, transfer all of this information into the answer booklet.
And this, is waterfall model oversimplified for you.

Well, in software development things get a lot more complex and the primary reason why the pundits junked waterfall model was that it didn't address change very well. And in the software industry, change is inevitable.

OK, now let's assume that you are a very diligent student, who also enjoys life to the fullest. There's always so much to do, and so little time. Say you adopt the simple "Plan the work, and work the plan" strategy well. Everyday you allocate some time for play, some for studies and some for everything else.
On a weekly basis you finish learning everything that was taught in college in that week. Without breaking a sweat. Say now something unexpected comes up, the plan needs to be flexible enough to accommodate this.
Come exam/internals time, you only need to revise everything once. And you are good to go.
No night out, no slogging, no last minute hustle. Plainly unemotional, isn't it?

So now let's extend this thinking to software development on a slightly larger scale with many team members. The complexity is much higher, but the idea is the same.
Break down the overall product development into smaller releases.
Have smaller more focused teams.
Make frequent and periodic releases to the stakeholders, with new features in every release. Make sure that each release is properly tested.
The final product release is just another day. No scene, no emotion, no scampering around, no night outs.


For all this to work in real projects, you need some help though. Support from managers, customer to try out, allow for failure. But most importantly, the unwavering support and faith of the team.
I was lucky to have them all.

I end this post with what a lecturer once told in class, "If you fail to plan, then you plan to fail"