Delivery

After we have ensured that we build the right things, it’s time to build the things right.

Delivery
Delivery

Key Objectives / Key Questions

Create a detailed plan on what to build and when; then develop accordingly.

Key Activities

  • Thoroughly examine and break down every feature into small tasks, especially all technical tasks involved, leaving no detail unnoticed.
  • Identify and manage dependencies, specifically for larger teams working on a bigger product
  • Run Agile Sprints with empowered teams, providing timely feedback, ideally before the end of the current Sprint.
  • Implement continuous delivery to avoid tech debt piling up during longer implementation projects
  • Consider development holistically, including quality assurance, performance, documentation
  • Maintain and foster ongoing communication with all the parties involved in the delivery phase, especially Engineering Team, UX Design, as well as customers.
  • Implement Continuous Discovery to foster learning and improve customer understanding

Exit Criteria

  • The feature(s) are available in a dedicated environment, ideally via continuous delivery.
  • The Product Management team agrees to the feature scope delivered with a solution.
  • The UX Design team agrees to user flow and visual design as built.
  • Non-functional requirements are met, most notably around quality and performance.

Involved Team Members

  • Engineering teams are in the lead and accountable.
  • Product Managers closely follow. They provide insights, answer questions, and help to prioritize – but they do not run the engineering team.
  • UX Design is actively involved in fine-tuning the user experience.

Tools and Techniques

  • Agile Frameworks, like Scrum or Kanban to iterate quickly
  • Alternatively, software development frameworks, such as Shape Up to optimize the value delivered to customers
  • Risk management tools, e.g. to ensure that the highest risks are tackled first. Note the concept of Work as a Hill in Shape Up
  • Concierge Tests or Wizard of Oz implementations as ways to test MVPs to provide value to customers as quickly as possible, even though with yet non-scalable solutions

Things to Watch out for

  • Avoid waterfall. Avoid Product & UX designing a solution during previous phases, and throwing it over the fence to the Engineering team. While the degree of involvement of team members varies across the various phases, it is still a team effort.
  • Be open to change. Even after a solution has been agreed upon, new insights may occur at any time suggesting scope changes.
  • Leave technology decisions to the Engineering team. There might be constraints, for example with respect to 3rd party technology. But neither stakeholders nor Product Managers can decide about the software stack.
  • Provide transparency about status. Recall the GPS metaphor regarding estimations – always know where you are, and be transparent about it.
  • Quality is non-negotiable.
  • Avoid sandboxes. It’s nice when “it works on my machine” for one Software Engineer. But that usually is not very predictive of real-life behavior in a productive environment. Instead, use dedicated integration environments and continuous delivery processes.
  • Test small iterations. In B2C, most people are aware of A/B testing. In B2B, we found such tools less useful because enterprise customers don’t want to act as guinea pigs. Instead, feature flags and similar methods can be used to provide early access to selected customers.

Example

A B2B software company was in the process of finalizing a new feature, which enables customers to digitally sign documents. A couple of Sprints in, the feature had already taken form, meaning though some UI elements missing and predictable edge cases weren’t fully covered, a standard end-to-end user journey could already be demonstrated in the software.

The Product Manager began to show the feature during Customer Advisory Board meetings and user interviews. Both valuable positive and constructive feedback was received and passed on to the Engineering team. Upon quick importance and satisfaction assessment, a couple of quick-fix tickets were created and tackled in the upcoming Sprints.

To continue the momentum, the Product Manager collaborated with a few Consulting and Presales colleagues, who had requested this feature in the past, to show the functionality to a manageable number of customers and prospects. The message was clear internally and externally: This is an exclusive sneak preview of a feature work-in-progress. Soon more feedback flew in and the Product Manager continued to work with the Engineering team to adapt the delivery.

In addition, a feature flag was added in order to control and easily manage who can see the feature on a customer-by-customer basis. At the end of the delivery phase, when the desired functionalities were finished, Sales and Consulting colleagues could further enable its visibility to a controlled group of customers using the feature flag.

By the time the feature was released, feedback from nearly 10 customers was already implemented.