One of the things I want to do in this loosely structured set of blog posts about Agility (or living out the principles of Agile) is to respond to ideas I am learning from other blogs and articles.  I hope this helps point some of you to good resources out there for learning about product management and Agile.  I even hope it helps contribute to the wider discussion in the Agile community.  If you have been reading my recent blog posts you know I’ve been reading lots of things that other folks are saying about Agile development as it relates to key issues our team is wrestling with.  There have been other good things I’ve read recently that have sparked thinking on my part and I plan to share these pieces and my own thoughts about them in my blog and on twitter.

For this post I want to talk about is a recent article from Silicon Valley Product Group about developing strong product teams.  Here is the link to the original post: http://www.svpg.com/developing-strong-product-teams .  I really enjoy reading these articles and have added a link to the site on the sidebar to my own blog.  In this recent piece Marty Cagan (who wrote a great book called Inspired about product development) and Jeff Patton (who blogs about design and other issues at http://comakewith.us/author/jeff/) pose a series of questions about how to develop and evaluate the strength of a product team and its results.  I found many of these questions truly challenging because they highlight some of the areas where I know we need to keep growing as a team.

They break their questions into four sets, the first of which concerns the team staffing.  I’m glad they started here because I found these questions the most encouraging.  I think we have a strong team of coders, testers, and designers who work well together and with the product owners on the team.  It’s harder for me to evaluate how strong our product owner is since that’s my role and I can feel at times as though I am handling the multiple aspects of this role well and at other times like the gap between what I should be doing and where I actually spend my time is much wider than it ought to be.  But on the whole I think our team is well staffed and that we are growing stronger as we continue to work together.

Moving beyond the team staffing they next ask question about the team context.  These questions have both an internal dimension – how well does the team and specifically the product manager understand how success will be measured by the relevant parties within the company – and an external one – how well does the team know the buyers and users for the product and how the market defines the key problem to be solved?  As a product owner I work hard to keep the team focused on the vision behind what we are trying to create, particularly by rooting our development efforts in user stories rather than feature lists and by sharing key client success stories.  But I worry if we have identified the key performance indicators that will demonstrate the success of our creative efforts for the stakeholders evaluating what we do.  And I regularly wish we had more access to users and customers to get the market validation we need.

The next two sets of questions presented the strongest challenge for me; here the authors drill into the two sides of a sprint cycle – discovery and delivery – with twenty-five pointed questions on areas that range from using MVP (minimum viable product) techniques and an A/B testing infrastructure to predicting delivery with confidence and covering all new features with some level of analytics.  Our team does well in some of these areas and struggles with others.  The entire dual-track sprint concept (which Cagan elaborates upon here: http://www.svpg.com/dual-track-scrum/) is one that our team resonates with but that we are still trying to figure out how to embody.  Currently we are better at a lot of the ‘delivery’ pieces (a reliable release process, regression testing, and sprint retrospectives) than we are at some of the ‘discovery’ elements (vetting new ideas each sprint, building high-fidelity prototypes, and regularly reviewing the backlog to weed out ideas that don’t pass the vetting process).  But I found these questions all challenged me to think more deeply about both my own role as a product owner and the way our team needs to keep growing.

The whole concept of ‘prototyping’ is one I particularly wrestle with.  Given the highly complex nature of the problems we are trying to solve through software development in my current firm, building even a ‘low fidelity’ prototype can be challenging.  And given the often urgent requests our development team receives to get out solutions for our clients, I sometimes worry that what was intended as a prototype will start being used as a stop-gap solution – leading to frustration for our clients, our sales team, and our developers.  Maybe I’ll try to write up my larger thoughts on prototypes in a separate post where I can more fully share my views on both the positive and negative aspects of using them in my current context.  For now I’ll just say that I always find the idea of using prototypes in development both intriguing and challenging, and so I’m glad that Cagan and Patton raise this issue in their article.

There are many insightful people writing good articles and blogs about Agile product development; I enjoy reading these pieces and hope from time to time to share both the posts themselves and some of my own thoughts about them.  I am eager to grow as a product owner and to connect with the wider Agile community, and I am happy to pass along what I find to those of you who read my blog.  If you read something you think I should read too please post a link in the comments here or tweet me @asbiv so I can see it.  As I hope the above post shows you, I am always ready to be challenged with good insights and deep questions that can help me evaluate how I’m doing and move toward greater skill in my role.  The core principles of Agile and the straight-forward questions raised in Cagan and Patton’s article look easy on the surface; but as you dig in you find that in truth it’s not that simple.