A simple litmus test can help determine whether a product team is the real thing or wearing a different name.
Marketers have been trying to dress up spam, ever since the odd can-shaped meat was invented. It has been called “special processed American meat,” “shoulders of pork and ham” and even “spiced ham.” But, no matter what you call it, Spam is still spam.
Dressing Up is Not Just for Canned Meat
Something similar has been going on in IT. We are getting makeovers as well.
Instead of putting in the hard work of changing culture, organization and operating model, we are simply just relabeling the status quo.
For example, projects are now called products, development teams are called squads, meeting are called standups, small sprints are called MVPs and everything is now an experience. The list goes on. But the underlying structure and organization has not changed.
Maybe executives are hoping that the change in name might just bring about the culture change that they are seeking. But at the end of the day, these newly coined product organizations are still slow, costly and risky, and companies continue to publish subpar code.
Separating Truth from Fiction
So how can you tell the difference between a real product organization versus one that is pretending to be? How can you tell if the organization has put in the effort and time to make the real changes versus just a name change? Consider this litmus test:
- The team is made up of cross functional SMEs, which includes all the various skill sets (Business, UX, Dev, Test, Ops Etc.) required to ship a product/increment.
- There is a dedicated product owner and a scum master.
- The product owner is the single owner responsible for both, output (business KPIs) and input (resources) and everyone on the team and within the organization knows about it.
- The scrum master helps the product team stay on track, removes impediments and shields the team from external distractions.
- The squads are judged on their impact to business metrics (business KPIs are tied to every new feature released).
- The teams are autonomous; they (not someone from the outside) decide how much work to commit during a sprint.
- The team keeps the backlog well-groomed and accurate, and resolves issues without escalating to management.
- The executives trust the product team to do the right thing within a sprint.
- Minimal viable product is the default delivery mode and cycle time (development to release) is no more than a few sprints.
- For every feature the team has agreed on the definition of done, its business impact and how to measure that impact before it goes into development.
- Product team uses continuous integration (which includes a agile development, branching strategy, on-demand environment, automated build and test and strict quality gates).
- Feedback is part of the product team’s DNA; failure is expected and is considered as an opportunity to learn.
If your team espouses the above characteristics, congratulations: You passed the test. More importantly, your organization has done most of the heavy lifting and created a truly high-performing product team. That’s no small feat.
However, if your team does not share many of the above characteristics, then you have your work cut out for you.
Good luck.