Agile Methodology Done Right

Ajitesh Shukla
Aug 6, 2019 · 5 min read

What is Agile?

Agile software development implies software development methodologies anchored on the idea of iterative releases, where requirements and solutions evolve through collaboration between self-organising, cross-functional teams. The ultimate value in Agile development is that it enables teams to deliver value faster, with greater quality and predictability, and greater aptitude to respond to change.

Challenges with Agile

Agile without adaptation and good planning does more harm than good. Agile in it’s ideal shape should serve as a catalyst / tool for progressive elaboration on requirements, better sprint planning and refactoring cycles.

In bad shape Agile results in loads of technical debt, unwanted context switches and poor flow efficiency. Implementing Agile well is a collective effort from management, product leads and developers. Let us first look at issues which are commonplace across orgs practicing Agile:

Management Issues

Committing deadlines without / inadequate consultation: Management often commits deadlines externally with inadequate consultation with the stakeholders. Let me put up one such sample communication:

Manager: Why don’t you give us an estimate of how long it will take to build something like this?

Product Lead: It’s difficult to give an estimate upfront. We’ll need to do a thorough requirement analysis, account for existing work etc.

Manager: Just give me a rough sense considering this to be your only deliverable.

Product Lead: 2 months give or take.

Manager to Client: It will take around 3 months to delivery.

We’ll ask for estimates and treat them as deadlines
We’ll ask for estimates and treat them as deadlines

Technical Leadership Issues

Sprint planning must take into account cross vertical dependencies and wait time, unplanned seasonal work, sequencing of deliverables to improve clarity with every release. Failing to plan these properly leads to a lot of context switch and wait time.

Overall schedule must include smartly planned refactoring cycles in between regular sprints. Failing to do this results in everlasting technical debt and a frustrated tech team.

How to do it right

Agile makes progressive elaboration for requirements fairly simple. An iterative model like Agile can help you split the overall requirements into multiple segments of different confidence values. Confidence value here is directly proportional to the clarity that Client /Org has on the requirement.

Creating these segments can enable the execution teams to:

  1. Plan the sprint right. (Mix of items with different confidence values)
  2. Re-engage with client / org to increase the confidence value of some of the requirement segments in subsequent iterations.

After requirement segmentation is done, creating milestones and splitting them across sprints is the next heavy duty task. There are 2 ways to go about it:

a) Fix a timeline for the release (often externally driven) and than work in backwards to split the requirements across sprints.

b) Select a mix of items from requirement buckets with very high confidence value and buckets with extremely low confidence value and then extrapolate a timeline for it. Why select a mix and not all low confidence value requirements:

All low confidence items run the risk of giving Client/Org an impression that all progress has been made in the wrong direction.

Development team may feel demotivated with almost all the work running the risk of being scraped.

Having a mix helps with both and gets good clarity by moving some of the requirements to higher confidence buckets after every iteration and keeping the team and client motivated at the same time.

AdHoc requirements from different verticals within org often come up as a bummer when addressing those requires a lot of context switch for the developers. Context switch can often disturb the whole flow of the pipeline and can result in multiple resources being stuck and waiting for the interim releases to go through while some other high priority task is being delivered.

These scenarios can never be completely eradicated unless the org has a strong bench strength. One way to deal with it is to gather seasonal requirements upfront from different stakeholders which may need attention. This exercise if done periodically in between sprints results in lesser surprises and improves team’s ability to make corrections to the timeline well in advance.

Creating buffers for refactors after releasing low confidence requirements is a must. Once low confidence requirements are rolled out after a sprint, it has strong odds of:

  1. Increase in scope of work
  2. Need for refactor.

Hence low confidence line items should be split across first few releases where refactoring is costs less.

Conclusion

There is a lot of scope of improvisation when it comes to Agile methodology. The steps discussed in the article try to capture a big section of issues which are commonplace in our development teams today. With more n more tracking, planning and documentation setups coming up, it’s easy to create and plan sprints well. Success of these sprints and output of each iteration still depends on a whole bunch of subjective aspects of planning.

In the discussed methodology the success of sprints may vary from org to org. Some orgs may be more comfortable pushing all the low confidence requirements into initial few iterations for getting as much clarity upfront as possible. Some orgs may want to demonstrate good progress in quick time with respect to high confidence requirements.

Choose your plan and iterate!!

Remember to follow, share & hit the 👏 button if you’ve liked it!

LinkedIn | Twitter

Yourstory Engineering | Technology

The technology that brings you interesting stories from…

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store