Agile development isn't enough

I was talking to a board member of a mid-size company a few weeks back about his biggest challenges. After over a year of struggle implementing Agile and changing a couple of products to be delivered as services (SaaS), one of his biggest pains was keeping marketing, sales and support up to speed as the release rhythm accelerated. After asking him a couple of questions regarding how product management engaged with these "functions" (luckily, he has an effective, empowered product management team), it became apparent to me that while PM and development had made great progress with respect to adopting Scrum, the other functions had been left behind!

On the surface, it seems obvious that if development is delivering releases at a higher frequency, sale's needs are going to change with respect to enablement and demos, for example; marketing's needs are going to change in a similar fashion. The same can be said about support, who moves from a model of "handover" a couple of times a year to continuously absorbing new changes, including new problems. Put simply, if you want to realize the benefits of Agile/Scrum or Lean or SaaS, the entire "train" will have to get on the track. That means frequent, managed engagement with all internal stakeholders, including IT. On that note, DevOps is the area that I see the most conspicuous acknowledgement of the need for the entire extended product team to adapt to new development approaches and techniques.

The days of waterfall development taught us that pulling in sales and marketing toward the end of the release is a mistake. These problems are exacerbated when release rhythm picks up. The answer? Creating continuous, efficient engagement with all stakeholders; it is probably the most important step you can take to ensure alignment, effective collaboration and maximum "throughput" end-to-end. The importance of making sure the leadership of these organizations understands what the change in development approach and product delivery means to them cannot be overstated.

What's your experience? Have you seen organizations that have gotten development on the Agile track but have left other parts of the organization behind?

Previous post: Balancing Release Investments with Simple Analytics

You can find more information about me (including upcoming training dates) at www.prickril.com.

Balancing Release Investments with Simple Analytics

This post by Rich Mironov resonated with me even more than usual (if you don't regularly read his stuff, you should!). Rich describes a practice involving placing completed user stories in the following buckets to get insight on how you're really spending your development dollars (and thus getting insight into your strategy, even if it's implicit):

·        Planned features

·        Unplanned features

·        Quality and development infrastructure

·        Longer-term research

Rich's post reminded me of a similar practice I've had of categorizing proposed investments in a release. He's right on with the a pie chart or similar graphic being much more useful in communicating the insights gained.

Before I describe my practice, I have to be forthright about how I've typically done release planning during most of career. Because I've worked at big/huge primarily B2B shops with (probably) overdeveloped portfolio processes, we were always forced to consider the likely scope of a given release long before we started development. While such a practice is clearly not in vogue in a software development world dominated by Agile/Lean thinking, because of intra-portfolio dependencies, expectations of big customers (some of the biggest companies in the world) and staunch competition for development resources, we simply couldn't tell our stakeholders "We can't tell you yet what we'll deliver". In my experience in these big shops, Agile/Scrum was used as a mechanism to allow deviation from these plans as necessary, but didn't preclude our defining our intentions relative to a release before we began building it.

BTW, Rich's approach suggests calculating story points for completed stories/features/epics to determine proportional investment. In terms of release planning, our metric was always development capacity expressed as person-days, one of the key goals of release planning being to convince ourselves that we had a reasonable fit between planned investments and available development capacity (and setting the stage for requesting additional resources as needed).

Here are a few interesting pivots that I would assume could  drive insight into investments we've already made (or "implicit strategy" to use Rich's terminology) as well as planned investments. Once again, I realize people who have drunk deeply from the Agile Kook-aid pitcher will balk at the idea of this level of detailed planning before development begins, but, what can I say? It's an imperfect world and we were doing the best we could in sometimes very un-Agile organizations.

Kano model

The Kano model was the original inspiration for generating simple analytics based on investment categorization. We had launched a new product that had barely made it out the door. Suffice it to say none of us were thrilled with the final scope nor the level of quality. At "power vendors", the truth is that it is assumed that you'll get it "right" on the third release, but that's fodder for another post. Anyway, as we planned the next release, we quickly realized that just fixing perceived gaps and addressing very real quality issues would consume all development capacity. When we considered the press release for V2, we realized we had virtually nothing in the release to generate excitement.

This quick exercise can help you determine if your release has enough sizzle to get customers' and analysts' attention when you launch.

Customers we have vs. customers we want

Another way to categorize investments involves considering if the investment is likely to please the customer segments you have or represents an investment to acquire customers in new segments. Although the line isn't always clear, try categorizing your investments based on who you think they'll most resonate with:

·        Existing Segments

·        New Segments

·        Both

·        Indifferent (overcoming technical debt etc.)

Products at the beginning and end of their life cycles often must attract new customer segments, often with features that may not be particularly valuable to their installed base. If you're not investing in attracting new customer segments, ask yourself why not. This categorization also gives you insight into to proportion of your investment that is going toward things that please no customer whatsoever. I've been involved in releases when this "bucket" consumed 80% or more of our development calories.

Stakeholders

Categorizing your investments by stakeholder can also be an interesting exercise. While it's natural to focus on customers, the truth is that we product managers must often please multiple masters. Here are some typical stakeholder categories:

·        Customers (consider decomposing this one based on segments as well)

·        Partners

·        Management (investment in quality initiatives, portfolio interoperability etc.)

·        Product standards compliance(accessibility, supportability etc.)

·        Sales (to close some critical deals, for example)

This exercise should also make it fairly easy to see how much of your investment is intended to please internal vs. external stakeholders (in big shops, you internal stakeholders my consume a significant number of calories).

Conclusion

So there you have it, a few ways to categorize investments you intend to make to get insight into priorities and possibly make adjustments before development starts. Do you do similar categorization?

You can find more information about me (including upcoming training dates) at www.prickril.com.