Viewing entries tagged with 'product teams'
Exactly a year ago I was invited to give a keynote at the Craft Conference in Budapest and I discussed the 10 biggest reasons why product teams fail. You can watch that talk here, or read the narrative article here.
To continue on the series on team autonomy (see autonomy vs. leverage, autonomy vs. mission and autonomy vs. ownership), I wanted to add one more important dimension to this discussion which concerns the practical implications of working on large, multi-team initiatives.
In my recent articles I have been exploring the critically important but complex topic of autonomy of product teams. First we discussed the trade-offs between autonomy and leverage, and then we discussed the trade-offs between autonomy and mission. From your feedback I know this is a subject that is important to many of you, and I realized there was one more dimension to this discussion that I should also put out there, and that has to do with the trade-offs between autonomy and the concept of ownership, especially code ownership.
In my last article I discussed the trade-offs between the sometimes conflicting goals of team autonomy versus leverage. Quite a few of you wrote to me and said this was a hot topic at your company, and several asked about the same basic topic, but less from an engineering perspective and more from a product and design perspective. This issue comes up enough in different forms that I thought it was worth elaborating on.
Virtually every leading tech company has jumped on the empowered, dedicated/durable, cross-functional, collaborative product team bandwagon, and I think things are much better for it. I don’t see very many companies that are still using the old models (primarily the pool model).
I have long written about the importance of dedicated, durable product teams and that we should always strive to optimize for the team and not for the individual function (e.g. product management, user experience design, engineering, test automation, data science, etc.). It’s not hard to spot when teams have not embraced this model, as you see lots of organizational silos and “walls” between members of the team.
NOTE: My friend and colleague Jeff Patton is the author of an upcoming book on the general topic of User Stories and especially the technique of Story Mapping. I was asked to write a foreword for this new book, and this article is an excerpt from the foreword. I was also a reviewer of the book and it is definitely a must-read for any product person and fills a very big gap in the current library of Agile titles. If you’d like to pre-order the book you can do so from O’Reilly.
Note: This article is a collaboration between myself and my long-time friend and colleague Jeff Patton. We often work together to help product teams.
In my last article, I discussed how we manage public commitments in an Agile, Dual-Track environment. In that article I talked about those public commitments that are needed to run a business, such as when a customer can count on getting some capability, or when a development partner can plan on testing, or determine what will be available for the upcoming holiday season.
If your company is one that still allocates product development funds based on approval of projects, then you still have the old “project-based funding model.” This is mostly a situation in either large companies, or those that have an IT-style legacy, but the mindset often exists even in small companies too.