Agile – the pied piper of software development
Almost every software development company today is rushing to adopt Agile scrum as their preferred software development methodology. Little attention is paid to the nuances of agile as can be understood from bits of conversations below -
- “The client wants us to deliver fast and so they want us to do Agile” ... was what I heard from an onsite person visiting the ‘xxx’ offshore office in India.
- “We are running behind schedule and need to expedite the delivery. Let’s increase the velocity of the team to ensure that we deliver on the date committed to the client” – was what my program manager said for a project for which the product backlog has been ever growing and the goal always looked far off without changing the delivery date.
- “We are doing agile, right? So why can’t you make this little change … what is the problem? – was what a business stakeholder said in a review meeting to the SOS scrum master. The business requirements were so volatile that they changed many a times after the sprint had already started.
- “Is Agile really successful? I mean it’s so chaotic and you always have to be on your toes and work day in and day out … everyday ... until the last day” – so said the solution architect who had been working in traditional waterfall ways for long and Agile was relatively new for him.
There are so many such things that I’ve heard many times in the
past and keep hearing them even today. In these years, I’ve experienced a lot
of flavors of “scrum” which is the most widely used Agile methodology; most of
them conflicting with the agile mindset or agile manifesto so to say.
Being able to deliver fast or increasing velocity to meet
schedules is a misconception about what agile scrum can do for you. The best
way to put this across would be to say that Agile scrum is an empirical process
that helps reduce the time to market by using an incremental and iterative
development approach.
We do embrace change in Agile but Agile doesn’t mean chaos! Instead,
it involves planning – continuous planning. While scope changes are very much
acceptable, no changes are allowed once the sprint has started. These were some
initial thoughts and the intent clearly is not to deep dive into the
nitty-gritties. Call them bad smells of scrum that teams/management should stay
away from. Do you smell something fishy around?
Best,
Jasdev Singh (PMI-ACP, CSM)
Comments
Post a Comment