What does it mean to be truly Agile? A practitioner’s point of view

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

Which is the right question to ask? Is your company truly Agile, Is your approach truly Agile or Are you truly agile? Each individual will have a different answer to offer as Agile is not a methodology but an ideology. Many a time wrong interpretation and adoption keep true behavior of Agile elusive to many companies and individuals.

Most of the companies today attempt to change tasks to work in Scrum (a popular variant of Agile) rather than adopting true Agile philosophy to modify existing requirements to maximize gains. Inspect and Evolve are fundamental and key elements of any Agile variant which needs to be addressed on an iterative basis to remain truly agile. Retrospection should identify the genesis of change and its need and above all anticipate the change as it will help in identifying the best path. Evolve is to faithfully adopt retrospection results.

There is no well-defined definition of Agile which can be readily adopted but instead, companies strive for the best interpretation. We’ve been practicing and evolving with Agile since 2009 and the whole philosophy has been to make individuals agile in terms of thinking, development and above all deliverance. We have successfully adopted Scrum and have delivered on many products and each time evolving with new variations of various Agile principles as mentioned below

  • Faithfully convert all the requirements into user stories and Epics as it allows stakeholders to visualize road map clearly and critical flows.
  • Application or product should be stable after each iteration i.e. ready to be shipped. It critically depends upon the diligent selection and segregation of user stories
  • Create small teams for better collaboration and responsibility should be defined clearly for team members with correct empirical measures to instill a greater sense of accountability
  • Definition of Done should be clearly defined for each user story. Often development team confuses it with Acceptance criteria
  • Iteration cycle should be defined based upon the average size of user stories rather than picking up a random number
  • Allow team members to present user stories during the demo as it provides greater insight during introspection
  • Teams and not individuals should plan and estimate User Stories and estimations should be done in terms of hours and not days
  • Instead of doing certification based upon feature, expand your bar to the overall experience of client
  • Treat yourself as a user or customer of application rather than relying on feedback every time. It brings best possible recommendations from least possible directions

Over the years, we have realized that you may have the best use cases and the brilliant code, but if the process is not optimized, your end product will always fall short. Applying Agile to your process diligently can bring lots of improvements; however, if your teams are not thinking Agile, your company is still not truly agile. Teams and individuals become truly agile when they start adopting uncertainty as an opportunity rather than dismissing it as limitations.

Subscribe To Our Newsletter

Get updates and learn from the best

You may like to read this

UI Test Automation – what’s possible and what is not

The central reasons to automate any business task are speed and convenience. Think of the consumers opting to get a dishwasher. They want to eliminate the drudgery of washing utensils and the time and the…
ui over ux

Taking The Step From UI To UX

Terms such as user experience (UX) and User Interface (UI) are commonly used and are now in uber-focus while discussing web or mobile application development. In fact, many use these two terms interchangeably. Some others…
Scroll to Top