In today's fast-paced business world, leaders and managers are constantly on the lookout for innovative ways to maximize efficiency and get the most bang for their buck. This is what makes capitalism so dynamic and exciting!

While it's true that not every piece of advice or anecdote, particularly those shared on social media, comes with a seal of authenticity, they often offer valuable insights. These nuggets of wisdom can serve as jumping-off points for meaningful change and improvement.

Navigating the intricacies of agile delivery practices can be challenging, but it's also incredibly rewarding. Don't worry if you've encountered some bumps along the way. These experiences are not setbacks; they're fantastic learning opportunities! The key is to recognize them, adapt, and continue to evolve.

Get ready for an enlightening blog post! We're going to explore real-world examples that show us precisely what to avoid when energizing our agile teams. Then, we'll pivot to effective and inspiring alternatives that will optimize your delivery flow and place the right incentives in just the right spots within your organization.

So, let's get started on this journey to agile excellence!

Related Articles

Motivation via Story Points and Estimation Ceremonies

The link below is an example taken from Reddit where a team is measured by the number of story points they are finishing in a sprint:

As an engineer, my teams performance is measured in number of story points
byu/pykaun inagile

The problem here is the idea that story point output is a static-ish value that represents the effectiveness of a team. If a team is delivering against more story points, they must be producing more work. One of the commenter is correct in their assertion that a team should push back against this idea by simply doubling the number of points they think each task should take to represent the amount of work being finished.

This is simply a game of squishy numbers. Management wants more output so an arbitrary target it is introduced. To meet the arbitrary target, arbitrary estimates will be produced at which point everybody wins... err, everybody looses (sorry things get a bit loose here simply because this is silly).

Representing Output of an Agile Project

There are a few simple truths in business:

  • Businesses want the most value they can get out of the dollars they are spending on labor
  • Agile teams want a stable flow of work that provides value to everyone
  • Customers want quality and value for the dollars they are spending

Where I see businesses go wrong more often than not is simply this: Business leaders are unable to quantify what it really takes to develop software that customers love and employees love to work on.

This often puts Agile teams at a disadvantage because there is a schism between the reality of what it takes to deliver something and the aspirational expectations of stakeholders. Agile is about the give and take between aspirational expectations and realistic delivery goals, needs, and milestones.

Handing down a mandate that story point velocity must go up does not take delivery needs, goals, and milestones into account. Doubling story points does not take aspirational expectations into account.

Business leaders and Agile teams together should take a step back and review the overall breadth of work. They should be discussing blockers to progress, areas for improvement in delivery, and business OKRs to devise plans for how to achieve those goals. Businesses should not be afraid to invest in their Agile teams because those investments, more often than not, yield a great long term ROI. Agile teams should not be afraid to set realistic delivery expectations based off their known state.

Building this balance is what develops customer-centricity and meets the fundamental goal "Customers want quality and value for the dollars they are spending". Setting arbitrary internal goals around what is essentially an estimation of effort+complexity won't fix any real underlying problem.

Story Points Aligning with Time

The link below represents a Reddit post where an individual is trying to rationalize story points against real clock time:

I think story points should be closely tied to time estimate. Anything otherwise really doesn't make sense
byu/neograds inagile

Let's face it, estimation is tough. If we were able to be accurate when guessing how much time something will take to complete, they wouldn't be called estimates.

When looking at story points, if you say "Hey Stew, we need to estimate filling out 12 story points over a 2 week period. Figure out which of these tasks you can complete in that time frame." then Stew can look at a body of work and assume complexity, effort, risk, and ambiguity and report back what he feels like he can accomplish with referential estimates attached.

If Stew is asked the same question using hours, he will ignore external touch points, risk, and any other factor and hyper focus on his own effort to produce exactly what is asked in a very concrete way.

What Is The Right Frame Of Mind For Estimation?

Businesses, and by extension their customers, have expectations about what they would like to see accomplished in a given time frame. Agile teams have a capacity and ability to complete a set amount of work in a give time frame. If the work was static and known work this would be a simple equation to complete. Since a lot of work is generally tangentially related but not the exact same, this equation is generally far more difficult to complete in a deterministic way.

My experience in this space has been this. The business or customers will ask for X capability in a given time frame. My Agile team(s) will work through their estimations via story points in a very pessimistic non-happy path fashion to help illustrate complexity and risk of the ask. Sometimes this goes well and the stars align and everyone is pleased with the result of estimation, but for the sake of argument here let's assume that is not the case. This then gets represented to the business or customer as a negotiation where the business has a few levers to pull:

  1. Reduce or change scope
    • This generally leads to a conversation about what can be realistically achieved in a given time frame.
  2. Increase funding
    • If increased funding can get something going more quickly. Sometimes you cannot spend more to get the same thing faster.
  3. Stop the project and recalculate
    • Sometimes people's expectations between quality and delivery are very misaligned and they are just looking for high level feedback to reset expectations.

While this approach works well for the Agile teams, it generally causes a mild amount of frustration or friction inside of business units who are marching towards targets of revenue generation and are only looking for answers that achieve that goal.

This is where quality must be a measure that is taken along with revenue targets. Any company can build low quality technology to meet revenue targets that their customers end up disliking or is fraught with issues that eventually starts digging deeply into margin. If quality is an additional measure next to revenue then business units have no choice but to make decisions that are both good for the business and the businesses customers.

When quality is measured along with throughput, revenue, and other target focused objectives, the most common levers to be pulled are lever 1 and 2. When tyranny of the urgent is the strongest force, none of the most common sense levers are pulled and it is left up to the individual contributors to make chicken soup out of chicken shi...

So, to answer the question "Should story points should be closely tied to time estimate?", I would say the answer is an absolute no. Time estimates do not take any external factors of complexity, politics, risk, or ambiguity into account and no human no matter how smart they are can ever produce a time estimate that other people will be happy with.

Replacing Humans with Robots

This question on Reddit poses the question, "Can you replace Agile Coaches / Scrum Masters with robots?"

What do you think a platform that replaces agile coaching / scrum masters?
byu/Playful-Clue-175 inagile

I think this question comes from a good place but misses the mark on what these specific roles are providing for a delivery teams, customers, and the business they work for. A clear demotivator for teams is an Agile Coach or Scrum Master that is overbearing and unwilling to work with the teams. They can also be a great motivator when utilized correctly to reduce stress and anxiety for a team putting them into a position of strength and decision making.

Let's dive into each of these.

The Human Side of Agile

In the realm of Agile development, the effectiveness of teams hinges not only on the tools they use but significantly on the human guidance and leadership provided. This is where the roles of Agile Coaches and Scrum Masters become paramount. Let's explore how these roles add value in ways that transcend the capacities of digital tools, benefiting delivery teams, customers, and business leaders alike.

Delivery Teams

Agile Coaches and Scrum Masters offer invaluable human interactions that tools simply cannot replicate in a delivery team's environment. Agile Coaches focus on fostering adaptability and continuous improvement, mentoring teams, and facilitating a cultural shift towards Agile mindsets through hands-on workshops and strategic guidance. They tackle the organizational and cultural challenges that are beyond the scope of tools.

Scrum Masters ensure that teams adhere to Scrum practices, helping to maintain clear priorities and facilitating Agile ceremonies. They are deeply involved in resolving impediments that affect the team's workflow, something that requires a human touch to navigate the intricacies of team dynamics and project management.

While tools can automate and streamline processes, they lack the capacity for empathy, motivation, and nuanced judgment. Agile Coaches and Scrum Masters excel in these areas, promoting effective communication, conflict resolution, and team cohesion, which are critical components for successful Agile delivery.

Customers

Agile Coaches and Scrum Masters help customers by providing a level of interaction, guidance, and personal service that tools are not designed to deliver. While tools may be configured to automate tasks and generate reports, Agile Coaches and Scrum Masters offer a personalized touch, tailoring Agile practices to meet the specific needs and concerns of the customers.

Agile Coaches engage with customers to understand their vision and business goals, aligning the Agile processes with these objectives. They facilitate collaboration between the customer and the delivery team, ensuring there is clear communication and that customer feedback is integrated into the development cycle effectively. Agile Coaches help customers navigate the complexities of product development, often educating them about Agile methodologies so they can actively participate in the process, providing real-time feedback and adjustments.

Scrum Masters serve as the customers' champions within the development team, ensuring that the team's work is fully aligned with customer expectations. They ensure that the customer is involved at key points in the project, such as during reviews and planning sessions, which allows the customer to understand the progress, provide feedback, and reprioritize work as necessary. This is particularly important as customer needs evolve over time, requiring a flexible approach to product development.

The human element that Agile Coaches and Scrum Masters bring cannot be understated. They are skilled at interpreting the nuances of customer interactions, managing expectations, and fostering trust through transparency and clear communication. Tools lack the ability to build relationships and cannot adapt to the subtle shifts in customer mood and preference, whereas Agile Coaches and Scrum Masters excel in these areas, ensuring that the customer's voice is heard and acted upon throughout the project lifecycle.

The Business And Business Leaders

Agile Coaches and Scrum Masters provide business leaders with strategic insights and operational guidance that go beyond the capabilities of digital tools. While tools can manage workflows, track progress, and facilitate certain types of communication, they lack the ability to offer the nuanced consultation and tailored advice that business leaders often need to drive transformation and achieve organizational goals.

Agile Coaches assist business leaders in understanding and implementing Agile methodologies at a strategic level. They provide expertise in change management, helping leaders to cultivate an Agile mindset across the organization. Agile Coaches support leaders in envisioning an Agile transformation roadmap, identifying potential obstacles, and developing strategies to overcome them. They can interpret the unique challenges and opportunities of a business, aligning Agile practices with the company's strategic objectives.

Scrum Masters, with a more focused approach, support business leaders by ensuring that development teams are aligned with the business goals. They facilitate communication between the development team and stakeholders, translating technical challenges and progress into business language that leaders can understand. Scrum Masters also provide leaders with insights on team performance and product development, helping to make informed decisions based on empirical evidence from the team's work.

Both roles serve as crucial links between the technical teams and business leadership, ensuring that the Agile processes are generating value and that the teams are delivering products that meet market demands. Unlike tools, Agile Coaches and Scrum Masters can preemptively identify issues that might not be evident through metrics alone, such as team morale, stakeholder engagement, and the quality of collaboration. They also advocate for and facilitate the continuous learning and improvement of both teams and leaders, thus driving a culture of innovation and responsiveness that is vital in today's fast-paced business environment.

Conclusion

I hope you got something from this article about missteps you may have made in your Agile journey. I will continue to add content to this page as I find new and interesting ways that industry has tried to motivate Agile teams to shed additional light on better forms of motivation.