Transparent development

We develop it products to order. Since we are not developing our own projects, and create them for clients, it is important for us to build personal relationships with them. As it turned out, really depends on how it is developing. We are able to work productively with customers and create successful products. But usually the work on the project begins with fairly low confidence.

As for young companies, for them it is one of the main problems. I want to tell you how we build the transparent development process, which helps us to establish trustful relationship with clients. The theme of the relationship between the contractor and the customer in the development of it products, not new. The company is “At” in his article “Management tools.

Why customers demand stupid reports?” rather dwelled on this question, showing the four stages of relationships and possible transitions between them. Formally they can be represented in matrix form. Im not going to describe in detail what each of the stages. Let me just say that our task is.

From square A, when customer confidence and transparency of the process at a low level, move to square C and stay there. The route to be followed is as follows. A → B → C. We can do this by increasing the transparency of the process — after that establishing trust becomes a matter of time.

Why you should try to remain on stage C. If we go to stage D, our situation will be very unstable, the cost of failure will be too great to risk again to go to low trust. Interestingly, the transition C → D is almost always due to the customer, at least judging from my practice.

The client just relaxes. May cease to participate in the planning and retrospectives, because everything is fine. After it relaxes to the development team. In my experience, this has happened twice (Dmitry, Hello!). The client regularly pays money, but virtually not involved in the operational management of the project.

Really was only after a year of work — after we have saved the product and began to produce a stable release. What we do to keep the relationship in the stage C. Briefly. Do not relax.

Didnt have a client on the stand-up meeting or retrospective. So, we need to send the result to him in the mail. Tell him about all the problems, issues or successes. The story was not abstract, Im relying on a real project, which we happened to do recently.

We were approached by a customer refused to continue cooperation with another contractor. The reasons for such situations are often similar — we intentionally Refine them to better understand customers. The subject area of the project — construction, service selection building contractors. The model is similar to “Yandex.Master”, only the emphasis is on construction work.

Development was carried out in a cascade model (waterfall). It was planned a certain set of functions on TK for some time, the guys took all this to realize and then once rolled out what happened. Moreover, the client and so not really know who you are — so he still doesnt understand what all this time was team whether she needed so much time and, if so, why is the product the result was not as he expected. The customer preferred to concentrate on the business (and rightly so), not to audit the work of the developers.

But in this case the situation was lose-lose for both sides and, unfortunately, there. With this customer initially difficult to work with because he was very distrustful and for the second time wants to see and to control everything. You can understand him, and he needed help. The initiative in such cases is always on our side.

What to do. We help techniques from Agile software development. I havent seen a single team who strictly followed any particular methodology. Usually the process is built from a combination of different techniques that are adapted to specific team or project. So do we.

We received feedback from the customer regarding the previous development process, understand the weaknesses and fixes them, adding in the process several important components that directly interact with the customer. Next, each item will be considered mainly from the point of view of benefit to the customer. It usually starts with what we are asked to estimate the cost and timing of project development.

It was with this customer. Here all act differently, but now we mainly evaluate the projects after story mapping. Let me explain why. The essence of the story map is to describe system from user perspective and to put all scenarios on two axes. Time and priority.

What gives. A real example of a Story Map for the first version of the project. The build took two to three hours. After you have built the first version, likely to follow improvements.

The resulting map is being digitized, it stops. Read more about the practice and its benefits over conventional TK, I told in the article “Story Mapping. A powerful tool in the Arsenal of developers”.

Our customer was in the following situation. Was required to develop the first version of the project (volume about 100 days), which needed to demonstrate to investors that the development had continued. Seemingly small amount for a team of three people, team with a defined — whats the worst that can happen during this period. But it was not so good. In many cases the system behavior was not as expected by the customer, — for various reasons.

The problem is that over this period was only released one release. In the end. We do things differently.

During the months of development there is nothing preventing us to release the weekly releases (in fact — daily). Thus, in the month produced, on average, four releases instead of one. What gives. We quickly received feedback from the client and can immediately react to it.

Continuous integration is an integral part of quality development. Any changes in the code should automatically get deployed on the testbed, where they have to check the QA Manager. In this case, this is due to two main reasons. Feedback and the customer.

Quickly realize that something went wrong, as expected, is very important. In addition, when the customer at any time have access to the latest product version (albeit not 100% working) — you know, this has a positive effect on his attitude towards the team. We immediately explained to the client the value of continuous integration for your product launch, so after a while the project got a CI server. We use TeamCity for integration.

To work on the project we will plug QA Manager, who is responsible for the quality of the product overall. Its not just a test case, “protecive” project task description. This is the person who handles all the scenarios of system use, verifies completed tasks, carries out regression testing before release. His work largely determines the quality of the project is its responsibility.

We had cases when we had to justify the connection of additional person who “would be stupid for you to check your work”, but that is an exception. If, before this reaches you, we can help demonstrate the case when QA Manager is useful and also common sense. Now many teams (even those that dont work on agile methodologies) used in the so-called Agile Board to all members of the team before his eyes focused on the current tasks, their status and so on. We use virtual boards to the team and the customer saw the situation.

We tried to work with AgileZen, Trello, TFS and YouTrack. The main problem that I have been able to see, is incorrect splitting into statuses (columns). When the task is on the Board, there should be questions about her condition. Lets return to the team that worked with our client to us.

On their Board after the status of “Working” was the status of “Testing”. This is wrong, because in this case it is impossible to determine whether this task is currently in test mode, or the developer just did it and moved to the next status. And such examples weight. The Board is an important element of the process.

The client should always have access to the Board, and it needs actively to use it. We were very surprised to learn that the customer for all the time the development opened it only a few times. The backlog (Backlog) for Board is formed on a Story Map constructed in accordance with the priority designated by the client. About the stand-up rallies all know, but not always used in practice.

These mini-meetings lasting no more than 15 minutes have great value to the project. Every morning, before lunch, we call each other on Skype with the client, and each tells what he has done yesterday, what problems arose, how he decided or not decided, and signed on what will make today. Daily live chat has a positive impact on the relationship, it is noticeable with every new week.

Developers like to translate the conversation in too technical a plane. For example, I can say. “I wrote a migration that replaces the relationship one-to-one one-to-many”, instead of saying. “I implemented the ability to add multiple categories to publish instead of one”. These things need to be moderated.

The customer is interested to hear about the results from the point of view of business, not technical implementation. After the end of each iteration (it lasts a week) we are holding a demonstration of the work done to the client. Show what was done or fixed. You need to demonstrate, not just to send the customer a link to a dev-server where he will be able to see it myself.

Hell see only after the demo. During the demonstration we try to get feedback and have discussions, make notes, record observations on the Board. The demo is a very important component of the development, pleasantly exciting. We have in the demo involved the whole team, and hosted by the team lead or QA Manager.

All of the above are necessary components of a transparent development process that help us build relationships of trust with clients. In addition, it is the base on which our company is based the process as a whole. It is also worth noting that for most of these techniques and maintaining the pace of work the development team needs to be high enough level.

We very strictly follow this process.


Leave a Reply