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.

Technical Leadership Issues

Under-planned Sprints:

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.

No Room for Refactoring Cycles:

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

Requirement Segmentation

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.

Extrapolate Timelines from Action Items and not vice versa

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.

Get clarity on floating requirements across verticals in the sprint timeframe

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.

Create buffers for refactoring and replanning in between Sprints

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!!