Setting Expectations about Formal Releases with the Business Team

Product Management sets features and priorities – Engineering sets schedule … and meets schedule

Advertisements

While the business team may desire, or be obligated, to fix both the date of a release and the features that will comprise it, it is our job as Engineers to educate them on how unrealistic this approach is [under the assumption that staffing cannot be increased and quality is not negotiable]. It is also our job to offer alternatives.

By working collaboratively, we can redefine the desired outcome in a way that still meets the business needs and allows for a speedier implementation, without compromising quality.

The fundamental rule of engagement is that …

Product Management Sets Features And Priorities — Engineering Estimates The Schedule … And Meets The Schedule.

Engineering is a key contributor to the product roadmap, sometimes even the primary contributor. However, the Product Management (PM) team has, by definition, the ownership of the business derived from the product, and as such they call the shots when it comes to the definition of features, and priorities.

On the other hand, PM has no business pronouncing how long it will take to implement the desired feature sets – this is Engineering’s purview. This is no different than when we are dealing with a contractor to remodel our kitchen: we can tell them what we want the kitchen to look like, but he/she is not going to do business with us if we tell him how much he/she can charge us, and/or how quickly the job will be completed.

Why? It simply boils down to ownership and accountability

Engineers, by and large, are a good sport and will do whatever they can to meet even the most unrealistic schedule. Ultimately, however, hard work cannot compensate for a schedule that is plainly not feasible.

Since it is Engineering’s job to develop the product, having anyone other than Engineering make estimates, or worse, commitments about schedule, removes the ownership and accountability of meeting the schedule from the Engineering team.

Schedules Only Have Value If There Is A Reasonable Expectation That They Will Be Met.

We set a schedule for the release of a product for a reason: so that other teams inside (e.g. marketing, sales) and outside the company (e.g. customers, partners) can make their own plans based on the availability of the product at a given date.  If we don’t meet the schedule, these other teams will have to redo their plans and will resent us for it. Worse, if we establish a habit of missing schedules, they will stop making plans and just wait-and-see until the product is actually delivered. This can create a vicious circle where the Engineering team sees that the Sales team does not plan on the product being ready on time, and thus does not feel the pressure to deliver on time – which reinforces the Sales team’s attitude, ….

The best way – by far – to build reliable schedules is to let the engineers who are responsible for the delivery of the product estimate their own schedule. For two reasons, one because the estimate will be more reliable and two because the engineers then have ownership of the schedule.

I have worked with a few CEOs who did not trust Engineering with estimates, and who were convinced that giving impossible tasks to the Engineering team ensured that they could get every last drop of blood/work out of the team. This is plain wrong.

Once in a while you can indeed rally the troops to meet an impossible target and “save the company”. However, over time, it quickly becomes counter-productive. People will not accept arbitrary challenges and will simply dis-engage.

On the other hand, when empowered to estimate their own schedule, Engineers will then feel accountable for meeting it, and it will become a matter of personal, and team, pride to deliver on-time. Furthermore, this fosters a culture of success – and a virtuous circle of people being able to rely on teammates’ commitments.

Schedule And Feature Set Result From A Collaborative Effort

Pushing the kitchen remodeling analogy further: Usually, the first bid is too expensive. What follows is a discussion about how flexible the dates are, what are the critical elements driving the dates and price, and a series of “what if …” discussions. The same needs to happen between Engineering and Product Management: what flexibility do we have in the dates? For example, will the customer to whom we promised certain features actually go into production at the said date, or will they accept a beta release because they need to do their own tests in a Staging environment? Are all the options and variations of a particular capability required by the release date, or can some of them be pushed out to the next release?

One of the most satisfying moments of the job is when product managers and engineers brainstorm on how to meet the business needs of our customers in innovative ways. By bringing these two teams together and sharing the knowledge of customer needs, or why a certain feature requires a lot of work, or why by softening a specific aspect, implementation becomes much easier, we truly create value for the company. At the end of this brainstorm, we have truly optimized the features we offer AND the effort required to deliver them. The continuous repetition of this exercise allows us to deliver more, faster.

 

The final ingredient is to provide transparency to the Engineering process – which is frequently considered as a black box. It is because of this lack of visibility that people on the outside tend to buy themselves insurance and ask for a schedule that’s more aggressive than need be. In the next blog, we will show how Agile Software Engineering provides, among other things, not only visibility on the progress of the Engineering team, but also the ability to adjust the course.

Violating the Laws of Physics: When the Business Imposes both Release Date and Features

Managing an Engineering team, when the company imposes both features to be delivered and the release date

In all the companies where I have worked, the business side has been “supportive” of Agile software development methodologies – in its own way J. They like the story, agree it makes total sense … except for the part where we talk about adjusting priorities and not committing ahead of time to delivering specific features by a certain date – even whilst recognizing that historically, priorities have significantly changed in the midst of a release.

 

Given that, for all practical purposes, headcount is fixed (budgets are rarely elastic), and quality is non-negotiable, this combination of fixing features of the release and the release date violates the laws of physics!  Only Engineering can estimate how long it will take to develop a certain of features (given fixed resources and without impacting quality). The Business team (product managers, VP Marketing, CEO, etc) cannot estimate the amount of effort a given release will take. Just like we don’t tell our contractor how long (or how much) it will take to remodel your kitchen, the business team must let Engineering scope the effort, and time, required for a release.

 

In this multi-part blog, I will present my recommendations on how to best manage a team in this environment. I hasten to say that I have not found the perfect solution and I am still working hard at f refining it daily.

 

Three important aspects drive the management techniques:

  1. Understanding, and communicating to the Engineering team, the “Why”: why the business needs to impose both dates and features … and why this is unlikely to change materially
  2. Communicating to the business teams what they can expect from the Engineering team, and establishing “rules of engagement”
  3. Understanding, and implementing, the Agile principles that are most helpful in this environment.

The (Legitimate) Reasons for Formal Release Processes

To be clear, a continuous release process, where new features are deployed as soon as they are developed and tested is ideal. Unfortunately, this is only possible in specific environments, e.g. self-hosted web-apps, and does not work for ISVs.

 

Most ISVs which sell to enterprises need to publish their 18-24 month product roadmap. Customers don’t just buy today’s product, but also tomorrow’s. This 2-year product roadmap is most critical  for startup whose buyers accept the risk of buying from a fledgling company because of the promise the continuous stream of benefits committed in the product roadmap. “Committed” is the operative word: because of its startup status the company must meet every single one of its promises in order to maintain the fragile trust of its customers.

 

Here are some common (legitimate) reasons that prevent “continuous” release, and require formal release:

  • The software is installed on customers’ premises. In this case, it is important to “version” the code. It would be impossible to manage communications, installation, or support, if each customer installed a different version
  • The overhead of introducing new features makes it too costly to release one feature at a time. Any function can cause this overhead to be too dear – even in the case of a hosted (SaaS) web-app:
    • QA – if a bug cannot be afforded (e.g. financial applications, regulatory conditions),
    • End-user communications & training: when the usage paradigm is changed significantly, deliberate communications and user training will be necessary. Similarly, some environments have seasonality that limit the opportunities to introduce something new (e.g. schools, retail)
    • Integration with 3rd party partners, and/or customer systems: will require a phase of joint testing upon any change in our software
    • Customer release processes: even in a SaaS environment, customers (e.g. in  mission critical applications such as e-mail, and/or sensitive applications like finance) will impose their own pace of deployment, and limit the number of upgrades to 1 or 2 a year
    • Marketing: the business may be such that opportunities to communicate to customers, partners and analysts are rare and costly, and consequently, it is necessary to group features in a release to maximize the excitement about product announcement.
    • Customer commitments: As the CEO, VP of Sales, and sales team scour the country, or the globe, in search of orders, they make commitments to customers in order to win deals, as to features being available by a certain date.

 

In all the situations listed above, one could argue that there is no reason why Engineering should not be involved in setting dates before commitments are made. And the point is correct. It is in everyone’s interest to involve Engineering before making commitments. This is called the Product Roadmap process … which we will discuss in a subsequent blog