Custom Scrum Application Features

In this article I will talk about the features of Scrum in custom development, which differs from the “greenhouse” conditions of internal development. Is it possible to apply Scrum in market conditions and what should be paid attention first of all. Welcome to the cat and in the comments.

How to sell Scrum to a customer?

The first question that usually arises is “How to sell Scrum to the customer?”, Because he doesn’t really care what foreign word you call your internal processes. At this stage, it is very important to explain to the customer (we believe that we have two-week sprints) that he will be able to:

• every two weeks to get new functionality that you can try and release to the market to make money,
• change requirements every two weeks so that changes in business are reflected in software,
• adjust the timing and cost of work on projects due to the ability to stop the project after any sprint;

The second question that appears immediately after the first: "How to reflect the process in the contract?" The best option here is to conclude a contract such as “Time and Material” (Time and Material, T&M), in which the customer will pay you the cost of the team plus the agreed percentage. The advantage of this type of contract is the timing and cost management on the part of the customer, but it should be noted that with this approach, risks are transferred to it. I also note that with this approach, the project analysis phase is sharply reduced, since there is no need to give an accurate estimate of the terms and guarantee it.

Traditional for our country is the approach to conclude contracts with a fixed price (Fixed price), which, it would seem, transfers many risks to the contractor. In fact, the contractor is trying to put all these risks into the value of the contract. This approach can hardly be called flexible, since both sides are trying to defeat each other, instead of looking for a Win-Win solution based on mutual trust.

Zero sprint

About the zero sprint, many are silent, they say it is "Waterfall", or write just a little bit. Just a year or two ago, they finally started actively discussing this phase of the project, and, at the moment, the main part is the product part. We’ll start with her.

The most important document in the project, from which it is worth starting its development, is the vision of the project. This short document describes what a product is, who, when, how and where will be its audience, the main phases of the project, a business model for monetization, and so on. In a word, the whole package is replaced by a document that is customary to do in more heavyweight methodologies. To create a vision, you can use innovative games , all sorts of brainstorming and frameworks.

The next stage is the identification of persons and their activities (up to individual user stories), which are actually a lightweight and more visual version of ector and user cases. Traditionally, Scrum teams implement this activity in the form of Story mapping, the result of which are boards and entire walls with visualization of activities in the project:



Be sure to draw out the customer representatives to the processes for developing vision and Story mapping (and, to the last, potential users).
The reverse side of the coin is the choice of a platform for the design and creation of architecture. Of course, I do not mean Big Upfront Design , but a more flexible approach, because tens or hundreds of diagrams gathering dust in the farthest drawer of the table are not our goal. Our task is to make the product, minimizing losses.



In the simplest case, you can limit yourself to a domain chart with the simplest syntax that will be understandable to the customer. In more complex cases, this diagram should be supplemented with a class diagram and type a few more UML diagrams in the architecture basket to help describe the dynamic part of your system.
You can take ICONIX as a subset of UML and process (see. My presentation c AgileDays in Yekaterinburg ), but it will soon replace Story Mapping, than complement it.
The zero sprint also includes preparation for the first sprint. To do this, you need to describe the user story, design an interface for them and evaluate it. It is best to build the work in this order, since it contributes to a better understanding of the requirements and their assessment.

Scrum practices or putting the customer on an iterative needle

I won’t dwell on the traditional Scrum practices, I just want to note that it is necessary to involve the customer in them whenever possible. The minimum program is a visit by a customer of all demonstrations: it is vital for you to hook the customer to your own rhythm of work so that he wants to receive the next increment of functionality, like a drug :) This will greatly help build an atmosphere of trust between you.

The maximum program is to get the customer representative to other events. For example, a visit to poker planning will help the customer better understand the size of your tasks and understand that the team works at a high speed. The customer’s participation in retrospectives will allow deeper immersion in the problems and risks of the team, while he will be able to take an active part in improving the processes.

Next time we’ll talk about how to cross risk management and Agile.

Posted by Boris Wolfson - Head of Softline Development