Agile is being positioned as a magic potion to weed out all corporate inefficiencies. People have seemingly bought the idea that implementing Agile and following its best practices will start boosting their bottomlines positively. However, implementing Agile is a marathon, not a sprint. Peddling this as a “snake oil” is fraught with danger, and doing a disservice both to adopters & practitioners of Agile.
A lot of Agilists believe that Agile simply involves cutting up work into sprints, removing documentation, having daily standups, and doing a fact check at the end of each sprint, is enough to complete software development & deliver it. Nothing could be farther from the truth. On the other hand, baiters of Agile say that there is no “senior” to manage such projects, so tracking of progress is impossible, and that it does not work with large enterprise scale projects or teams. According to them, Agile cannot even promise the delivery of the predefined work on a fixed date, because it does not work on fixed scope. Again, they are missing the forest for the trees.
Such urban legends & misconceptions are harming Agile and preventing the unlocking of real value. The aim of this stage is to list & discuss various urban myths that have been propagated by Agile opponents and also proponents. Agile isn’t and has never been the point, getting better & delivering value have been the keys all along. Learn why Agile frequently fails because of the aforementioned myths, and discuss real world solutions teams have implemented to deliver & better themselves.
Agile is being positioned as a magic potion to weed out all corporate inefficiencies. People have seemingly bought the idea that implementing Agile and following its best practices will start boosting their bottomlines positively. However, implementing Agile is a marathon, not a sprint. Peddling this as a “snake oil” is fraught with danger, and doing a disservice both to adopters & practitioners of Agile. A lot of Agilists believe that Agile simply involves cutting up work into sprints, removing documentation, having daily standups, and doing a fact check at the end of each sprint, is enough to complete software development & deliver it. Nothing could be farther from the truth. On the other hand, baiters of Agile say that there is no “senior” to manage such projects, so tracking of progress is impossible, and that it does not work with large enterprise scale projects or teams. According to them, Agile cannot even promise the delivery of the predefined work on a fixed date, because it does not work on fixed scope. Again, they are missing the forest for the trees. Such urban legends & misconceptions are harming Agile and preventing the unlocking of real value.
People assume culture to be static. Culture is a living, breathing, dynamic entity. Culture – Shared values & beliefs, languages, food, customs, rituals, behavior, arts
Potatoes – introduced in 18 th Century Chili – 16 th Century Cashews - 16 th Century Samosa – (origin – Sambusa – Central Asia) 13 th Century Tea – popularized by British in 19 th Century
Add one arrow to Waterfall
What’s the odd word here? “Control”
People have choice to evaluate what works & what does not Existing practices cann be tweaked, discarded; new processes can be adopted. Key is to question status quo & understand why something needs to be done.
MISCONCEPTION People equate following certain rituals & declare themselves Agile. Product Backlog + Sprint Backlog + Sprint Planning + Daily Scrum + Demo + Retro != Agile
What to do if your PO is non-existent? Customer does not always know all the answers, they only think they do.
FACT, but… Experienced people are always a plus on any project. In initial bootstrap phase, it helps if experienced devs are there for architectural decisions & laying of initial framework. Risk is when team increases and onboarding of newer member happens. Mechanism needs to be in place to ensure that knowledge is distributed and silos are prevented
Software development itself has scaling issues, this is not methodology specific. Larger scope – Greater no. of people involved in project Greater communication delays Greater complexity Greater probability of failure Agile recommends – Smaller projects Smaller teams Shorter delivery timeframes
This is not a methodology issue This is: - People Issue (mindset, fear of job loss) - Culture issue (different people have different aspirations & work differently) - Technical Issue (Different hardware & software setups, communication) - Time Issue (Different times & dates of availability for overlap to occur) Agile has wrongly also been sold to onshore teams as profile enhancement – Become team leads & manage offshore teams. Rather, a level playing field is required. - Good communication software - Parity in hardware & software between different teams - Good Internet bandwidth - Increased & richer communication (Video conferencing) - Co-location
In a distributed model, timezones might be a significant blocker that may prevent all team members from connecting to each other.
Agile has a number of models around Fixed Bid. Fixed Time-Variable scope model - vendor signs up for fixed number of sprints, and the PO ensures that he/she can derive maximum value out of the time they have signed up for. Fixed Scope-Fixed Time model – vendor signs up to deliver predetermined user story points. These might not fit the description of a pure Agile process, but are the realities of a global software delivery model.
Agile places full emphasis on quality. If anything, rather than abdicating the responsibility of quality to a separate QA team, Agile actually proposes that the Dev team collectively take ownership of their deliverables and ensure it meets the Acceptance Criteria, which also includes quality. I’ll also explain about Pair programming, Unit testing & Continuous Integration, and how XP principles help to achieve higher quality.
FACT, but… True, but only for the initial stages. Agile recognizes this and has a reflection mechanism built into the methodology which works on the Inspect & Adapt principle. As we continue and learn, the “guesstimates” will get better over time, and a more realistic picture of project completion likelihood will emerge. I’ll specifically talk about the relationship between the estimate accuracy & effort involved and use the Estimation Accuracy Curve as a reference point for this.
Agile is a way to just manage scope creep; changes can happen on daily basis Team has to learn to say NO. Business has to come back & convince team where the newly requested feature stands in terms of priority, and team will take a decision accordingly.
Managers say - Lack of accountability
Developers say that Agile has given managers power to do daily status checks instead of spaced out checks in waterfall.
Agile is costly bcoz: - People require training on Agile processes - Coaches would need to be hired - A lot of tools & practices need to be implemented, which takes time - New skillsets in Agile testing, automation required
I can do it piecemeal Mix & match
Improving self & delivering value have been the keys all along for success of Agile, not ensuring compliance with certain processes.