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 use Scrum in the market conditions and what should be paid attention first of all. Welcome under 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 a customer?”, Because it 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 can:
- every two weeks to get a new functionality that you can try and put on the market to make money,
- every two weeks to change the requirements that changes in business are reflected in the software,
- regulate the timing and cost of work on projects due to the possibility 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 of the type “Time and Materials” (Time and Material, T & M), at which the customer will pay you the cost of the team plus the agreed percentage. The advantage of this type of contract is the management of the timing and cost of the customer, but it should be noted that with this approach, the risks are shifted to him. I also note that with this approach, the stage of project analysis is sharply reduced, since there is no need to give an accurate estimate of the timing and guarantee it.
')
For our country, the traditional approach is to conclude contracts with a fixed price (Fixed price), which, it would seem, transfers many risks to the contractor. In fact, the contractor tries to put all these risks into the contract value. 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 sprintMany people are silent about the zero sprint, they say it is a “waterfall”, or they write quite a bit. Literally a year or two ago, we finally began to actively discuss this phase of the project, and, at the moment, the food part is mainly being discussed. Let's start with it.
The most important document in the project, from which you should definitely start its development, is the vision of the project. This brief document describes what constitutes a product, who, when, how and where will be its audience, the main phases of the project, the business model for monetization, and so on. In a word, it replaces the whole package document, which is usually done in more heavyweight methodologies. To create a vision, you can use
innovative games , all sorts of brainstorming and frameworks.
The next step is the identification of persons and their activities (up to the individual user-story), which in fact are a lightweight and more visual version of ector and user cases. Traditionally, Scrum teams implement this activity in the form of
Story mapping , which results in boards and entire walls with visualization of activities in the project:

Be sure to pull the customer representatives on the processes to develop a vision and Story mapping (and the latter is still potential users).
The reverse side of the coin is the choice of a platform for developing and creating architecture. Of course, I mean not
Big Upfront Design , but a more flexible approach, after all, dozens or hundreds of diagrams gathering dust in a distant desk drawer is not our goal. Our task is to make a product, minimizing losses.

In the simplest case, you can restrict yourself to a subject domain diagram with the simplest syntax that the customer can understand. In more complex cases, this diagram should be supplemented by a class diagram and a few more UML diagrams should be added to the architecture basket to help describe the dynamic part of your system.
You can take ICONIX as a subset of UML and the process (see
my presentation with
AgileDays in Yekaterinburg ), but it will replace Story Mapping rather than complement it.
In the zero sprint includes preparation for the first sprint. For this it is necessary to describe user interface, design an interface for them and evaluate it. The work is best done in this order, as it contributes to a better understanding of the requirements and their assessment.
Practice scrum or plant a customer on an iterative needleI will not dwell on the traditional practices of Scrum, I just want to point out that they need to involve the customer as much as possible. The minimum program is a customer visit to all the demonstrations: it is vital for you to set the customer on your work rhythm so that he would like to receive the next increment of functionality, like a drug :) This will greatly help build an atmosphere of trust between you.
Maximum program - to pull the customer representative to other events. For example, a visit to poker planning will help the customer to better understand the size of your tasks and understand that the team is working at high speed. Participation of the customer in retrospectives will allow to dive deeper into the problems and risks of the team, and 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.
Author:
Boris Volfson - Head of Softline Development Department