Too often in my work have I found teams trapped in a cycle of working at max energy while stakeholders remain dissatisfied with their velocity. The teams work tirelessly to deliver the best results, yet they reminisce times when velocity was higher and stakeholders were more satisfied. The situation arises due to a cascade of factors which can ultimately threaten morale in a vicious downward cycle. The good news is that every team can get out of this situation and get back on track to deliver at high velocity, using the strategies that I describe in this article.
Velocity
In software development, velocity quantifies a team's capacity to complete work items, like user stories or tasks, within specific timeframes, often measured in story points for Agile practitioners. High velocity signifies efficiency and productivity. When measuring a team's velocity, often part of the work is excluded, such as bugs or scope creep.
The Demoralizing Spiral of Diminishing Velocity
As a project progresses, it is not uncommon to see a team's velocity drop. While at first stakeholders are empathetic, recognizing that errors are part of any project, if this decline persists the team's reputation suffers. The team feels this, but attempts to fix the situation fail.
Why?
Overpromise to repair: The team wants to make up for missed deadlines, commits to work harder, and overpromises.
Scope creep to please: Reluctant to disappoint further, the team accepts any new requests without changing the original plan. The workload increases further.
Quality compromises: To meet deadlines the team resorts to shortcuts, compromising the quality of their work. This can introduce bugs and other quality issues, necessitating roll-backs and bug-fixing alongside scope that is already too big. Releases are postponed and blow up.
Escalating Complexity: Projects naturally grow in scale and intricacy, accumulating technical debt and leading to the emergence of spaghetti code. This complexity invariably extends development timelines. The word 'refactor' becoming an increasingly frequently heard term.
Team discouragement: As stakeholders witness prolonged delays and perceived shortcomings, their frustration mounts. And despite their best efforts to rectify the situation, it seems impossible for the team to alleviate the situation. It is frustrating and in in the worst-case scenario can lead to distrust or demotivation.
Understanding these underlying causes is the first step toward breaking free from the cycle of diminishing velocity. Addressing these challenges head-on, adopting effective strategies, and fostering a culture of transparency and collaboration can revitalize the team's commitment and elevate their velocity. So, let's quickly dive into the strategies to revitalize.
11 Strategies to reignite and increase velocity
1. Lead with Humility
The first and most important step to reignite velocity is for the team leader to take ownership of problem, acting like lightning rod for stakeholders' complaints, and a megaphone for the team members' accomplishments. Leading with humility is a leadership style that fosters trust, accountability, and motivation within a team. It involves a team lead taking responsibility for any mistakes made by team members, while celebrating their successes, thereby creating a psychologically safe environment.
When a leader takes responsibility and ownership of any misses of the team, they will create a safe environment where team members dare to take risks. Yet for any achievement in the team, the leader should step aside and celebrate individual team member or the team as a whole.
Here's why it works:
Risk-Friendly Environment: When team members see their leader taking responsibility for mistakes, they feel safer taking calculated risks. They understand that mistakes are part of the learning process and won't lead to blame or punishment.
Motivation through Celebration: Celebrating team members' successes, including your own, motivates them to strive for excellence. It reinforces the idea that their contributions are valued and recognized.
Building Trust: Trust is the foundation of effective teamwork. When a leader consistently acknowledges their own fallibility and celebrates team achievements, trust in their leadership grows. Team members are more likely to follow a leader they trust.
Reducing Fear of Blame: In an environment where leaders readily admit mistakes, team members are less afraid of admitting their own errors. This leads to faster issue resolution and learning from mistakes.
Leaders should strive to create a culture where failures are seen as opportunities for growth, and successes are celebrated. This can significantly enhance team engagement and lead to increase in velocity.
2. Define Clear, Ambitious, and Achievable Goals (SMART Goals)
With clearly defined, ambitious yet achievable goals, the team has a clear path to work towards and stakeholders know what they can expect. These goals help to break down larger projects into manageable chunks. Having goals will help to prioritize and to push back on scope creep.
To maximize the benefits from goal setting, use the S.M.A.R.T. framework: Specific, Measurable, Ambitious, Realistic, and Time-bound.
Specific: A specific goal is clear, well-defined, and focused on a particular outcome. Specific goals provide a clear understanding of what needs to be achieved and leave no room for ambiguity. Instead of a vague goal like "Improve website performance," a specific goal would be "Reduce website load time"
Measurable: A measurable goal includes concrete criteria that can be used to track progress and determine when the goal has been achieved. Measurable goals ensure that there are quantifiable metrics in place to assess success. For example, "Increase monthly website traffic by 25% within one year" is a measurable goal.
Ambitious: An ambitious goal challenges the team or individual to stretch their capabilities and reach for significant accomplishments. Reaching an ambitious goal is more motivating.
Realistic: Realistic goals are achievable within the given constraints, such as available resources, time, and expertise. It's important to set goals that are grounded in reality and aligned with the organization's capabilities. While goals should be ambitious, they should not be so unrealistic that they become demotivating or unattainable.
Time-bound: Time-bound goals have a specific timeframe or deadline for completion. Setting a deadline creates a sense of urgency and helps maintain focus and accountability. Without a timeframe, goals can lack motivation and drift indefinitely.
Examples of non-SMART goals and their SMART equivalent:
Vague | SMART |
Improve our mobile app for customer onboarding. | Develop and launch a mobile app for iOS and Android that streamlines customer onboarding and reduces account setup time from 30 minutes to 10 minutes within six months. |
Make our web application more secure. | Implement multi-factor authentication in our web application, achieving a security audit score of 95% or higher within three months. |
Enhance customer support response times. | Develop and launch a mobile app for iOS and Android that streamlines customer onboarding and reduces account setup time from 30 minutes to 10 minutes within six months. |
Improve security to pass audit | Implement multi-factor authentication in our web application, achieving a security audit score of 95% or higher within three months. |
By applying SMART criteria to your goals, you empower your software development team to take ownership of their work with a crystal-clear understanding of what needs to be achieved, how it will be measured, and when it should be completed. Defining smart goals improves alignment with stakeholders reducing unexpected scope changes. This strategy helps maintain focus, enhances motivation, and provides a sense of accomplishment as milestones are reached, ultimately driving increased velocity.
3. Ruthless Prioritization
A team has many stakeholders to deal with. All stakeholders want to have their request done first. Do not fall into the trap of accepting all new tasks, but put everything on a single prioritized list. Rather than accepting a stakeholder's argument that their request is highest priority, negotiate and communicate clearly that other priorities will be handled first. Consider the effect of prioritization on the S.M.A.R.T. goal that the team is currently working towards.
How ruthless prioritization helps to increase velocity:
focus: The team can focus on finishing a smaller short term scope, rather than attempting to do everything at once. This reduces stress and leads to better results.
higher quality: with the ability to focus on the highest priorities, the team can deliver higher quality results. This produces fewer bugs and errors so the team can continue to create new functionality rather than fixing issues.
expectation management: You'll be surprised to learn quickly that stakeholders prefer a strong "no" to their request, rather than a weak "yes" that leads to unexpected delays and poor quality. With a strong "no", you can work together to look for alternative solutions, while a weak "yes" leads to disappointment. Stakeholders must know what they can expect.
predictability: A publicly displayed single prioritized list shows both the team and stakeholders what they can expect. Stakeholders can more reliably act on that list, helping them to increase their productivity.
4. Empower Stakeholders
Empowering stakeholders is about involving them in decision-making processes and giving them a sense of ownership over the project. This strategy leads to better collaboration and more realistic expectations. Key aspects include:
Transparency: Show stakeholders what's possible and what limitations exist. Transparent communication builds trust and helps stakeholders understand the constraints and trade-offs involved in software development.
Participation in Prioritization: Encourage stakeholders to actively participate in prioritization discussions. When they have a say in what gets done first, they are more likely to support the team's decisions. Do not accept that everything is top priority, but share ownership of ruthless prioritization with the stakeholder. The stakeholder becomes co-owner of the choice what to deprioritize.
Shared Ownership of Outcomes: Stakeholders who feel ownership of the project's outcomes are more likely to be engaged and supportive. They see themselves as partners in the development process rather than mere spectators.
Empowered stakeholders are less likely to demand short-tem changes to planning or to overload the team. This enables the team to focus more on completing work in progress, leading to higher velocity.
Working with empowered stakeholders increases trust and collaboration between the team and stakeholders, further feeding velocity.
5. Pull vs. Push
In a team setting, tasks typically follow a series of stages, such as 'to do,' 'in progress,' 'testing,' 'staging,' and 'done.' Everything between 'to do' and 'done' represents work in progress, a stage where time and resources have been invested but no tangible value has yet been delivered to the customer.
In the default 'push' model, team members take on new tasks from the 'to do' list as quickly as possible, aiming to reduce the size of the 'to do' list. However, a more efficient and productive approach is the 'pull' model, where a team member selects the task that is closest to completion. This approach results in delivering value to the customer at a faster pace, increasing velocity.
The push strategy offers several benefits:
Reduced Work in Progress (WIP): By pulling work only when it can be realistically completed, teams can significantly reduce WIP. This results in less multitasking, improved focus, and faster delivery of individual tasks.
More finished tasks: With a pull approach, teams are encouraged to complete tasks before moving on to the next, increasing the amount of completed tasks to show stakeholders.
Shorter Time-to-Delivery: Tasks are completed faster because there's a clearer sense of what needs to be done next. As a result, the time-to-delivery is reduced, which can greatly boost velocity.
Increased Flexibility: The pull approach allows teams to be more flexible. It's easier to reprioritize tasks that haven't started yet compared to ones that are already in progress.
6. Release Early and Often
The principle of releasing early and often, often associated with Agile development methodologies, involves delivering functional increments of software regularly, and as often as possible.
Though software development teams often consider their work 'done' when it is code complete, tested, and on staging, the work really is only done when a customer gets value, i.e. when it is being used in production. All work in progress is expensive; it has been invested in, but there is no return on that investment until a customer uses it. Besides the increased value of releasing early and often, this strategy helps to increase velocity for a number of reasons:
Shorter time to market: The time between starting a new task and releasing it is reduced because completed tasks do not wait for an artificial release moment.
Reduced Risk: Small, frequent releases are less risky than large, infrequent ones. It's easier to identify and fix issues when changes are incremental, reducing the likelihood of major disruptions. When a rollback is needed, only that most recent small release is rolled back, contrary to a major release where all new functionality (including those that are fault-free) are rolled back.
Iterative Improvement: Frequent releases provide opportunities for feedback and iterative improvement. Teams can adjust their approach based on real-world usage and stakeholder input. New tasks can therefore be better adjusted to changing stakeholder requirements, making the development of new features more efficient and effective.
Maintaining Momentum: Regular releases help teams maintain their development momentum. The rhythm of consistent delivery keeps team members engaged and focused.
Demonstrating Value: Frequent releases allow teams to showcase tangible progress and value to stakeholders. It's a visual demonstration of work completed, boosting stakeholder confidence and trust.
To implement this strategy effectively, teams need robust release management processes and tools to ensure that each release is reliable and well-tested.
7. Team accountability
Accountability is a powerful driver for increasing ownership and motivation within software development teams. It involves setting clear commitments and holding team members responsible for delivering on their promises. Teams that have missed deadlines several times can sometimes become complacent and ignore the estimates and deadlines that they have set.
Key elements include:
Commitment at Sprint Planning: During sprint planning or similar activities, ensure that the team commits to delivering the promised scope. This commitment serves as a clear goal for the sprint or development cycle.
Progress Monitoring: Regularly monitor progress against commitments. Standup meetings or daily check-ins are opportunities to track how the team is progressing and identify any obstacles. Burndown charts are a useful tool for monitoring progress.
Teamwork: When monitoring shows that the team is behind on schedule, the team should work together to get back on track. Tactics like pair-programming and focus-days can help, or perhaps two team members should switch their tasks. Overtime cannot be taboo; as a team you must do what it takes to deliver on your promise.
Responsibility for Outcomes: Emphasize that the team is responsible for delivering what was promised. This accountability extends beyond external factors and reinforces the team's ownership of their commitments.
Motivation through Achievement: Celebrate when the team successfully meets its commitments. Recognizing and rewarding achievements helps to remove complacency, maintain motivation and ambition, and reinforce the importance of ownership.
By holding team members accountable for their commitments, you encourage a culture of ownership and responsibility that directly contributes to increased velocity.
8. Plan for the Unexpected
Planning for the unexpected is a pragmatic approach that acknowledges the reality of software development: things don't always go as planned. By allocating a portion of time to handle unforeseen issues like bugs, scope creep, or underestimated tasks, teams can better navigate challenges and maintain velocity. Key considerations include:
Risk Mitigation: Planning for the unexpected is a form of risk mitigation. It acknowledges that unknowns and uncertainties are part of the software development process.
Flexibility: The buffer provides flexibility to adapt to changing circumstances without disrupting the overall plan. It allows teams to maintain velocity even when unexpected challenges arise.
Opportunity to overperform: In the positive scenario where the buffer isn't needed, the team can pull in extra work and delight the stakeholder.
9. Regularly Reevaluate Plans with Stakeholders
Frequent reevaluation of plans with stakeholders is crucial for adapting to changing circumstances and evolving requirements. This ongoing dialogue ensures alignment and facilitates better decision-making. Key considerations include:
Changing Priorities: As business priorities evolve or new information emerges, plans may need adjustments. Regular check-ins with stakeholders help to confirm that the project is still aligned with their needs.
Adaptability: The ability to pivot quickly in response to changing circumstances is a hallmark of agile teams. Regular stakeholder meetings provide a forum for discussing potential shifts in direction.
Feedback Loops: Stakeholder feedback, when incorporated regularly, leads to more responsive and relevant solutions. It also prevents misunderstandings that can lead to dissatisfaction.
Avoiding Misalignment: The longer plans go without reevaluation, the greater the risk of misalignment between the team's work and stakeholder expectations. Regular check-ins mitigate this risk.
Teams should establish a cadence for these meetings, with at least bi-weekly sessions recommended for staying closely connected with stakeholders. In scrum, the reevaluation happens during sprint review and sprint planning.
10. Measure Scope Creep
Scope creep is continuous or uncontrolled growth in a project's scope, at any point after the project begins. It will often lead to planned work to be postponed in favor of newly added scope. While this is usually viewed from a negative perspective (the team planned to deliver A this week, but hasn't even started yet), measuring scope creep helps to show the team's flexibility to change (the team acted on new insights and delivered higher priority B this week).
When continuously measuring scope creep, the team can calculate an average and better plan for expected scope creep.
The team must act on scope creep in one of three ways:
Improve predictability: if scope creep is measured at an average percentage, release dates can be extended by that percentage to take creep into account. This is not recommended because it can lead to complacency or a vicious cycle of scope creep. It is also incompatible with fixed deadlines e.g. for a bank holiday.
Stick to the plan: Say no to all new requests because you must meet the deadline. This is not recommended because it's better to respond to change and act on new opportunities.
Replace instead of add: Add new scope to the prioritized backlog, effectively pushing the lowest priority items out of scope. This method ensures that the team focusses on what is most important, while maintaining velocity and delivery dates.
A great tool for measuring scope creep is the burnup chart, which visually represents the amount of work done and the project's scope creep (see image).
11. Retrospectives
Retrospectives are a structured process for teams to reflect on their work processes, identify areas for improvement, and celebrate their successes. Conducted regularly, retrospectives promote continuous learning and growth. Here's how they contribute to increased velocity:
Process Improvement: Retrospectives are an opportunity to discuss how the team can improve its processes. By focusing on what worked and what didn't, the team can refine its methods for greater efficiency.
Identification of Pain Points: Retrospectives allow team members to voice their concerns and identify pain points in their workflow. Addressing these issues can remove obstacles to velocity.
Team Bonding: Celebrating successes and openly discussing challenges fosters a sense of camaraderie within the team. This positive atmosphere can significantly boost motivation and engagement.
Iterative Refinement: Over time, retrospectives enable the team to iteratively refine its approach to development. Each retrospective builds upon the insights gained in previous sessions, leading to ongoing improvement.
To make the most of retrospectives, they should be held regularly, ideally at the end of each sprint or development cycle. They should focus on specific aspects of the development process and be action-oriented, resulting in tangible improvements.
Conclusion
The strategies outlined above serve as a roadmap to reinvigorate software development teams, increase their velocity, and create a more productive and harmonious work environment. Each strategy addresses specific challenges that teams commonly face, from workload management to stakeholder engagement and process improvement. By implementing these strategies with care and commitment, software development teams can break free from the cycle of diminishing velocity and emerge as high-performing, engaged, and motivated units, capable of delivering exceptional results that exceed stakeholder expectations. In doing so, they ensure not only the success of their projects but also the long-term health and satisfaction of their team members.
Comments