As rightly it’s been quoted “Easier said than done”, it’s quite effortless to mention that you are AGILE. Having witnessed organizations swearing on being Agile, it gets hard to believe them when you actually dive into the depths of the team’s delivery/functioning framework.
Or it’s just a fancy term which makes you look like a newly renovated facade of RV attracting a horde of spectators (potential/existing clients) with a malfunctioning interior.
Recently, I’ve started putting together a little list and there are a dozen reoccurring myths that haunt almost everyone who has witnessed what true Agile corroborates.
1) AGILE IS A NEWBIE IN TOWN
While attending one of the sessions a few months back, I was astonished to know that Agile exists since the time human evolved!! Isn’t that an exciting discovery, we always knew but never thought in those terms? Humans inspected the situations/conditions and adapted themselves as per the requirement or need of the time.
Jon Kern, an aerospace engineer in the 1990s, became persistently frustrated with the long lead times and with the decisions made early in a project that couldn't be altered at some later point in time. It took the automotive industry six years or more to design a new car, and in the 1990s, that time was cut almost in half.In an extreme but by no means unusual example, the Space Shuttle program, which operationally launched in 1982, used information and processing technologies from the 1960s. Highly complicated hardware and software systems were often designed, developed, and deployed in a time frame that spanned decades.
In 2001, seventeen software developers met at a resort in Snowbird, Utah to discuss the lightweight development methods (Scrum, XP, DSDM, RAD, FDD etc.) among others Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, and Bob Martin. Together they published the Manifesto for Agile Software Development, giving birth to an umbrella term “AGILE
”.2) AGILE GIVES SPEEDY PROFIT
There is no shortcut to success. Yes, shortcuts often lead to a quick upward trend in the management graphs but it falls sharply. Talking about Agile, there is NO shortcut. Sounds funny, but it’s true.
Transformation is a continuous process of learning and change. Though transformation to Agile can deliver enormous benefits, the truth is that the majority of transformations go through spikes and dwindles in the chart. There is a tremendous effort that goes into training, team formation, not to mention - Forming, Storming, Norming, and Performing.
While everyone is trying to adapt to this new change, the delivery capability can actually go downwards before it makes the step-change upwards and begins to achieve the improved delivery capability.3) BLAMING AGILE IF YOU TRIED IT ONCE AND FAILED
One should always remember that Agile is NOT a magic wand that can solve all your problems. Any project may succeed or fail, even if you have adopted Agile.
If something is not working out, try to retrospect and see what went wrong rather than blaming the process – how effectively it is used depends on decision-makers, not on the approach itself!!4) THERE IS AN EXACT SIZE OF THE USER STORY
As it goes for projects, in the same way, no two teams are the same. They have their own thought process and way of understanding the complexity, effort, and uncertainty.
There isn’t a general accurate size for a User Story. It depends on the team, their skills, and their level of domain knowledge.
So, one has to get over this notion that there is an exact size. NO, nothing as such exists.
The size of a story depends on the experience and knowledge of a development team. When the team is new and in want of domain familiarity, they request more and more detail. Contrariwise, team members with experience and knowledge in the domain might not look at it that way.
A user story can be the size of a skateboard or it can as big as a space shuttle.5) NON-FLEXIBILITY FOR FIXED DEADLINE PROJECTS IN AGILE
is most suitable for fixed deadline projects. Surprised!!
Well, yes, when you use Agile, particularly Scrum, you will notice there is something called time-boxing.Scrum just loves deadlines!!
The team gets much of their control from the attaching deadline effects: sizing work to the deadline, individual commitment, and inclination to renegotiate just what is being built to meet a date.
You can set your milestones in terms of sprint and can predict the release date too. Even your customer would be thankful for the vision of delivery you provided.
6) AGILE ONLY RELATES TO SOFTWARE DELIVERY8) THINKING AGILE IS A SILVER GUNSHOT THAT WILL RESOLVE ALL YOUR SNAGS
During one of my sessions last month, I came across a statement where the group thought that Agile is only for the Software industry and it can solve problems and provide a solution. And yes, it is one of the widespread notion or myth lingering since long.
But, it’s NOT true.
Even before the birth of the term “Agile” in the industry, we had Toyota (1953) working on the concept of Kanban, to deliver their products. Kanban comes under one of the umbrella items of Agile.
We can see Agile being used in farming to increase the throughput. With the influx of real-time data and improved equipment that can act quickly, farmers can continue to make adjustments and iterate on their growing process throughout the season. One large iteration cycle (a growing season) can now be broken down into multiple mini-iteration cycles. Machine learning and analytics will shorten the time gap to translate data inputs into actions that get smarter over time.
7) NON-FUNCTIONAL REQUIREMENT CAN BE DEALT WITH AT THE END
During the days of waterfall methodology, non-functional Requirements (NFR) testing was generally the last step before application delivery.
Now with the adoption of Agile, the application is built incrementally over multiple sprints which results in overcoming agile challenges and building better results.
It is a ploy if the team is pushing it back to the end as the changes caused by incomplete/inadequately developed NFRs are potential large fixes, requiring costly architectural or design corrections.
As mentioned above, in point no. 3, Agile is not a magic wand that can address all the problems. You can fail just as dramatically on an agile project as you can using any other traditional method. But the catch is, that you fail early (acknowledgements to transparency and visibility)
It is not going to solve your problems, but, it can surely empower you with the principles and values, which can help you achieve success. And it lets you know how to avoid mistakes in Agile. Now it’s up to you, how you want to adopt it – Just for the buzzword OR for real agility.
Agile isn’t “just do it” – there are significant planning and re-planning involved when required.
As you can see, these 8 common pitfalls in Agile can cause substantial blockers for anyone trying to implement Agile. But as long as you recognize this by keeping the above information in mind, your chances of getting better results with Agile will considerably improve.
To end with, what do you think, are you Agile?