In 3 steps from introduction to first product release

As with all collaborations, the process starts with getting acquainted. At first sight, this may seem obvious and trivial, but it certainly is not. At rb2 we apply Agile working, and although this is the standard in software development, it requires a good click between us and our customers. Getting to know each other is essential for building the mutual trust needed to realize an appropriate technological solution with sufficient speed.

Step 1: Getting to know each other and setting the context

As we get acquainted, we also explore the context of the solution to be built, i.e. the (intended) business model and positioning. These are starting points for jointly defining the 'product vision'. This describes the purpose of the product, the intention behind the product, and what the product enables its users to do. This context is necessary to enable a good estimation of the work needed to realize the right technical solution. We assist clients in the clearly thought-out identification of specific characteristics and peculiarities. It is not the intention to record everything in detail in this context. 'Adequately' is the keyword here.

Step 2: Establishing functionalities of Minimal Viable Product (MVP)

As soon as the overall vision and objectives for the product are sufficiently clear, a set of functionalities is drawn up and selected in mutual consultation, which absolutely must be included in the first release of the product. We work to ensure that customers can get a product up and running quickly so that we receive feedback from users as early as possible. In this way, a product delivers value as quickly as possible and, if necessary, the feedback can also be used quickly to improve the product. When a first release can go live of course depends to some extent on the feature set that the existing solution already offered or that the market sees as 'standard' in the case of an upgrade project, for example. If a new e-commerce platform needs to be realized, rb2 makes available the 'standard' feature set based on its experience, paying particular attention to those features that will make the proposition stand out. If the order is for a totally new proposition for which no reference exists yet, then the total feature set for the first release plays a central role.

Step 3: Starting the technical realization with a Proof of Collaboration

After getting acquainted, the joint exploration, and reaching agreement on the first release, the realization phase begins. This should lead to cooperation between the client's executive team members and the team members at our office in Purmerend. We use a Proof of Collaboration to promote the growth of this collaboration. During the first sprints, extra attention is paid to the division of roles and finding the optimal cooperation within the SCRUM process.  How many sprints are needed depends on the specific situation, but four sprints is a good starting point. The role of the Product Owner (PO) gets a lot of attention, in view of his or her responsibility for the Product Backlog. In this Product Backlog, the development team can see exactly what aspect they need to tackle next.

Continuous coaching

Once the Proof of Collaboration has been successfully completed, the realization will proceed at full speed. The link between rb2 and the customer continues to remain strong after this also. We continue to coach, with the goal of ensuring optimal delivery of the software solution. We help customers work in a (more) agile way, ensuring that our team can and will deliver the right thing. After all, not every customer is equally experienced with Agile working. We match the expertise in process and technology offered with the client's experience and agility. We prefer to work with a Product Owner from the client organization, but sometimes there is no one available for this role at the start. In that case, rb2 prefers to work with an external PO. As soon as a PO has mastered scrumming, coaching on the process becomes less necessary. We then often still support the PO with 'refining' the Product Backlog, to make things move along more quickly. We emphatically take on the journey from the first introduction to the first product release - and beyond - together. To achieve the best possible results.