Agile Scrum – Nothing more than a COMMON Sense approach

Last few years has really seen the growth of Agile – Scrum adoption in the IT Industry. Organizations are adopting dime by dozen concept in moving towards Agile. Every Software person (whether a developer or tester) is bent on adopting and having the agile experience on their resume / profile. Well nothing wrong with this, But if all (or should I say most) of the organizations are adopting agile and its related frameworks and all the workshops are going full, why the quality of the SW delivered has not improved in the same proportion, Are we not having things which are behind schedule?, are we not working late to complete the commitments that we have given?.

Same happened with Lean applied to manufacturing; people learned the Toyota-ish words but didn’t embrace the philosophy. We all have got certified in various elements, but have not improved. Well, i ain’t talking about the improvements exponentially, but at least by some percentage. So do we say that the agile model is fundamentally faulty or it is our adoption which is creating the unnecessary trouble.

If one thinks that Agile is defined by buzzwords, it is no wonder you not sure can will come or can’t, to me it should come can make it work. Agile is a mindset that leads to:
• Centralized change management to projects
• cutting projects into manageable chunks,
• Insisting on end user ownership, etc.

One of the areas that the industry has defaulted itself is in the area of focusing on Project Management and forgetting about Software Engineering piece of the system. We have conveniently forgotten the idea that every coin has two sides and unfortunately we have focused only on one side of the coin in agile

Just because you’ve travelled in a CAR doesn’t mean you can drive it (like for me, “I can travel in CAR, but cannot drive the same”). Same thing with an agile process, too many people use the buzz words and get the quickie certifications that the industry requires in order to get the job. They did the same thing to RUP, OOAD and OOAP when it came out; everyone was doing it theoretically, yet they really didn’t apply practically and that’s where they failed. If you’re going to say you are using an agile process then really learn it, really do it, and really be it or stop saying you are agile and find something else to blame piss poor requirements, design, and software on.

Personally, for me, Agile Scrum comprises of good common sense elements, doing small things, and doing regular and periodic delivery to the customers / clients or management / end user (whatever the case may be). My concept of Agile is to deliver less, but deliver of good quality, Even if one delivers a great amount of software, but if it does not work at the customer site, how does it really matter. But as they say these days “COMMON SENSE is NOT SO COMMON”.

My belief is that there is a wide range of people using the term “agile” but of these also there are two types of people
1. Some people have a lot of experience doing software development and can use it to create much better software.
2.And other are those people who use the term vaguely in order to sound intelligent and flexible.

There is a fundamental understanding flaw of what agile development is about. There are many people who see agile as anti-process and an excuse to work in an informal and ad hoc manner, While the actual objective of agile development is to follow an agile process and not eliminate process completely. There are unfortunately companies who operate in a chaotic manner and try giving this approach legitimacy by calling it “We Work the Agile Way”. On the other hand, there are companies which, using an agile methodology in the way it was intended, have seen great success.

Agile is abused as a methodology, particularly in India, where there is a culture of pathetic unplanned and managed software development is prevalent. Most of agile principles are not followed and adhered to… It is more of a jargon that is used in the industry to boost up a few resumes and profiles. It is quite surprising when we get assignments to have resources certified for CSM (Certified Scrum Master) or PMI ACP (Agile Certified practitioner), because the client / customers who are giving business to my local clients (In India) want certified resources on the project, I am not sure if the customer understands that getting a certificate and implementing the practices in true spirits are two different ball games… but alas who cares and why should we. On one hand we are getting business (so I am billable) and secondly the resource is getting a new additional element on his / her resume, who would complaint and not sure if the original customer, over a period of years has performed a ROI or cost benefit analysis of having all the resources working for their project certified of any value ….

The bigger question for me is yet to be answered … our management, customers and clients want agile to be practiced, how many of them even understand agile, have they ever got oriented on agile, do they understand the basic principle and thought process behind agile … I afraid not ….

In my long experience in IT industry and more specifically in SW development, certain things are consistent, and they aren’t Waterfall. Project Managers want software rushed out, often on the basis of inadequate specifications. They want something now, and they’ll worry later about having something maintainable. Developers don’t like to comment their code and don’t particularly like to take the trouble of documenting their unit test plans and so on …

One should not forget that we live in the real world, we are also the development team who would have to maintain the previous developers’ uncommented, unplanned spaghetti code, and that isn’t fun. We’re the ones who’ll have to deal with unexpected changes later on, and that will be hard if we wrote novella-sized subroutines that do everything. We should be pushing the idea of communicating with users without swallowing the whole package of bad design practices. Maybe that could have its own element or buzzword.

Could I rename it to Sensible /Common Sense way of SW Development, anyone?