I‘ve found that building and maintaining a high-performing Agile product development team is a challenge, whether in startups or large enterprises.

I have been in companies where, despite having highly skilled developers and PMs, some teams fail to deliver high-quality work at a good pace. We tried everything to improve performance, but nothing worked. But once in a while, you do find magic. 

I’ve seen a team of average individuals from middle-of-the-road companies thrive. We pushed each other respectfully, iterated on our process, and made tweaks as needed. Velocity, throughput, and quality of data all improved. I wish I could bottle this formula and take it everywhere!

Why is building a nimble, Agile product development process so complicated? Some companies focus too much on hiring the best and not enough on how their product development teams perform. They put candidates through six rounds of interviews and code pairing, then give them a laptop and say, “Good luck!”

In struggling teams, Product, Business, and Engineering often bicker over methodology, metrics, and process changes. This ‘useless fighting’ drains energy and leaves everyone feeling defeated. As a conflict-averse person, I’ve thrown in the towel before things escalated.

Arrogant co-founders can create a toxic culture despite inspirational slogans on the walls. CTOs may leave a mountain of tech debt for new leaders to clean up while claiming to live up to company culture and values. In other words, they’re saying, “This is your problem now, not mine. Fix it ASAP, but don’t change how I run this place.” 

Another challenge is constant pivots in the product development process without letting teams get comfortable with the changes or evaluate the data to drive the next course of action. If we had a bad sprint, we would shuffle the teams.

To stop strong engineers from leaving, we rush to promote them to tech leads, disrupting our newly formed team structure. Even when velocity and quality metrics are down, PMs are told to “ignore the sprint data and tell me a story.” This pursuit of stories is pointless when the data is evident. Shouldn’t the data drive our decisions?

I’m sharing some best practices for setting up a successful Agile product development process based on what’s worked for me. 

Three legs of the stool:

  • The Product Manager should not build an Agile product development process in a vacuum. Collaborate with Product, Engineering, and Design to build and launch your process. This will ensure early buy-in and avoid mistrust and roadblocks. If you have a Product Delivery team, include them too.

Hire producers

  • Many companies have rigid hiring practices and ratio frameworks, but hiring primarily “Producers” is key to team success. Producers deliver results, such as code, bugs, user stories, sales decks, designs, and roadmaps. I prefer hands-on team members to facilitators like Business Analysts and Scrum Masters.

1 + 1 = 3

  • My Russian math teachers would have been horrified by the “1 + 1 = 3” analogy, but I love this concept. Sometimes, teams with members that do not have amazing pedigree on paper ‘kick butt’ while other teams with members that have strong pedigrees underperform. Why is that? The answer may be in the magic dust or how well the teams gel overall. 

Here are some ideas from the best-performing teams in my career:

  • Avoid having multiple tech leads with giant egos on a team. They’ll argue all day about the best approach without accountability or defined roles. It’s like having five-point guards on a basketball team – no one will play defense or rebound.
  • Hire team members who will challenge the status quo, but everyone must row in the same direction once a decision is made. A “blame game” attitude after a failure is unhelpful and demoralizing.
  • Independent thinkers challenge cross-functional leads, creating a healthy culture and keeping egos in check. Deferring to leadership for all critical decisions hurts productivity and morale and drives away top performers, while your ‘middle of the road’ talent will settle for a comfortable gig.
  • Define roles and responsibilities – this is crucial so all the folks in their respective functions stay in their lanes.
  • The product team has to make the roadmap call, prioritize the backlog, make bets on what constitutes an MVP, and define and share internal benefits and value so the whole team aligns with that vision.
  • Engineering makes the call on how to implement and architect the solution. Engineering must also own its tech debt roadmap and champion spending capacity on that with the PMs.
  • Design makes the call on customer experience and customer interaction. So, each feature’s look, feel, and usability can be debated, but ultimately, Design runs the UX/UI show.
  • Data should drive product development decisions, not debate. Data is KING and should trump ongoing debate; all of that is conjecture if not backed up by data. Here are some useful data reports (from Jira or another work-tracking app):
    •  Sprint velocity over time should inform your team about predictability. If the actual vs. expected fluctuates wildly (~>10%), you do not have much predictability and must go back to the drawing board.
    • Capacity allocation for each sprint and over time across:
      • New features
      • Bugs
      • Tech debt
    • A sprint allocation with over 25% capacity for bugs indicates low software development quality. You may be skipping the basics of good requirements, coding practices, or testing to increase velocity.
  • The percentage of sprint allocated to Tech debt: This measure depends on your product’s life cycle. If you’re allocating 0% to tech debt, you’re rapidly creating it. A good rule of thumb is to spend 10-35% on tech debt every sprint.
  • Tagging features to OKRs or KPIs shows if your team’s capacity investment aligns with organizational goals. Start simple by adding tags to report on this measure and build a pie chart. For example, if your key objective is to drive ARR, but you’re only allocating 10% of capacity to ARR-related features, your Product team needs to make better bets.

In conclusion, building a highly engaged team and a nimble yet effective product development process is not easy and requires a bit of luck; like any good marriage or a relationship, you have to luck out with your partner who will roll their eyes for the fifth time when you tell the same story but smile politely in public. Adopting a data-driven approach and a highly repeatable process (with some guiding principles) you can stand on, especially during times of uncertainty, should help.