How to bring agility back to sprint planning

In software development today, it often seems like there are just two ways of doing work: the agile way and the wrong way. Agile - deservedly- came into the spotlight in the 2000s as a complete departure from previous hierarchical methodologies of software development. The Agile Manifesto put people ahead of processes, continuous integration over fixed project plans, and autonomy over supervision. On the face of it, this is the perfect approach for tech companies that have to grow at break-neck speed. What could go wrong?

Unfortunately, agile today has become less of a mindset and more of a set of protocols - the very thing it was fighting against. Development teams have to contend with a number of abbreviations, ceremonies, and processes if they want to be dubbed ‘agile’. Consultants have built entire businesses around preaching agility to companies. In the midst of this, agile has become just another buzzword that many teams claim to be but very few are. How do we strip down Agile to its bare essentials and enable software companies to build at the pace of CI/CD required to succeed?

Impact of rigid sprint planning

As the complexity and scale of systems increase, tools and processes can get in the way of teams staying agile. If your team is getting bogged down by the many protocols around agile, it’s not agile. If your sprint can’t differentiate between high-urgency tasks and high-impact tasks, it’s not agile.

Process-heavy sprint planning can affect the ability of modern tech companies to be nimble.

Affects pace of CI/CD

An accelerated pace of CI/CD is especially important for modern tech companies to bring their products to market faster. Feature requests and bug fixes need to be sorted through and code needs to be consistently deployed into production. Adamantly sticking to the processes in the agile methodology could mean that your sprints don’t allow for this kind of flexibility. The amount of planning and documentation required for sprints can almost make it seem like waterfall dressed in agile clothing.

Developers lose motivation

Agile is often criticized for reducing developers to merely cogs in a machine. As Miriam Posner points out in her detailed critique ‘Agile and the Long Crisis of Software’, “Daily standups, billed as lightweight, low-key check-ins, have become, for some workers, exercises in surveillance. Particularly when work is decomposed into small parts, workers feel an obligation to enumerate every task they’ve accomplished.” Sprints are often myopic to-do lists that don’t provide developers with any visibility of how their work actually impacts the end customer.

Ceremonies and protocols hinder speed

The Agile religion is steeped in abbreviations and ceremonies that can be daunting for development teams to follow. Teams can often get so wrapped up in getting agile ‘right’, that they lose out on the true essence of agile: bringing speed and customer-centricity to software development.

How do we make agile customer-centric again?

Does this mean there’s no place for Agile development anymore? Far from it. The core principles in the Agile Manifesto are probably more important today than ever before. Modern software companies need to iterate faster, customer feedback flows in from multiple channels, and AI is fundamentally changing the way development work is organized. Re-examining some of the agile principles shows that there’s possibly no methodology better suited for this scenario:

• Satisfy the customer through early and continuous delivery of valuable software
• Welcome changing requirements, even late in development
• Simplicity–the art of maximizing the amount of work not done–is essential
• Business people and developers must work together daily throughout the project
• Build projects around motivated individuals

The problem then isn’t with the philosophy itself, but in how it’s implemented. For software teams to be truly agile, it’s time to move away from heavy agile SCRUM methodologies that drive regimented delivery of work in preset time boxes. At DevRev, we have removed the many ceremonies and manifestos around agile to build a more simplified version using automation and opinionated workflows. How do we make the leap from ‘doing’ agile to ‘being’ agile?

NNL for smaller teams

For smaller development teams, following the agile methodology to a T can be overkill. Non-development teams also stay far from sprints because of its complex terminologies and reputation as a process only for software teams. In these cases, organizing work in a Kanban-style system can be far more effective than traditional sprints. DevRev offers an NNL (Now, Next, Later) Kanban view that is simple to use and intuitive to understand. All work is organized into three stages:

• Now: Work that is actively being done
• Next: Work that is immediately next on the roadmap
• Later: Work that needs to be taken up but is not an immediate priority

Issues - fundamental units of work in DevRev - can be easily grouped by stage to sort them into the NNL view.

• Now - All issues in the stages ‘In Development’, ‘In Review’, ‘In Testing’, and ‘In Deployment’ are automatically grouped under ‘Now’
• Next - All issues in the stage ‘Prioritized’ are grouped under ‘Next’
• Later - All issues in the stage ‘Backlog’ are grouped under ‘Later’

Because of the simplicity of the Kanban-style approach to sprints, even non-dev teams like Marketing can easily use it to sort and prioritize work.

Lean sprint management

For larger development teams or teams that have to manage a large workload with stricter delivery timelines, traditional sprints are still the most effective way to organize tasks. But the way sprints are typically conducted limits visibility of the impact of development work. Developers are focused on just completing tasks in each sprint and are not always aware of the why behind the work they’re doing. This can stifle innovation and creativity, encouraging developers to just complete tasks assigned to them rather than think of new solutions.

Modern tech companies need to empower their developers to drive product innovation. A revamped approach to sprint enables this by connecting work to impact. At DevRev, every issue is mapped to a product ‘Part’ and all discussions and customer tickets related to it happen directly on this issue. This gives developers a more holistic understanding of their work and how it impacts customers.

Sprint discovery

The connection between product development and customer impact needs to be reinforced right from the way sprints are created and discovered. In DevRev, a product is broken down into a set of ‘Capabilities’. Sprint boards are available under each ‘Capability’ and all issues related to that part can be organized within that sprint board.

Trails in DevRev offers a dynamic product hierarchy that captures all customer tickets, top contributors, sprint boards and more under each Capability. Using Trails, the entire organization can view ongoing sprints under each product part and developers can also view directly how issues in each sprint map to product improvements and customer experience.

Sprint planning

Sprints should have flexibility in-built so development teams can create processes that work for them and quickly pivot mid-sprint depending on urgency of incoming tasks. DevRev’s sprint boards allow you to set a sprint duration that works for your team, seamlessly move issues between sprints, and group issues by a set of attributes like owner, parts, stage, etc.

Since each issue also has customer tickets and internal discussions mapped to it, sprint owners will find it easier to understand which issues to prioritize in a sprint. We have also condensed sprint views to just current and previous sprints. In this fast-evolving era of software development, it can be futile to plan beyond two sprints at a time.

Retrospection

Retrospectives are critical to reflect on sprint performance and identify areas for improvement that can be implemented in future sprints. However, without data and analytics, sprint retrospectives can quickly devolve into accusations between teams. We have simplified retrospectives by focusing on four key areas for sprint insights:

1) print burndown charts

Sprint burndown charts show you the amount of work completed versus how much is remaining. Soon, with DevRev’s Turing AI capabilities, you will also be able to get predictive insights into sprint performance and likelihood of completing issues in each sprint.

2) Issue breakdown

This chart helps you get aggregated data on how many issues are in each stage, who the top owners of the issues are, and how many issues fall within each priority stage (P0 to P4).

3) Sprint health

Sprint health allows you to monitor the progress of a sprint and detect scope creep early on.

4) Average time per stage

You can view how much time on average an issue spends in each stage. This can help track velocity of development work and identify roadblocks.

Backlog and issue grooming

Issues that are not picked up in a sprint fall under the ‘backlog’ stage. DevRev converges front-end and back-end teams on the platform, so teams can collaborate easier on prioritizing issues. PMs, engineers, and support teams can regularly review issues in backlog to decide what needs to be picked up on priority for each sprint.

"Backlog grooming and sprint planning is a breeze with clear visibility on the direct impact of work items on product areas and customers”

— Priyanka Pal, Product Management, DevRev

The Agile Manifesto claimed that agile is a mindset and not a set of processes. It’s time to return to the essence of the agile methodology and steer away from the complex rituals that only bloat your development processes. By simplifying sprints and connecting work to customer impact, development teams become motivated to problem-solve rather than simply tick-off tasks.

The Build app in DevRev’s OneCRM is purpose-built for modern software companies. It brings together the knowledge graph of your people, product, and customers on one converged platform. We combine this data with our powerful vector database to bring the voice of the customer to every department and enable product teams to prioritize based on business impact. Get Started.