Remember when the internet was going to eliminate the middle man? How’d that turn out? When Agile software development took the software world by storm, it was like many other paradigm shifts before it. Agile promised to be the next panacea for whatever ailed software companies. And just like the internet, we didn’t know what we didn’t know, but now we’re in a much better place. Here’s a look back at three things that have changed for the better and three things that are still the same.

Three Things That Have Changed for the Better

  1. Sprints: Sprints have made software development teams more productive because they can digest requirements in spoon-size bites versus swallowing the elephant. They’re also more accountable because each sprint comes with more clearly defined scope and deadlines that usually don’t move. Shorter intervals to deliver key features? Who doesn’t love that?
  2. Iterative Design: We get to see products and features evolve as they go through iterations. It has done wonders for product usability versus waterfall where no one saw the end result until it was too late to change it.
  3. The Product Owner Role: Formalizing the product owner role and separating it from the product manager is critical to the long-term success of any product because it gives product managers the capacity to do more of what they should already be doing — spending time with customers to better understand how to make them more successful. In other words, product managers are responsible for drawing the target and product owners are responsible for working with developers to hit that target with the right product capabilities.

Three Things That Haven’t Changed

  1. Business Requirements Definition: Most business requirements are still written in a way that’s slanted more toward making the product better versus making the customer better (more successful). Understandably so, viewing the market through the lens of the customer (versus the lens of the product) is still the single biggest challenge for the product management profession. Spending more time with customers is the only way out of this dilemma.
  2. Waterfall Product Launches: In the early days of Agile, waterfall product launches were considered a crime on par with treason. As it turns out, new products and major releases in B2B software are best launched in waterfall fashion for a host of reasons. Cross-product integration and quality are at the top of the list.
  3. Combining the Product Manager and Product Owner Role: The more things change, the more they stay the same! In the waterfall era, it was quite common to combine the business analyst and the product manager into a single role. It was a train wreck then and it’s a train wreck now! For the small percentage of people who have the skills to do both well, there’s still not enough time in a day to do them successfully. The WHO, WHAT & WHY role (PM) has to be separated from the HOW role (PO/BA). The good news is this: in the Agile world, most organizations don’t need more headcount. They just need to reallocate their headcount so that the ratio of product managers (20-30% of headcount) to product owners (70-80% of headcount) supports the desired throughput of development.

If your product management and Agile development teams need a tune-up, contact Proficientz to discuss how our framework and training programs help you deliver, market and sell more strategic value in an Agile environment.