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.