Viewing entries tagged with 'product teams'
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.