Tag Archives: Agile

When Three Tech Leads Met: A Lesson in Team Dynamics

Posted on by

The Customer Token Handler project offers an ironic illustration of Tuckman’s stages of group development – specifically how a highly skilled group can easily fail due to team dynamics. At a major technology company in Southeast Asia, an experiment in temporary team formation produced an unexpected lesson in ineffectiveness.

The setup appeared logical on paper. Three seasoned technical leads from Mobile, Homepage, and Supply Extranet domains would combine their expertise for two sprints in a temporary 3 person team. The mission: create a unified token handling library for customer authentication. Experience suggested their combined expertise would accelerate delivery.

Hour one revealed the fundamental flaw. The Homepage lead populated JIRA with exhaustive tickets. The Mobile lead covered whiteboards with sticky note tasks. The Supply Extranet lead, not one for the bureaucracy of planning, just started writing code. Three experts, three methodologies, zero progress. No forming, straight to storming, never reaching norming.

The two-sprint experiment dissolved afterwards without a working solution. The project appeared destined for failure until one technical lead took ownership. Working alone, they completed the token handling library in another two weeks – accomplishing more solo than the combined team had achieved together in double that time.

This outcome challenged conventional wisdom about collaborative development. While the three-person team generated extensive documentation, diagrams, and partial implementations, they never established the shared context necessary for effective collaboration. The eventual solo success demonstrated how reduced coordination overhead can sometimes accelerate delivery, did we end up with a better product from the solo lead? probably not, but its a working one at least that we can iterate on.

The Customer Token Handler story reshaped our approach to temporary team formation. It highlighted how Tuckman’s stages cannot be shortcuts, even with experienced technical leaders. Teams should be long lived to be effective.

We must never look at Engineering teams like a scheduling problem to solve, they are people, they have the same flaws and quirks as people do, we need to acknowledge them beyond their IC number in order to create winning teams.

Technical North Star Metrics: The Currency of Product Success

Posted on by

There’s a saying in business that “what gets measured, gets managed.” But in the complex world of modern software systems, choosing what to measure can be as crucial as the measurement itself. Enter the concept of Technical North Star metrics – not just another KPI, but a fundamental compass that guides technical decisions and shapes organizational behavior.

The Power of a Single Number

When I first encountered the concept of a Technical North Star metric at a previous organization, I was skeptical. How could one number capture the complexity of our technical systems? But over time, I’ve come to appreciate the elegant simplicity it brings to decision-making and incident management.

The most effective Technical North Star metrics share three key characteristics: they’re ubiquitous throughout the organization, they directly correlate with business success, and perhaps most importantly, they’re actionable at every level of the technical organization.

Consider Netflix’s “Total Watch Time” or Facebook’s “Daily Active Users.” These aren’t just vanity metrics – they’re deeply woven into the technical fabric of these organizations. Every engineer, product manager, and executive speaks this common language, creating a shared understanding of success and failure.

From Metric to Currency

One of the most enlightening perspectives I’ve encountered came from a manager who described our Technical North Star metric as a “currency.” This analogy perfectly captures how these metrics function within an organization.

At Agoda, for instance, “Bookings” serves as this universal currency. While I can’t share specific numbers, what’s fascinating is how this metric has become part of the engineering team’s DNA. Ask any engineer about current booking rates, and they’ll know the number (though they won’t share it!).

This currency analogy extends beautifully to incident management. When an incident occurs, we can literally “count the cost” in terms of lost bookings. It’s not abstract – it’s concrete, measurable, and immediately understood throughout the organization.

The Art of Measurement

But how do we actually measure these metrics in a meaningful way? The approach needs to be both sophisticated enough to be accurate and simple enough to be actionable.

At Agoda, we’ve developed an elegant solution for measuring booking impact during incidents. We look at four-week averages for specific time windows. For instance, if the 10:00-10:10 AM window typically sees 50 bookings (a hypothetical number), any significant deviation from this baseline triggers investigation. When services are restored and the trend returns to normal, we can calculate the “cost” of the incident in terms of lost bookings.

This approach is brilliant in its simplicity. It accounts for natural variations in booking patterns while providing clear signals when something’s amiss. The four-week average smooths out daily fluctuations while remaining responsive enough to reflect recent trends.

Beyond Incidents: Driving Technical Excellence

The real power of a Technical North Star metric extends far beyond incident management. It shapes architectural decisions, influences feature prioritization, and drives technical innovation.

When every technical decision can be evaluated against its potential impact on the North Star metric, it creates clarity in decision-making. Should we invest in that new caching layer? Well, how will it affect bookings? Is this new feature worth the additional complexity? Let’s AB Test it on bookings.

You can look at the incrementality of these metrics to measure a B variants success which generally translates to direct bottom line value. For example, if we see a B variant is up on 200 Bookings per Day, this language translates to bottom line impact that’s easy for any engineer to understand. Connecting you day to day work to impact is very important for motivation of staff.

The Human Element

Perhaps the most underappreciated aspect of Technical North Star metrics is their impact on organizational behavior. When everyone from junior engineers to senior architects speaks the same language and measures success by the same yardstick, it creates alignment that no amount of process or documentation can achieve.

This shared understanding breaks down silos between teams. When a front-end engineer and a database administrator can discuss the impact of their work in terms of the same metric, it creates a foundation for meaningful collaboration.

Looking Forward

As our systems grow more complex and our organizations more distributed, the importance of having a clear Technical North Star only increases. The metric must evolve as our products and markets evolve. What worked yesterday might not work tomorrow.

The key is to maintain the balance between stability and adaptability. Your Technical North Star should be stable enough to guide long-term decisions but flexible enough to remain relevant as your business evolves.

The next time you’re evaluating your organization’s technical metrics, ask yourself: Do we have a true Technical North Star? Does it drive behavior at all levels of the organization? Is it serving as a currency for technical decision-making? If not, it might be time to look up and reorient your technical compass.

Remember, the best Technical North Star isn’t just a metric – it’s a shared language that aligns technical excellence with business success. And in today’s complex technical landscape, that alignment is more valuable than ever.

The Impact of Paved Paths and Embracing the Future of Development

Posted on by

Throughout this series, we’ve explored the concept of paved paths, from understanding the problems they solve to implementing them with practical tools like .NET templates. In this final post, we’ll examine the broader impact of paved paths on development culture and look towards the future of software development.

The Cultural Shift: Embracing Paved Paths

Implementing paved paths is more than just a technical change—it’s a cultural shift within an organisation. Let’s explore how paved paths influence various aspects of development culture:

1. Balancing Standardization and Innovation

Paved paths provide a standardized approach to development, but they’re not about enforcing rigid conformity. As David Heinemeier Hansson, creator of Ruby on Rails, aptly puts it:

“Structure liberates creativity. The right amount of standardization frees developers to focus on solving unique problems.”

Paved paths offer a foundation of best practices and proven patterns, allowing developers to focus their creative energy on solving business problems rather than reinventing the wheel for every new project.

2. Fostering Collaboration and Knowledge Sharing

With paved paths in place, developers across different teams and projects share a common language and set of tools. This commonality facilitates:

  • Easier code reviews across projects, everyone is following similar structure and standards
  • Simplified onboarding for new team members, you dont need to maintain a lot of onboarding docs yourselves, you can lean on centralized docs more
  • Increased ability for developers to contribute to different projects, the other projects in my company look kinda like mine

3. Continuous Improvement Culture

Paved paths are not static; they evolve with the organization’s needs and learnings. This aligns well with a culture of continuous improvement. As Jez Humble, co-author of “Continuous Delivery,” states:

“The only constant in software development is change. Your templates should evolve with your understanding.”

Regular reviews and updates to your paved paths can become a focal point for discussing and implementing improvements across your entire development process.

4. Empowering Developers

While paved paths provide a recommended route, they also empower developers to make informed decisions about when to deviate. This balance is crucial, as Gene Kim, author of “The Phoenix Project,” notes:

“The best standardized process is one that enables innovation, not stifles it.”

By providing a solid foundation, paved paths actually give developers more freedom to innovate where it matters most.

As we conclude our series, let’s consider how paved paths align with and support emerging trends in software development:

Microservices and Serverless Architectures: Paved paths can greatly simplify the creation and management of microservices or serverless functions. By providing templates and standards for these architectural patterns, organizations can ensure consistency and best practices across a distributed system.

DevOps and CI/CD: Paved paths naturally complement DevOps practices and CI/CD pipelines. They can include standard configurations for build processes, testing frameworks, and deployment strategies, ensuring that DevOps best practices are baked into every project from the start.

Cloud-Native Development: As more organisations move towards cloud-native development, paved paths can incorporate cloud-specific best practices, security configurations, and scalability patterns, primarily from Infrastructure-as-code. This can significantly reduce the learning curve for teams transitioning to cloud environments.

Platform Quality: I see a rise in use of tools like static code analysis to help encourage and educate engineers on internal practices and patterns, which work well with paved paths.

Conclusion: Embracing Paved Paths for Sustainable Development

As we’ve seen throughout this series, paved paths offer a powerful approach to addressing many of the challenges faced in modern software development. From breaking down monoliths to streamlining the creation of new services, paved paths provide a flexible yet standardized foundation for development.

By implementing paved paths, organizations can:

  1. Increase development speed without sacrificing quality
  2. Improve consistency across projects and teams
  3. Facilitate contribution cross system
  4. Empower developers to focus on innovation
  5. Adapt more quickly to new technologies and architectural patterns

However, it’s crucial to remember that paved paths are not a one-time implementation. They require ongoing maintenance, regular reviews, and a commitment to evolution. As Kelsey Hightower, Principal Developer Advocate at Google, reminds us:

“Best practices are not written in stone, but they are etched in experience.”

Your paved paths should grow and change with your organization’s experience and needs.

As you embark on your journey with paved paths, remember that the goal is not to restrict or control, but to enable and empower. By providing a clear, well-supported path forward, you free your teams to do what they do best: solve problems and create innovative solutions.

The future of software development is collaborative, adaptable, and built on a foundation of shared knowledge and best practices. Paved paths offer a way to embrace this future, creating a development environment that is both efficient and innovative. As you move forward, keep exploring, keep learning, and keep paving the way for better software development.

The Evolution of Scrum: A Cautionary Tale

Posted on by

Two decades ago, the software development world witnessed a significant shift. Scrum, a framework within the Agile methodology, was gaining tremendous popularity. This change coincided with a wave of redundancies among traditional project managers. Faced with evolving industry demands, many of these professionals saw an opportunity to reinvent themselves as Scrum Masters.

The true nature of the problem became clear to me when the Project Management Institute (PMI) added an Agile certification, allowing it to contribute points towards one’s overall project management goals.

This certification still exists today, enabling individuals to become “Certified in Agile” through self-study and an online exam. The concept seems utterly foreign to me, especially when I reflect on my experience with the Certified Scrum Master (CSM) course I took with Scrum Alliance years ago. That intensive three-day course was such an eye-opener, fundamentally shifting my mindset. I simply cannot envision anyone truly grasping the core concepts of Agile without face-to-face communication – a principle that, ironically, is a core value in the Agile Manifesto itself.

This transition wasn’t always smooth or successful though. Many former project managers approached Scrum with a mindset still rooted in traditional methodologies. They viewed it as merely a new set of processes to follow rather than a fundamental shift in philosophy and approach.

This misinterpretation led to a superficial adoption of Scrum practices:

  1. Gantt Charts Transformed: The detailed project timelines of Gantt charts were simply repackaged as product backlogs, missing the dynamic and flexible nature of true Agile planning.
  2. Sprint Reviews Misused: Instead of focusing on demonstrating working software and gathering valuable feedback, sprint reviews often devolved into status update meetings reminiscent of traditional project reporting.
  3. Daily Standups Misinterpreted: The essential daily sync-up became a rote status report, losing its intended purpose of team coordination and obstacle identification.

In essence, while the terminology changed, the underlying project management approach remained largely unchanged. This “Scrum-but” approach – “We’re doing Scrum, but…” – became prevalent in many organizations.

This misapplication of Scrum principles highlights a crucial lesson: true agility isn’t achieved by merely adopting a new set of practices. It requires a fundamental shift in mindset, embracing flexibility, continuous improvement, and most importantly, a focus on delivering value to the customer.

As modern software engineers and managers, it’s crucial to reflect on this history. We must ask ourselves: Are we truly embracing the spirit of Agile and Scrum, or are we simply going through the motions? The power of these methodologies lies not in their ceremonies, but in their ability to foster collaboration, adaptability, and customer-centricity.

The evolution of Scrum serves as a reminder that in our rapidly changing industry, it’s not enough to change our processes. We must also transform our thinking, our culture, and our approach to creating software that truly meets the needs of our users.

The Unintended Consequences of Rigid Scrum Implementation

Scrum was originally designed as a flexible, adaptive framework for product development. Its creators envisioned a methodology that would empower teams to respond quickly to change and deliver value efficiently. However, as Scrum gained popularity, a troubling trend emerged. Many organizations began to treat Scrum as a rigid methodology, leading to several significant issues:

  1. Ritual Over Results: Teams became more focused on following Scrum ceremonies to the letter rather than using them as tools to improve productivity and value delivery.
  2. Inflexible Sprint Lengths: The idea of fixed-length sprints, while useful for creating rhythm, was often applied too rigidly. Teams lost the ability to adapt to work that didn’t neatly fit into arbitrary time boxes.
  3. Product Backlog as a Wish List: Product backlogs grew unwieldy, losing the crucial connection between backlog items and real customer needs. They became dumping grounds for ideas rather than curated lists of customer problems and needs.
  4. One-Size-Fits-All Approach: Organizations often applied Scrum uniformly across different types of projects and teams, ignoring the need for adaptation based on context.
  5. Overemphasis on Velocity: Story points and velocity, meant to be team-specific measures of capacity, became weaponized as performance metrics, leading to all sorts of dysfunctional behaviors.

“Never mistake motion for action.” – Ernest Hemingway

The results of this rigid application were often the opposite of what Scrum intended:

  • Decreased Agility: Ironically, the rigid application of Scrum led to less agile teams. They became bound by their processes rather than empowered by them.
  • Reduced Innovation: Over-planning and strict adherence to sprints left little room for experimentation. Teams became risk-averse, focusing on meeting sprint goals rather than solving customer problems.
  • Misalignment with Business Goals: The focus shifted to sprint completion rather than delivering business value, creating a disconnect between Scrum activities and overall product strategy.

Signs Your Team Might Be Falling into the Scrum Trap

If you’re wondering whether your team has fallen into a rigid Scrum implementation, here are some signs to look out for:

Ceremony Fatigue: Team members view Scrum events as time-wasting meetings rather than valuable collaboration opportunities.

Velocity Obsession: There’s a constant push to increase velocity, often at the expense of quality or sustainable pace.

Inflexible Planning: Your team struggles to accommodate urgent work or valuable opportunities because “it’s not in the sprint.”

Stale Backlog: Your product backlog is enormous, with items at the bottom that haven’t been reviewed in months (or years).

Sprint Goal Apathy: Sprint goals, if they exist at all, are vague or uninspiring, and the team doesn’t use them to guide decisions.

Lack of Experimentation: Your team rarely tries new approaches or technologies because there’s “no room in the sprint” for learning or innovation.

Lack of User Feedback: Stories come curated from a seeming invisible place in the sky onto the backlog, with little justification as to why we are doing things. After shipping you are “done”, no measurement of impact post release is done, only “feature shipped”.

Scrum Master as Process Police: The Scrum Master’s primary function has become enforcing rules rather than coaching and facilitating. Has your scrum master said lately “No you cant add that story to the sprint, we’ve already started, you need to wait till next sprint”, is this statement Agile?

One-Size-Fits-All Sprints: All your teams have the same sprint length and use the same processes, regardless of their work’s nature. They all measure themselves in teh same way, story points delivered or sprint completion rate, might be everyone’s main measure of success.

Conclusion: Rediscovering Agility in Scrum

The evolution of Scrum from a flexible framework to a rigid methodology in many organizations serves as a cautionary tale for the Agile community. It reminds us that the true spirit of agility lies not in strict adherence to practices, but in the principles that underpin them.

To truly benefit from Scrum, teams and organizations need to:

Focus on Outcomes: Shift the emphasis from following processes to delivering value.

Embrace Flexibility: Adapt Scrum practices to fit the team’s context and the nature of their work.

Foster Innovation: Create space for experimentation and learning within the Scrum framework.

Align with Business Goals: Ensure that Scrum activities directly contribute to overarching product and business strategies.

Continuous Improvement: Regularly reflect on and adapt not just the product, but the process itself.

Remember, Scrum is a framework, not a prescription. Its power lies in its ability to help teams organize and improve their work, not in rigid rule-following. By rediscovering the flexibility and adaptiveness at the heart of Scrum, teams can avoid the pitfalls of overly rigid implementation and truly harness the benefits of agile methodologies.

As we move forward in the ever-evolving landscape of software development, let’s carry forward the lessons learned from Scrum’s journey. Let’s strive to create processes that truly empower our teams, deliver value to our customers, and drive innovation in our products. That, after all, is the true spirit of agility.

The Art of Crafting KPIs That Actually Work

Posted on by

Welcome back to our series on managing self-managing teams! 👋 We’ve reached the final instalment, where we’ll dive into the crucial skill of crafting Key Performance Indicators (KPIs) that truly work for your team. Let’s turn those dull metrics into powerful tools for success!

When Good Metrics Go Bad

Ever presented what you thought was a perfect set of KPIs, only to be met with blank stares or confused looks? You’re not alone. Many of us have faced the dreaded “Why are we measuring this again?” moment. So, how do we create KPIs that inspire “Aha!” moments instead of “Uh… what?”

The Essential Elements of Effective KPIs

Before we start, let’s review the key properties our KPIs should have:

  1. Easily Measurable: No complex calculations or long running batch jobs required.
  2. Team-Focused: Avoid singling out individuals.
  3. Business-Aligned: Clearly linked to company goals.
  4. Actionable: Provides clear direction for improvement.
  5. Motivating: Inspires the team to perform better.

KPIs to Avoid

Just as important as knowing what to measure is knowing what not to measure. Here are some KPIs to steer clear of:

  • Lines of Code: Quantity doesn’t equal quality.
  • Number of Bugs Fixed: Could encourage writing buggy code just to fix it.
  • Hours Worked: We’re after results, not time spent.
  • Story Points: Often arbitrary and not indicative of real progress.

Real-World KPI Success: The Booking Completion Saga

Let me share a story from a company I once worked at. We implemented a KPI around booking completion that became a game-changer. Here’s what made it so effective:

  1. Direct Business Impact: We measured “Incremental Bookings per Day.” This directly showed teams how much they were contributing to the company’s bottom line.
  2. Instant Feedback: The real magic was in the immediacy. As soon as an A/B test was turned on, the numbers started ticking. Our experimentation system was linked to a real-time Kafka feed from the booking website.
  3. Visible Results: We had TVs on office walls displaying dashboards of running experiments. This visibility created a buzz of excitement.
  4. Celebration of Wins: When an experiment showed significant improvement, the Product Owner would take the team out for drinks the day it was taken, when the experiment run finished. It wasn’t uncommon to see teams celebrating their wins at the local bar area in the evenings with a bottle of something and shots on the table.

The excitement was so palpable that one developer even created a Slack bot in his spare time to check experiment results during dinner! He wasn’t going to wait to the next day in the office to see what the users thought about his new feature.

This KPI worked because it connected directly to business impact and provided instant, visible feedback. It almost gamified the process for the engineers, making it thrilling to see in real-time how users responded to new features. The high volume of bookings meant meaningful results appeared quickly, sometimes within minutes.

The result? A highly motivated team, numerous significant wins, and a culture of continuous improvement and celebration.

Aligning Team Metrics with Business Goals

Your KPIs should create a clear line from daily team activities to high-level business objectives. For example:

  • Business Goal: Increase market share
  • Team KPI: “Feature Adoption Rate” (How quickly users embrace new features)
  • Daily Activity: Developing intuitive UI and smooth user on-boarding

Regular KPI Reviews

KPIs aren’t set-and-forget metrics. Schedule regular review sessions with your team to ensure your KPIs remain relevant and effective. Make these sessions collaborative and open to change.

The Ethics of KPIs

Remember these important principles:

  1. Never use KPIs as weapons against your team. Using KPIs punitively creates a culture of fear and discourages risk-taking and innovation.
    Example: If a team’s “Time to Value” KPI is lagging, don’t use it to criticise or penalise the team. Instead, use it as a starting point for a constructive discussion about process improvements or resource needs.
  2. Prioritise learning and improvement over hitting arbitrary numbers. Focusing solely on numbers can lead to short-term thinking and missed opportunities for meaningful growth.
    Example: If your “Feature Adoption Rate” isn’t meeting targets, don’t push features that aren’t ready. Instead, dig into why adoption is low. Are you building the right features? Is user education lacking? This approach leads to better products and sustained improvement.
  3. Celebrate the intent and progress behind the metrics, not just the numbers themselves. This approach encourages a growth mindset and values effort and learning, which are crucial for long-term success.
    Example: Even if a new feature doesn’t immediately boost your “Enthusiastic User Ratio”, celebrate the team’s efforts in user research, innovative design, or technical challenges overcome. This keeps the team motivated and focused on continuous improvement.
  4. Regularly review and adjust KPIs to ensure they remain relevant. As your product and market evolve, yesterday’s crucial metric might become irrelevant or even counterproductive.
    Example: If your product has matured, you might shift focus from a “New User Acquisition Rate” KPI to a “User Retention Rate” KPI, reflecting the changing priorities of your business.

By adhering to these principles, you create an environment where KPIs drive positive behaviour, foster learning, and contribute to both team satisfaction and business success. Remember, the goal of KPIs is to improve performance and guide decision-making, not to create pressure or assign blame.

Wrapping Up: The True Value of KPIs

The real power of KPIs lies not in the numbers, but in the conversations they spark, the behaviours they encourage, and the focus they provide. When done right, KPIs serve as a compass, guiding your team through the complex landscape of product development.

Craft KPIs that inspire, illuminate, and drive your team towards excellence. And remember, in high-performing teams, the best KPIs often become obsolete because the team internalises the principles behind them.

What’s the most effective KPI you’ve used? Or the least useful? Share your experiences in the comments below!

P.S. If this post helped you rethink your approach to KPIs, don’t hesitate to share it with your network. Let’s spread the word about better performance indicators!

Metrics That Matter: The Ultimate Guide to Measuring Self-Organising Team Success (Without Driving Everyone Crazy)

Posted on by

Hey there, data-driven dynamos and agile aficionados! 👋 Ready to dive into the wild world of measuring team success? Buckle up, because we’re about to turn those vanity metrics upside down and discover what really matters in the land of self-organising teams!

The Metrics Maze: Don’t Get Lost in the Numbers

Picture this: You’re in a maze of mirrors, each one showing a different metric. Story points completed! Sprint velocity! Lines of code! Number of commits! It’s enough to make your head spin faster than a hard drive from 1995. 💿💫

But here’s the million-dollar question: Which of these actually tell you if your team is succeeding?

Spoiler alert: Probably none of them. 😱

The Great Metrics Showdown

Let’s break down some common metrics and see how they stack up:

1. Sprint Completion / Story Points

The Good: Easy to measure, gives a sense of progress. 
The Bad: Can be gamed faster than a speedrunner playing Minecraft. 
The Ugly: Focuses on output, not outcome.

2. Meeting Deadlines / Completing Projects

The Good: Aligns with business expectations. 
The Bad: Can lead to corner-cutting and technical debt. 
The Ugly: Doesn’t account for value delivered.

3. DevOps Metrics (Deployment Frequency, Lead Time, etc.)

The Good: Focuses on flow and efficiency. 
The Bad: Can be technical overkill for some teams. 
The Ugly: Doesn’t directly measure business impact.

4. Business Metrics / KPIs

The Good: Directly ties to business value. 
The Bad: Can be hard to attribute to specific team actions. 
The Ugly: Might be too long-term for sprint-by-sprint evaluation.

The Secret Sauce: Metrics That Actually Matter

“Not everything that counts can be counted, and not everything that can be counted counts.” – Albert Einstein

Al wasn’t talking about Agile metrics, but he might as well have been. So what should we be measuring? Let’s cook up a recipe for metrics that actually matter:

  1. A Dash of Business Impact: How many users did that new feature attract?
  2. A Sprinkle of Team Health: How’s the team’s morale and collaboration?
  3. A Pinch of Technical Excellence: Is the codebase getting better or turning into spaghetti?
  4. A Dollop of Customer Satisfaction: Are users sending love letters or hate mail?

Mix these together, and you’ve got a metric feast that tells you how your team is really doing!

The Goldilocks Zone of Measurement

Remember Goldilocks? She wanted everything juuuust right. Your metrics should be the same:

  • Not too many: Analysis paralysis is real, folks!
  • Not too few: “Vibes” isn’t a metric (no matter how much we wish it was).
  • Just right: Enough to guide decisions without needing a PhD in statistics.

The Metrics Makeover: Before and After

Let’s give some common metrics a makeover:

Before: Number of Story Points Completed ❌

After: Business Value Delivered per Sprint ✅

Instead of just counting points, assign business value to stories and track that. It’s like turning your backlog into a stock portfolio!

Before: Code Commit Frequency ❌

After: Feature Usage and User Engagement ✅

Who cares how often you commit if users aren’t clicking that shiny new button?

Before: Bug Count ❌

After: User-Reported Issues vs. Proactively Fixed Issues ✅

This shows both quality and how well you’re anticipating user needs. Crystal ball coding, anyone?

Some of your more technical metrics maybe SLAs as well, for example Quality, we want to deliver business value, without reducing quality.

The user engagement, you can usually glean from some kind of Web Analytics (Google, Analytics, etc), what ever you are using for this focus on the core user actions people are doing on your system, for example with ECommerce it usually Completed booking or step conversion in your funnel. Then these can be near real time even.

The Team Metrics Workshop: A Step-by-Step Guide

Want to revolutionise your team’s metrics? Try this workshop:

  1. Metric Brainstorm: Have everyone write down metrics they think matter.
  2. Business Value Voting: Get stakeholders to vote on which metrics tie closest to business goals.
  3. Feasibility Check: Can you actually measure these things without hiring a team of data scientists?
  4. Trial Run: Pick top 3-5 metrics and try them for a sprint.
  5. Retrospective: Did these metrics help or just add noise?

Repeat until you find your team’s metric sweet spot!

The Metrics Mindset: It’s a Journey, Not a Destination

Here’s the thing about metrics for self-organising teams: They should evolve as your team evolves. What works for a new team might not work for a seasoned one. It’s like updating your wardrobe – what looked good in the 90s probably doesn’t cut it now (unless you’re going for that retro vibe).

The Golden Rules of Team Metrics

  1. Measure what matters, not what’s easy.
  2. If a metric doesn’t drive action, it’s just noise.
  3. Team metrics should be about the team, not individuals.
  4. Metrics should spark conversations, not end them.
  5. When in doubt, ask the team what they think is important.

Wrapping Up: The Metric Mindfulness Movement

Measuring the success of self-organising teams isn’t about finding the perfect metric – it’s about finding the right combination of indicators that help your team improve and deliver value. It’s like being a DJ – you’re mixing different tracks to create the perfect sound for your audience.

Remember, the goal isn’t to hit some arbitrary numbers, it’s to build awesome products, delight users, and have a team that loves coming to work (or logging in) every day. If your metrics are helping with that, you’re on the right track!

So go forth, measure wisely, and may your charts always be up and to the right! 📈

What wild and wacky metrics have you seen in the wild? Got any metric horror stories or success sagas? Share in the comments – let’s start a metric revolution! 🚀

P.S. If this post helped you see metrics in a new light, share it faster than your CI/CD pipeline! Your fellow tech leads will thank you (maybe with actual thank-you metrics)!

The Art of Hands-Off Management: Coaching Self-Organizing Teams Without Turning into a Micromanager

Posted on by

Hey there, tech leads and engineering managers! 👋 Are you ready to level up your leadership game? Today, we’re diving into the delicate art of coaching self-organizing teams without accidentally morphing into the dreaded micromanager. Buckle up, because we’re about to walk the tightrope of hands-off management!

The Micromanager’s Dilemma

Picture this: You’re leading a team of brilliant devs. They’re self-organizing, they’re agile, they’re everything the tech blogs say they should be. But… they’re about to make a decision that makes your eye twitch. Do you:

A) Swoop in like a coding superhero and save the day? B) Bite your tongue so hard you taste binary? C) Find a way to guide without grabbing the wheel?

If you chose C, congratulations! You’re ready for the world of coaching self-organizing teams. If you chose A or B, don’t worry – we’ve all been there. Let’s explore how to nail that perfect balance.

The Golden Rule: Ask, Don’t Tell

“The art of leadership is saying no, not saying yes. It is very easy to say yes.” – Tony Blair

Okay, Tony wasn’t talking about tech leadership, but the principle applies. When you’re tempted to give directions, try asking questions instead. It’s like the difference between giving someone a fish and teaching them to fish – except in this case, you’re not even teaching. You’re just asking if they’ve considered using a fishing rod instead of their bare hands.

Example Time!

Let’s say your team is struggling with large, monolithic tasks that are slowing down the sprint. Instead of mandating “No task over 8 hours!”, try this:

You: “Hey team, I noticed our sprint completion rate is lower than usual. Any thoughts on why?”

Team: “Well, we have these huge tasks that only one person can work on…”

You: “Interesting. How might that be affecting our workflow?”

Team: “I guess it leads to a lot of ‘almost done’ stories at the end of the sprint.”

You: “Hmm, what could we do to address that?”

See what you did there? You guided them to the problem and let them find the solution. It’s like inception, but for project management!

The Five Whys: Not Just for Toddlers Anymore

Remember when kids go through that phase of asking “Why?” to everything? Turns out, they might be onto something. The Five Whys technique is a great way to dig into the root of a problem without telling the team what to do.

Here’s how it might go:

  1. Why is our sprint completion rate low?
  2. Why do we have a lot of long-running tasks?
  3. Why are our tasks so big?
  4. Why haven’t we broken them down further?
  5. Why didn’t we realize this was an issue earlier?

By the fifth “why,” you’ve usually hit the root cause. And the best part? The team has discovered it themselves!

When in Doubt, Shu Ha Ri

No, that’s not a new sushi restaurant. Shu Ha Ri is a concept from martial arts that applies beautifully to coaching self-organizing teams:

  • Shu (Follow): The team follows the rules and processes.
  • Ha (Detach): The team starts to break away from rigid adherence.
  • Ri (Fluent): The team creates their own rules and processes.

As a coach, your job is to recognize which stage your team is in and adapt accordingly. New team? Maybe they need more structure (Shu). Experienced team? Let them break some rules (Ha). Rockstar team? Stand back and watch them soar (Ri).

It’s a great way to introduce a process to them that isn’t overbearing, for example you can say how about we try “X” my way fora sprint or 2, see how you like it and evolve it from there.

The KPI Conundrum

“Not everything that can be counted counts, and not everything that counts can be counted.” – Albert Einstein

Al knew what he was talking about. When it comes to measuring the success of self-organizing teams, you need a KPI (Key Performance Indicator) that’s:

  • Instantly measurable (because who has time for complex calculations?)
  • Team-focused (no individual call-outs here)
  • Connected to business value (because that’s why we’re all here, right?)

Avoid vanity metrics like lines of code or number of commits. Instead, focus on things like deployment frequency, lead time for changes, or even better – actual business impact metrics.

Why instantly measurable? it doesn’t necessarily need to be instant, as long as it’s timely, the sooner you know results the sooner you can change direction, and if its very timely you can even get to the point of gamification, but more on that in another post.

A good KPI sets the course for the team, can solve arguments and helps them course correct if they choose the wrong direction.

It’s also good to agree on SLAs for technical metrics (Quality etc) to make sure we don’t make a decision that trades off long term for short without knowing.

The Coaching Toolkit: Your Swiss Army Knife of Leadership

Here are some tools to keep in your back pocket:

  1. The Silence Technique: Sometimes, the best thing you can say is nothing at all. Let the team fill the void. This will encourage your team to speak up on their own.
  2. The Mirror: Reflect the team’s ideas back to them. It’s like a verbal rubber duck debugging session.
  3. The Hypothetical: “What would happen if…” questions can open up new avenues of thinking.
  4. The Devil’s Advocate: Challenge assumptions, but make it clear you’re playing a role, if you don’t make this clear you may come across overly negative and not supportive.
  5. The Celebration: Recognize and celebrate when the team successfully self-organizes and solves problems.

Wrapping Up: The Zen of Hands-Off Management

Coaching self-organizing teams is a bit like being a gardener. You create the right conditions, you nurture, you occasionally prune, but ultimately, you let the plants do their thing. Sometimes you might get an odd-shaped tomato, but hey – it’s organic!

Remember, your goal is to make yourself progressively less necessary. If you’ve done your job right, the team should be able to function beautifully even when you’re on that beach vacation sipping piña coladas.

So go forth, ask questions, embrace the awkward silences, and watch your team bloom!

What’s your secret sauce for coaching self-organizing teams? Have you ever accidentally micromanaged and lived to tell the tale? Share your war stories in the comments – we promise not to judge (much)! 😉

P.S. If you enjoyed this post, don’t forget to smash that like button, ring the bell, and subscribe to our newsletter for more tech leadership gems! (Just kidding, this isn’t YouTube, but do share if you found it helpful!)

What Makes an Awesome Team?

Posted on by

In our previous post, we established that the primary job of an Engineering Manager is to build awesome teams. But what exactly makes a team “awesome”? In this post, we’ll dive deep into the characteristics of high-performing engineering teams and explore why self-organization is a key factor in team success.

Google’s Recipe for Awesome Teams

When it comes to understanding team dynamics, few studies have been as influential as Google’s Project Aristotle. After years of research, Google identified five key factors that set successful teams apart. Let’s break these down:

  1. Psychological Safety: Can team members take risks without feeling insecure or embarrassed?This is the foundation of all great teams. When team members feel safe to voice their opinions, admit mistakes, and take risks, innovation flourishes.
  2. Dependability: Can team members count on each other to do high-quality work on time?Reliability builds trust, and trust is essential for smooth collaboration and high performance.
  3. Structure & Clarity: Are goals, roles, and execution plans clear within the team?When everyone understands their role and the team’s objectives, it’s easier to align efforts and make progress.
  4. Meaning of Work: Is the work personally important to team members?Teams perform better when individuals find their work meaningful and aligned with their personal values.
  5. Impact of Work: Do team members believe that their work matters?Understanding how their work contributes to the larger goals of the organization can significantly boost motivation and performance.

These factors provide a solid framework for what makes a team “awesome”. But there’s another crucial element that ties into several of these factors: self-organization.

The Power of Self-Organizing Teams

The concept of self-organizing teams is a cornerstone of many modern software development methodologies, including Agile and Scrum. As the Agile Manifesto states:

“The best architectures, requirements, and designs emerge from self-organizing teams.”

But what does self-organization really mean in practice?

According to the Scrum Guide:

“Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team… Development Teams are structured and empowered by the organization to organize and manage their own work.”

Self-organizing teams have the autonomy to decide how to approach their work, distribute tasks, and solve problems. This autonomy directly contributes to several of Google’s success factors:

  • It enhances psychological safety by empowering team members to make decisions.
  • It increases dependability by allowing the team to commit to what they believe they can achieve.
  • It provides structure and clarity by enabling the team to define their own processes and roles.
  • It boosts the meaning and impact of work by giving team members more control over their contributions.

Why Self-Organization Matters

  1. Encourages Ownership: When teams have the power to make decisions, they’re more likely to take ownership of both the process and the outcome.
  2. Increases Engagement: Autonomy is a key factor in job satisfaction. Self-organizing teams tend to be more engaged with their work.
  3. Promotes Responsibility: When team members are involved in decision-making, they’re more likely to take responsibility for the results.
  4. Fosters Innovation: Self-organizing teams can quickly adapt their processes and try new approaches, leading to innovative solutions.
  5. Builds Leadership Skills: In a self-organizing team, leadership is often distributed, giving team members opportunities to develop leadership skills.

The Role of the Engineering Manager in Self-Organizing Teams

You might wonder, “If teams are self-organizing, what’s left for the Engineering Manager to do?” The answer is: plenty!

The shift towards self-organization doesn’t diminish the importance of the Engineering Manager. Instead, it changes the nature of their role. Rather than directing the team’s day-to-day activities, the Engineering Manager becomes a facilitator, coach, and guardian and helps the team maintain autonomy.

In our next post, we’ll explore how to initiate and nurture self-organizing teams, and discuss the delicate balance of providing guidance without undermining the team’s autonomy.

Wrapping Up

Building an awesome team isn’t just about assembling a group of skilled individuals. It’s about creating an environment where psychological safety, dependability, clarity, meaning, and impact are prioritized. By embracing self-organization, teams can take ownership of their work, leading to higher engagement, more innovation, and ultimately, better results.

What’s your experience with self-organizing teams? Have you seen these principles in action? Share your thoughts in the comments below!

Understanding the Role of an Engineering Manager

Posted on by

In the fast-paced world of software development, the role of an Engineering Manager is crucial yet often misunderstood. As we embark on this series exploring the art of managing self-managing engineering teams, let’s start by demystifying what an Engineering Manager really does and why their role is pivotal in building successful tech organizations.

What IS an Engineering Manager?

If I had to distill the essence of an Engineering Manager’s job into one sentence, it would be this:

An Engineering Manager’s job is to build awesome teams.

At first glance, this might seem overly simplistic, but let’s unpack what building awesome teams really entails:

  1. Hiring the right people: This involves not just finding individuals with the right technical skills, but also those who align with the team’s culture and values.
  2. Onboarding new team members: Ensuring new hires can hit the ground running and quickly become productive members of the team.
  3. Skill set management: Making sure the team has the right mix of skills to execute on their projects and meet organizational goals.
  4. Coaching and mentoring: Helping team members improve themselves, grow in their roles, and reach their full potential.
  5. Career development: Providing opportunities and guidance for team members to progress in their careers.

The Split of Work

In my experience, the work of an Engineering Manager typically breaks down as follows:

  • 30% hiring
  • 70% everything else

While hiring is a significant part of the job, it’s that “everything else” that we’ll be focusing on in this series. It’s in this 70% where the real magic of building and nurturing awesome teams happens.

Why Focus on Building Awesome Teams?

You might wonder, “Why not focus on the technology or the product?” The answer lies in a fundamental truth of software development: great products are built by great teams, not just great individuals.

An awesome team:

  • Collaborates effectively
  • Innovates consistently
  • Delivers high-quality work
  • Adapts to challenges
  • Continuously improves

By focusing on building awesome teams, Engineering Managers create the foundation for all of these positive outcomes.

The Shift Towards Self-Managing Teams

In recent years, there’s been a significant shift towards self-managing or self-organizing teams in the tech industry. This approach, championed by methodologies like Agile and frameworks like Scrum, presents both opportunities and challenges for Engineering Managers.

On one hand, self-managing teams can lead to increased ownership, engagement, and job satisfaction among team members. On the other hand, it requires Engineering Managers to adapt their leadership style and find new ways to guide and support their teams without micromanaging.

In the upcoming posts in this series, we’ll dive deep into how to initiate, nurture, and measure the success of self-managing teams. We’ll explore strategies for coaching these teams without undermining their autonomy, and discuss how to create meaningful KPIs that align with business goals.

Wrapping Up

The role of an Engineering Manager is multifaceted and challenging, but at its core, it’s about people. By focusing on building awesome teams, Engineering Managers set the stage for innovation, productivity, and success.

In our next post, we’ll explore what makes a team truly awesome, drawing insights from Google’s groundbreaking research on team effectiveness. Stay tuned!

What aspects of the Engineering Manager role do you find most challenging or interesting? Share your thoughts in the comments below!

Planning for Change: The Fallacy of Long-Term Roadmaps in Software Development

Posted on by

Introduction

In the world of software development, long-term roadmaps have long been a staple of project management. These carefully crafted plans, often spanning months or even years, aim to provide a clear path forward for product development. They outline features, set deadlines, and allocate resources with precision that would make any project manager proud.

But here’s the deal: by the time you start working on that meticulously planned roadmap, the market is already changing. The technology landscape shifts like quicksand beneath your feet, and customer needs evolve at breakneck speed. This creates a fundamental tension between our desire for orderly planning and the chaotic reality of the tech world.

The Siren Song of Long-Term Roadmaps

Despite this tension, companies are often drawn to long-term planning like moths to a flame. It’s not hard to see why:

  1. Illusion of Control: Long-term roadmaps provide a comforting sense of control in an unpredictable industry. They offer a vision of the future that feels tangible and achievable.
  2. Alignment with Business Goals: These roadmaps allow companies to align their development efforts with broader business objectives, creating a narrative of progress that’s easy to communicate to stakeholders.
  3. Resource Allocation: With a long-term plan in hand, it becomes easier (in theory) to allocate resources, budget for future needs, and make hiring decisions.
  4. Compatibility with Traditional Business Cycles: Many businesses operate on annual or multi-year planning cycles. Long-term roadmaps fit neatly into these established rhythms, making them attractive to executives and boards.

The Problems: When Plans Meet Reality

However, as Mike Tyson famously said, “Everybody has a plan until they get punched in the mouth.” In software development, that punch often comes swiftly and from multiple directions:

  1. Rapid Technological Changes: The tech you planned to use might be outdated by the time you implement it. New frameworks, languages, or methodologies can emerge that render your careful plans obsolete.
  2. Shifting Market Demands: Customer needs and expectations can change dramatically in a short time. The feature that seemed critical six months ago might be irrelevant today.
  3. Disruptive Competitors: In the time it takes to execute your roadmap, a new competitor might enter the market with an innovative solution that changes the game entirely.
  4. Estimation Difficulties: Accurately estimating time and resources for software development is notoriously difficult, especially for work that’s months or years in the future.
  5. Stifled Innovation: Rigid adherence to a long-term plan can blind you to new opportunities and stifle the kind of rapid innovation that’s often necessary in the tech world.

Case Studies: The Perils and Promises of Planning

Let’s look at a couple of real-world examples that illustrate the challenges and opportunities in software development planning:

  1. Waterfall Woes at FirstBank: FirstBank, a large financial institution with over 10 million customers, spent 18 months meticulously planning a comprehensive overhaul of their online banking system. The project, codenamed “Digital Horizon,” was designed to modernize their web-based services and improve customer experience.However, by the time they were halfway through development in 2010, the mobile revolution was in full swing. The iPhone and Android smartphones had exploded in popularity, and customers were increasingly demanding mobile banking solutions. Much of FirstBank’s planned desktop-focused features suddenly seemed outdated.The bank found itself in a difficult position. They had already invested millions in the project, but continuing as planned would result in a product that was behind the curve at launch. They made the painful decision to scrap significant portions of their work and pivot towards mobile development. This led to delays of over a year and cost overruns exceeding $30 million.The “Digital Horizon” project, originally slated to give FirstBank a competitive edge, instead left them playing catch-up in the mobile banking space for years to come.
  2. Agile Triumph at QuickPay: In contrast, QuickPay, a small fintech startup founded in 2012, took an iterative approach to developing their peer-to-peer payment app. Instead of planning out years in advance, they released a minimal viable product (MVP) with basic transfer functionality and rapidly iterated based on user feedback.This agile approach allowed QuickPay to pivot quickly when they discovered an unexpected demand. Users were frequently splitting bills at restaurants and bars, and wanted an easy way to divide payments among friends. This wasn’t a feature QuickPay had originally considered as central to their app.Within two months, QuickPay had developed and released a “Split Bill” feature. They continued to refine it based on user feedback, adding capabilities like itemized bill splitting and integration with popular restaurant POS systems.Within a year, the “Split Bill” feature became QuickPay’s main selling point, setting them apart in a crowded fintech market. It propelled them from 100,000 users to over 5 million, capturing a significant market share from larger, more established payment apps.By 2015, QuickPay’s success attracted the attention of major financial institutions. They were acquired by a leading bank for $400 million, a testament to the value created by their, customer-focused development approach.

These examples highlight a crucial truth in the fast-paced world of software development: the ability to adapt quickly and respond to user needs often trumps even the most carefully laid long-term plans.

The Inevitability of Change in Software Development

In the world of software development, change isn’t just common—it’s inevitable. Unlike traditional industries where conditions might remain stable for years, the software landscape can transform dramatically in a matter of months or even weeks. This rapid evolution is driven by several factors:

  1. Technological Advancements: New programming languages, frameworks, and tools emerge constantly, often rendering existing solutions obsolete.
  2. Shifting User Expectations: As users interact with various digital products, their expectations for functionality, design, and user experience evolve rapidly.
  3. Market Disruptions: Startups with innovative ideas can quickly disrupt established markets, forcing everyone to adapt.
  4. Regulatory Changes: Especially in fields like fintech or healthcare, new regulations can necessitate significant changes to software systems.

This constant state of flux means that software development requires a fundamentally different approach to planning compared to other industries. While a construction project can often stick closely to initial blueprints, a software project needs to be able to pivot at a moment’s notice.

The key is to embrace change not as a disruption, but as an opportunity for innovation and improvement. This mindset shift is crucial for success in the dynamic world of software development.

Alternative Approaches to Planning

As Elon Musk once said, “You don’t need a plan. Sometimes you just need balls”, operating without a long term plan is scary for some people, you feel less in control, but once you realize you are in even less control with one, it get’s easier. Here are some alternative approaches that embrace the dynamic nature of software development:

  1. Inspect and Adapt Principle: This principle acknowledges that we can’t predict everything, so we need to regularly examine our progress and adjust our approach based on what we learn. Agile methodologies, in particular, heavily rely on this principle, incorporating regular retrospectives and iterative development to ensure teams can pivot quickly when needed.
  2. Extreme Programming (XP) Cycles: XP introduces an interesting approach with its weekly and quarterly cycles. The weekly cycle focuses on short-term planning and execution, where teams plan at the start of each week and deliver working software by the end. The quarterly cycle is used for reflection and longer-term planning, allowing teams to adjust their course based on what they’ve learned over the past quarter. This dual-cycle approach balances the need for immediate action with longer-term strategic thinking.
  3. Rolling Wave Planning: This technique involves detailed planning for the near-term future, with broader, less detailed plans for the longer term. As time progresses, the plan is continuously updated and the detailed planning “wave” rolls forward. This approach acknowledges that we have more accurate information about the near future and allows for flexibility as we move forward.
  4. OKRs (Objectives and Key Results): This goal-setting framework, popularized by Google, focuses on setting ambitious objectives and measurable key results. OKRs are typically set quarterly, allowing for more frequent reassessment and pivoting compared to traditional annual planning. They provide direction without prescribing specific solutions, giving teams the flexibility to determine the best way to achieve the objectives.
  5. “Just Enough” Planning: This concept emphasizes doing only the minimum amount of planning necessary to start making progress. It’s about finding the sweet spot between flying blind and over-planning. The idea is to do just enough planning to provide direction and alignment, but not so much that it becomes a burden or limits adaptability.

The common thread among these approaches is flexibility. They all acknowledge that plans will change and build in mechanisms for adapting to new information or circumstances. By embracing these more dynamic planning methods, software development teams can stay agile in the face of inevitable change and uncertainty.

Balancing Long-Term Vision with Short-Term Flexibility

While embracing change is crucial, it doesn’t mean operating without direction. The key is to balance a clear long-term vision with flexible short-term planning.

The Importance of Long-Term Vision

A compelling long-term vision serves several crucial purposes:

  • It provides a North Star for decision-making
  • It helps align teams and stakeholders around common goals
  • It inspires and motivates team members

Your long-term vision might be something like “Become the go-to platform for peer-to-peer payments” or “Revolutionize online education.” This vision should be ambitious and inspirational, but also clear and focused.

Combining Vision with Flexible Planning

Here’s how you can maintain your long-term vision while embracing flexible short-term planning:

  1. Set Directional OKRs: Use your long-term vision to inform high-level, directional OKRs. These provide guidance without prescribing specific solutions.
  2. Use Adaptive Roadmaps: Instead of detailed feature lists, create roadmaps that focus on problems to be solved or outcomes to be achieved. This allows teams the flexibility to find the best solutions.
  3. Regular Check-ins: Schedule regular sessions to review progress and reassess priorities (quarterly at most). This allows you to course-correct while still moving towards your long-term vision. Some advice I got on this once, if the project is on fire, bi-weekly check-ins, if the project is running smoothly monthly or even quarterly, if the project is doing “amazing” biweekly, work out what makes them so good and maybe you can apply in other areas.
  4. Empower Teams: Give your teams the autonomy to make decisions about how to best achieve the objectives. They’re closest to the work and often best positioned to respond to changes.
  5. Communicate Constantly: Regularly reinforce the long-term vision while acknowledging and explaining changes in short-term plans. This helps maintain alignment and buy-in.

By maintaining a clear long-term vision while embracing flexible short-term planning, you can navigate the ever-changing landscape of software development effectively. You’ll be positioned to seize new opportunities as they arise, while still moving consistently towards your ultimate goals.

Remember, in software development, the ability to adapt is often more valuable than the ability to predict. Embrace change, stay flexible, and keep your eyes on the horizon.

Implementing More Flexible Planning in Your Organization

Transitioning from long-term roadmaps to more adaptive planning isn’t just about adopting new methodologies—it’s a cultural shift. Here are some tips to help you make this transition:

  1. Start Small: Begin with a pilot project or team. This allows you to test and refine your approach before rolling it out organization-wide.
  2. Educate Your Team: Provide training on adaptive planning techniques. Help your team understand the ‘why’ behind the change.
  3. Emphasize Outcomes Over Outputs: Shift focus from feature delivery to achieving business outcomes. This mindset change is crucial for flexible planning.
  4. Shorten Planning Horizons: Instead of annual plans, consider quarterly or even monthly planning cycles.
  5. Embrace Uncertainty: Teach your team that it’s okay not to have all the answers upfront. Uncertainty is a normal part of software development.

Communicating this change to stakeholders is crucial. Here’s how to manage expectations:

  1. Be Transparent: Explain the reasons for the change. Share both the potential benefits and the challenges you anticipate.
  2. Focus on Value Delivery: Show stakeholders how this approach will lead to faster value delivery and better alignment with business needs.
  3. Use Visual Tools: Employ visual roadmaps or boards to show progress and plans. These can be easier for stakeholders to understand than traditional Gantt charts.
  4. Regular Updates: Provide frequent updates on progress and changes. This helps stakeholders feel involved and informed.

Conclusion

Long-term roadmaps, while comforting, often fall short in the fast-paced world of software development. They can lead to wasted resources, missed opportunities, and products that don’t meet user needs.

Instead, embracing more flexible planning approaches allows teams to:

  • Respond quickly to changes in technology and market demands
  • Deliver value to users more frequently
  • Learn and improve continuously

Remember, change in software development is not just inevitable—it’s an opportunity. By adopting more adaptive planning methods, you position your team to seize new opportunities as they arise and create better products for your users.

Call to Action

As you finish reading this post, take a moment to reflect on your current planning processes. Are they truly serving your team and your users? Or are they holding you back?

Here’s what you can do right now:

  1. Review Your Current Process: Identify areas where your planning might be too rigidly planning or disconnected from user needs.
  2. Start a Conversation: Discuss these ideas with your team. Get their input on how you could make your planning more flexible.
  3. Experiment: Choose one small aspect of your planning to make more adaptive. It could be as simple as adding a monthly check-in to reassess priorities.
  4. Measure and Learn: Keep track of how these changes impact your team’s productivity and the value you deliver to users.

Remember, the goal isn’t to eliminate planning altogether, but to make it more responsive to the realities of software development. Start small, learn as you go, and gradually build a more adaptive, resilient planning process.

The future of your software development efforts—and possibly your entire business—may depend on your ability to plan flexibly and embrace change. Are you ready to take the first step?