As I launch into this new series I’m calling Agility, I had planned to begin with one or two ‘big picture’ postings about the Agile Manifesto and core principles.  I still plan to write these posts soon, but if you follow me on Twitter (@asbiv) you might have noticed that an issue came up at work this week that I wanted to write more about while it was fresh.

The 140 character summary was this: Interesting conversations today about when to market new features – not too conservative but never over-promise. Looking for balance.  The key issues raised are about when new and developing features are ready for new customers to use – and even what ‘ready’ means.

I need to put in a caveat here that I’ll probably repeat in one form or another fairly often during this posting series.  This blog is about my perspective on a complex issue that can be seen in multiple ways by equally well-intentioned and well-informed people (that’s why this whole blog is called In Truth It’s Not That Simple).  Not everyone in my current company thinks about Agile the same way that I do; not everyone values the same parts of this approach or critiques the same aspects of it that I do; not even everyone on my team looks at the issues the same way I do.  I’m sharing my own thoughts and perspectives from the middle of working on things, so please take what you like and leave the rest.

So back to the issue at hand.  We are in the middle of developing a feature that different clients and prospects have asked about over the past few years.  Our sales team, advisory team, and product managers have done enough investigation to know that this feature will address a real, pervasive, and pressing market need which clients will pay for us to help them solve.  And we have talked internally about what it will take for us to support this new feature once folks are actively using it.  The question is, when do we decide to market this feature and when do we decide it is ready for folks to use?

The first part of that question is (I think) fairly easy to answer: we market this now.  We already know ‘the market’ wants this feature and given both our development cycle (two-week sprints focused on prioritized functionality) and the implementation cycle for anyone ‘signing up’ for this feature there is very low risk of over-promising and under-delivering.  So we are training our sales folks on the key components and benefits and making sure our sales support folks know how to demo this where appropriate.

The harder part of the question concerns when we can say this feature is ready for existing clients – some of whom have been asking for it for months.  A more traditional waterfall approach would say that the feature is ready when it has progressed through the software development life cycle – when it has been thoroughly documented and tested internally so that it can be unveiled as a finished product.  Some Agile practitioners on the other hand might argue that the product is ‘born ready’ – that is, as soon there is a functional piece of software (which should be the goal of a single sprint) this should be put in the hands of end users (or at least a select group of them) who are ideal for truly validating that the functionality meets the market need in a usable way.  Through an iterative process the initial piece of functionality will be fixed and improved up to the point where it fulfills the product manager’s goals and a new issue becomes a higher priority.  From this perspective a high fidelity prototype is just as ‘ready’ as a fully finished product (if such a thing exists) because use and validation by real customers is the only way to know when development of a feature is complete.

The question is sharpened for me by talking with the folks who support some of our products and services that will be impacted by this new feature.  As a company we are still sorting out the best way to build and use high fidelity prototypes and so in this case we did not develop one.  That means that once we release this feature for clients it will drop into the inter-connected web of our many services.  And that means that the overlapping teams of product sales, product development, and product support all have to get on the same page about when and how to begin getting clients using this feature.  The sales folks are understandably eager for another feature to tout and another legitimate reason to connect with current and potential clients, while the support team raises valid concerns about the impact of rolling out a new feature too aggressively when we don’t yet know all the ways it will impact our existing services.

This situation is not at all uncommon when new features and products are being developed.  It puts me as product owner on the bridge connecting these reasonable differences, trying to facilitate a conversation about the best way forward.  In this particular case I think we are making a wise decision about our rollout strategy.  I’m also glad we are growing in our understanding of prototyping, and in our cross-team conversations around these issues.  All of us share the goal of delivering outstanding products and services that thrill our clients and grow our market impact.  We don’t all think the same way about how an Agile approach should inform the ways we solve these kinds of questions, but as a company and as individuals we do value our respectful interactions with each other over any other decision-making process – and that as you may know is the first tenet of the Agile Manifesto (here’s a link to the manifesto if you’d like to check it out: http://agilemanifesto.org/).

So maybe it turns out that talking about one specific decision connects pretty directly to also talking about the big picture of Agile.  While we try different approaches to developing and delivering software, I think we’ll keep learning what parts of Agile we resonate with and which pieces we want to adapt to fit our own company culture.  I feel fairly confident that we will appreciate the central principles at the heat of the Agile methodology.  Sharing those core values will continue to be crucial as we wrestle with complex decisions, because in truth it’s not that simple.