Software Productivity

    Agile In Practice: How to Increase Your Dev Team's Sprint Performance

    Posted by Peter Cronin on Mar 23, 2020 5:36:46 PM
    Find me on:

    Is your software development team running sprints to plan, complete, and review deliverable work? The introduction of Agile practices and principles in the software development industry created a massive shift in the way software development was managed. This resulted in the ability for faster release of products to market and better market fit. If you’re looking to grow your company, increasing your team’s sprint performance can give your company a competitive edge or just eliminate some of those day-to-day challenges that are hanging around the edges and burning capacity.

    Large-group-of-computer-programmers-working-on-desktop-PCs-in-the-office.-964800938_1258x839

    Day-to-Day Challenges of a Sprint Holding Back Your Team’s Sprint Performance

    The two most common challenges we hear from software development team leaders and developers are:

    Developers work on their tasks in isolation

    Many software developers tend to say, “These are the tasks with my name on it that were planned out for this sprint, so that's all I have to worry about.” Depending on the length of the sprint, teams may see their developers go away and put their head down to work on something, and not hear any communication or updates outside of the daily stand-up until their individual task is finished. Although the daily stand-up can help communicate any task blockages or alert the team if assistance is required, this narrow individual focus on the individually assigned work can lead to task times blowing out and uncertainty of when handovers will occur.

    Different software development teams will have different ways of managing their work during a sprint. Some teams will be using a Kanban-style board or system while other teams may be using an Excel list or digital task management system. These systems are often helpful for increasing visibility of which tasks are being ‘worked on’ or are ‘in progress,’ but commonly fail to show information such as the progress made or estimated handover time. When a developer has more than one task in play (multitasking), there is often no distinction visible to show which tasks are ‘waiting’ and which task is currently being worked on.

    This lack of information can burn time during a sprint if people have to keep checking in to see if a task is done yet or if managers don’t intervene early enough when a task falls behind. Often, workflows with low visibility suffer from surging workflows or delayed handovers. This challenge is magnified when also combined with developers working on their tasks in isolation.

    There are many interruptions during the sprint

    The longer the sprint time, the more interruptions will occur from various sources. Two of the biggest interruptions for developers during a sprint are people shoving work into the sprint and unplanned work that must be done on top of the sprint.

    • Shoving work in during the sprint:
      • Founders, owners, heads of customer service, and salespeople with ‘important’ clients are the biggest culprit of this.
    • Unplanned work that is additional to the sprint:
      • Many software companies have a service-level agreement with customers that bugs of a certain category will be fixed within x Often, the company will not have resources allocated solely to fixing bugs so urgent bug fixes interrupt planned sprint work.

    Frequent multitasking and interruptions lead to decreased productivity and sprint performance as developers have more ‘pick-up, put-down’ time and less ‘in the zone’ uninterrupted time.

    Two Expert Tips to Increase Your Team’s Sprint Performance

    If you recognise these challenges in your software development team then don’t worry, you’re not alone, and there is a way to address these issues!

    Encourage your team to work together, not in isolation

    Rather than developers looking at their individual tasks, we want developers to be looking at the whole team’s work when considering what needs to be completed in the sprint. Team leaders and developers can help create this shift in focus by encouraging others to look out for tasks later on in the week that they need to do. Individuals still need to look at their individual currently assigned tasks, but having an awareness of how the rest of the team is tracking, and the status of future tasks they will interact with, allows a developer to be able to plan their time better.

    From an overall team perspective, it encourages more teamwork; developers that are ahead of where they need to be during the sprint can help out those who might be tracking behind because a task estimate wasn’t quite right, etc.

     

    When the team works together as a whole, there are increased opportunities for developers to:

    • adjust the plan accordingly;
    • ask for help;
    • talk to other people in the team to get a new perspective when they’re blocked; and
    • point out tasks that are not going to plan or are bigger than expected.

    The increased visibility and communication from a team focus actually allows software developers more freedom and creates less stress as handovers and sprints run more smoothly. There is less management oversight or ‘nagging’ as team leaders can quickly ask anyone how the sprint is going and know the team has each other’s back.

     

    Prevent unexpected or unplanned work from derailing your sprint with a buffer and priority status

    We can minimise the interruptions or ripple effects of unplanned work by building a small buffer of time into the sprint. This means only planning to use, for example, 80% of the team’s capacity and keeping the remaining capacity free to deal with work created by service-level agreements or other interruptions.

    This isn’t a buffer to absorb the variation from shoving work in – we still want to prevent work from being shoved in wherever possible. If the work isn’t required for a service-level agreement, add the urgent item(s) to top of the queue for the next sprint. If you find your sprints are regularly being derailed because key stakeholders can’t wait until the next sprint, consider the length of sprint you’re using. Often, people feel they can wait one week, maybe two at most, but waiting a month for the next sprint to get the work done can be too long.

    Summary

    So, whether you’re looking to increase the sprint performance of your team to gain a competitive advantage or you’re just looking to get rid of some of the day-to-day challenges you face, looking at how you manage the sprint execution is key. When developers work together as a team and there are mechanisms to prevent unexpected work from derailing the sprint, the flow of work is smoother and sprint performance rises.

     

    eBook download link

     

    About the Software Productivity Blog

    A collection of effective guides on Productivity improvement initiatives and implementation ideas to ensure productivity projects have significant system wide benefits. 

    You will read content related to:

    • Process of Continuous Improvement
    • Workflow Management
    • Behavioural/Change Management

    Subscribe to Email Updates

    Recent Posts

    Posts by Topic