product management – The Making of Software

Speed up On-Premises Product Delivery

Fast delivery of value to customers is today’s business mantra – especially in the software industry. In this blog I reflect on delivery challenges of companies which offer the same product as SaaS AND on-premises solution. I will also present a case study that shows how a company has dramatically improved its on-premises delivery speed.

Within the past 15 years we have seen several approaches how to foster fast delivery of software products. Two prominent ones are:

Agile development
Cloud based solutions

The agile approach to software development produces software products incrementally and frequently. This is achieved by close interaction with customers and a set of development principles that are based on the agile manifesto. It is not uncommon that software companies create new versions of their software products on a monthly or even shorter frequency.

How are these product increments delivered to the customer?

Currently there are two major mechanisms in use:

The fastest way for on-premises provisioned products, is to check during launch if there is a newer version of the product available. If so, the newer version will be automatically downloaded and installed. This practice is often used within the software games industry. E.g. games that are provisioned by the steam gaming platform. Traditional ways to deliver a new on-premises version are customer notifications combined with manual on-demand-downloads.

SaaS provisioned products are often under control of the company in charge for the development of the product. Whenever the development organization has produced and tested a new product increment, it will be moved to the SaaS server. Customers that launch the product through their web browser are automatically connected to the latest version of the product. Cloud-based solutions enable software vendors to deliver new software features quite often to their customers. The only thing left to do is to update the software on the runtime environment that is often under their own control. In such environments it is not uncommon that bug fixes and new features are delivered on a weekly or even on a daily basis.

The dual-delivery challenge

Companies which started business after the millennium focus often on cloud based solutions and do not provide on-premises products. In contrast, companies that have been around for more than 15 years are used to on-premises delivery and have established their business around that channel. However, more and more of those companies start to deliver their products as SaaS-based products in addition. Prominent examples are Microsoft with their office suite and HPE with their ALM solution.

Serving two channels with the same product creates new challenges. Customers that utilize on-premises products often have to wait for more than a year to get new features. Features which they can already see within the SaaS version of the same product. This situation creates quite some tension. Therefore, product companies try shortening the delivery cycles for on-premises solutions as well.

The company Jama Software was faced with this challenge and recently came up with a new release model for their on-premises release stream of the requirements product named Jama.

Case study Jama

Jama Software prefers the SaaS delivery channel. However, they accept that some of their customers do not want data managed outside their company’s intranet. Especially, if the data contains sensitive information about upcoming product releases which is usually the case when managing requirements.

As a consequence, Jama Software delivers its product as a hosted solution via SaaS AND as an on-premises solution. Typically, they release two on-premises versions within a year. However, customers using the SaaS version get access to new product features much earlier.

In summer 2016 Jama Software announced a significantly changed new release mechanism: On-premises Express. With the on-premises express channel they aim to deliver new versions on a monthly base. Compared to the half year release schedule so far this represents a stunning acceleration in delivery.

What are the secrets to Jama Software’s cycle time reduction?

First of all: A thorough analysis of the current situation. Finding out the areas of work that need a lot of time for each release. The current server part of the product Jama is delivered on two operating systems: Windows and Linux. All used 3^rd party components need to be available on both platforms at the same time. So far Jama Software supports two database systems: MySQL and Oracle. Features and bug-fixes need to be tested on both platforms and DBs. Testing bug fixes and new product features on the various configurations consumes quite some time.

Jama product management made the tough decision to drop support for Microsoft Windows server and Oracle DB. This enabled the QA organization to substantially reduce time for testing. Now Jama Software delivers the same software configuration to their customers that they use on their hosted platform as well.

Second, they analyzed their current architecture in regards to ease of modification. They found out, that they could improve their product significantly by a new way of modularization.

Third, they decided to utilize top-notch technology for isolating the product into distinct independent components, thereby easing software distribution. Jama Software decided to utilize Docker containers. They now encapsulate product dependencies like Java and Tomcat into containers, so that customers don’t need to care about specific Java or Tomcat versions.

Fourth, accelerating deployment. Jama software now uses Replicated. This technology takes advantage of Docker and deploys containers not only to the SaaS server of the vendor but also behind a customer’s firewall. Using Replicated Jama Software now builds the product just once and deploys the result simultaneously to their own hosted instance and to registered customers.

Encapsulating product services into Docker container and managing deployment with Replicated enables Jama Software to manage deployment of the service-oriented architecture much faster, more flexible and more reliable than before.

Summary

Achieving cycle time reduction in development is just one element to deliver software to customers more frequently. It needs to be matched by fast deployment methods, so that the whole DevOps chain can be covered. On top of that the product managers of Jama Software needed to make some tough decisions what not to support in the future. These decisions took complexity out of the product and significantly reduced testing time. Product managers are responsible for the overall product success. They have a holistic view of the business and need to look at all aspects along the delivery chain of a product in order to come up with solutions that enable sustainable business success. Jama Software has rebuild major elements along that line.

We may expect similar moves by other vendors this year as they all face similar pressures.
Stay tuned.

Further information:

Jama delivery channels

Replicated Technology: SaaS vs. on prem solved

Docker

Software Product Management: Key to software product success

How Product Managers Learn

Reflections from PMF 2015

On November 18 and 19 I participated at the Product Management Festival 2015 in Zürich Switzerland. This was a great event for product managers to get together. Besides networking opportunities it provided numerous insights into product management practices. Most of the talks were experience reports. Young product managers as well as high profile product directors shared their insights. Some of those insights were morphed nicely into pictures, like the one from Nilan Peiris (VP of growth from TransferWise). He illustrated the relationship between Product Management and Product Marketing with a nice picture in the tweet: The great mexican standoff of product management

Learn from failures of other practitioners

What the audience really appreciated is the fact that speakers shared their failures as well. Where else do you get such insights? Learning from failure is a theme that has become prominent with the agile movement: you are allowed to fail, but you shouldn’t fail twice with the same topic.

Learn from good practices of other practitioners

Sharing good practices is another good source of learning and we could listen to numerous recommendations from the speakers, like the ones from Martin Rusch – vice president Xing. He provided insights into the Xing way of launching new initiatives using “Auftragsklärung” as a key success element. The German word “Auftragsklärung” is explaining the situation so excellent, that Martin and his colleagues at Xing didn’t find an equivalent English word for it; “project clarification” would be a rough translation.

“Auftragsklärung” may work for Xing, however, each practice should be evaluated carefully, whether it fits to other environments as well. Already 30 years ago Fred Brooks coined the famous term “there is no silver bullet”.

Learn the foundations

Several attendees came to the festival to learn how to establish product management as a discipline in their company. For them a product management framework like the one from the International Software Product Management Association (ISPMA) is a good starting point. Based on that Software Product Management Body of Knowledge training providers have established curricula that teach software product management as a discipline. See our training offerings on swpm.de/spm as one example.

Learn from references

There is also a growing body of knowledge available in text format. Books, blogs, online presentations and research articles about the field of software product management. Watch out for upcoming information about this topic in this blog.

Learn from your own practice

The most important learning source for product managers however is provided from own practice. Nothing is more worthwhile than making your own experience.

That of course, wasn’t possible at the product management festival, but will be done every day at work. May be we can hear about your experiences at next year’s festival?

Aha

Recently we updated our annotated collection of requirements management tools. In this update we introduced a couple of new tools, which we got notice from. One of them is the product Aha!.

Aha! is a cloud based solution targeted at product managers. It has been created in 2013 and focuses on product planning aspects. The company Aha! positions the product as roadmapping software. Product managers can specify high level goals and visions for products. Continue reading “Aha”

Tools for Product Management

On September 17, I will be speaker at this years product management festival in Zurich.

I will provide an overview about tools that support product managers to do their jobs. More and more tool provider recognize, that product manager and product owner have specific needs and start to address these. Even completely new products show up. I will provide an overview and visualize recent trends in tooling. It will be fun to discuss these with the intended target audience.

Gerald Heller

Agile Requirements Frameworks

by Andreas Birk and Gerald Heller

When agile methods emerged during the 1990s and until quite long into the first decade of the 21st century, agile requirements were widely synonymous with user stories. This was a major contribution and step forward for requirements practices on team level. However, for larger multi-team development efforts, for continuous product development as well as for product- and portfolio-level planning, effective guidance for agile requirements management was still mostly missing. This situation has improved gradually since around 2005 when frameworks for scaling agile appeared on the scene. Most notable examples are: Scaling Software Agility by Dean Leffingwell (2007) and Scaling Lean & Agile Development by Craig Larman and Bas Vodde (2008). Follow-up publications of these authors have provided valuable additional guidance also for requirements management. In particular, Dean Leffingwell published the first comprehensive agile requirements framework in 2010: Agile Software Requirements, the approach is now known as the Scaled Agile Framework (SAFe).

Today, we have quite a variety of agile requirements frameworks. But now it has become difficult to survey the entire scene and find the suitable approaches relevant for one’s own specific software or system development context. For this reason, we want to give an overview here, providing orientation and guidance in the growing field of agile requirements management. You find a survey of those frameworks we find most important along with links for further information. Of course, this selection is subjective, and for sure we have overlooked some important approaches. So we will be grateful, if you can comment on the following list and send us additional hints (feedback link). We will include them into future updates of this list.

Scaled Agile Framework SAFe (Leffingwell)

SAFe has been the first comprehensive framework for agile requirements management, defined by Dean Leffingwell. Published in its initial version in 2010 and partly based on earlier works, we view it still as the most important reference and entry point for agile requirements management. The website provides a very rich collection of valuable information. The book is an excellent introduction and resource on agile requirements. Dean Leffingwell’s earlier book makes a good extension for understanding the large-scale agile development process.

Scaling Lean & Agile Development LeSS (Larman, Vodde)

LeSS does not focus on requirements management in particular, rather it addresses the entire spectrum of agile development activities. However, it includes very many practices and techniques relevant to agile requirements management. A good introduction to LeSS is the May 2013 article in CrossTalk magazine. Additional information provide the homepages and blogs of Craig Larman and Bas Vodde. An interesting experience report is the article on Large Scale Scrum (LeSS) @ J.P. Morgan at InfoQ. The comprehensive resources are the two books on basic concepts (2008) and on practices (2010) of the approach.

Disciplined Agile Delivery DAD (Ambler)

DAD is a “process decision framework” that aims at helping projects and organizations to create their suitable agile development approaches. As such it includes various agile requirements practices along with guidance to design requirements and software delivery processes. The approach is relatively new, dating from 2012. There is an accompanying book available.

Discover to Deliver (Gottesdiener)

Discover to Deliver is an approach to agile product planning and (requirements/business/system) analysis. It extends established product planning and analysis techniques and transforms them into the agile world. A book introduces the approach, and a short 2-minutes video clip explains the essential concepts.

Specification by Example SBE (Adzic, Fowler, and others)

“Specification by example (SBE) is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements.” (Wikipedia) It provides a consistent framework to agile requirements management utilizing high-level tests and test automation. Among the main proponents are Gojko Adzic and Martin Fowler. Gojko Adzic maintains the specificationbyexample.com website and has written a good instructive book on the topic. Martin Fowler has written a concise article that motivates and introduces the approach.

Acceptance Test Driven Development ATDD (Gärtner, Koskela, and others)

ATDD is another consistent approach for accomplishing agile requirements and testing tasks in an integrated fashion. It features several agile requirements practices that can be very useful in the context of other approaches as well (e.g., the Given-When-Then template for specifying system behaviour and tests). A Wikipedia article provides a good introduction. Introductory books are available from Markus Gärtner. Lasse Koskela has written a brief introduction as well as a very instructive book on ATDD.

User Stories Applied (Cohn)

User stories are the nucleous or starting point of all agile requirements management. Mike Cohn’s classical book on the topic provides an excellent introduction and explains the application of use cases in agile development projects.

Use Case 2.0 (Jacobson)

Ivar Jacobson has coined the concept of use cases as early as in the 1980s. With Use Case 2.0 he and his colleagues have refurbished the use cases approach for the agile age. The approach differs partly from other agile requirements frameworks (e.g., stronger emphasize on more or less formal information structure and (only) apparently less emphasis on stakeholder communication procedures). However, this makes it particularly relevant as a source of additional inspiration for agile requirements managers. It also can provide important guidance for environments in which other agile approaches don’t appear suitable (e.g., possibly in development of technical products using model-based approaches). An eBook explains the approach.

Agile Product Canvas (Pichler)

Roman Pichler is the author of the book Agile Product Management with Scrum (2010). Since then he has developed several additional and very useful tools. One of them is the Agile Product Canvas, which collects all important overall product-related requirements information on one easy-to-understand and easy-to-use pane.

Agile Modeling & Agile Documentation (Ambler, Rüping and others)

Quite early during the emergence of agile methods, Scott Ambler and Andreas Rüping had taken attention to aspects beyond coding. First, Scott Ambler wrote a book on agile modeling (2002). He also now maintains a comprehensive website on the topic, which contains a good overview article. Soon later, Andreas Rüping has added another book on agile documentation (2003). In 2012, Andreas Rüping published an updated and extended version of the book (available in German only). These works complement the other frameworks on agile requirements management by providing guidance also for the interfaces of requirements management to adjacent disciplines like graphical modeling (e.g., business process models, UML, SysML), architecture specifications, and user documentation.

At the end of this article, let us emphasize again: We will be very glad, if you share your thoughts on agile requirements management with us. Do you disagree with (parts of) what we have written here? Would you have additional framework suggestions? Do you have agile requirements experiences that you want to share with others? Don’t hesitate to contact us via info@swpm.de.