October 5, 2015 at 20:30Transparent software development process
For young software companies, one of the most important problems facing development is the low level of loyalty (trust) of [potential] customers. In general, over time, subject to quality work, it is gradually eliminated in a natural way. However, in what way can this decision be accelerated? One option is to organize a transparent development process.
Recently, a client came to our company who refused to continue cooperation with another contractor. The reasons are standard. The developers created the product on the principle of a black box: a list of tasks was determined, they left to do all this, and then immediately rolled out everything that had happened to the client. Hence a lot of problems, the constant distrust of the client, because he does not understand what the team was doing this time, whether they really needed so much time, and if so, why, as a result, the client was still unsatisfied. Hence the result: the product was not what the client expected it to be, spoiled relationships and reputation. Losing situation for both.
We managed to rectify the situation by organizing a transparent development process. When working with the previous contractor, the customer had to spend a lot of time on the technical component of the project, engage in constant checks of developers, instead of concentrating on business. Now the client at any time understands what stage the project is at, has the ability to adjust the progress of work, and gives us quick feedback.
We have long enough developed for ourselves the most successful version of the combination of several flexible software development methodologies that we successfully apply (sometimes it changes in details and adapts to a specific project). The main components of our process will be described below, which, in my opinion, affect the speed of establishing trusting relationships between developers and clients more than others.
Flexible development methodologies come to the rescue. In my experience, teams never adhere to strictly one methodology, for example, Scrum or Kanban, most often each team simply adapts combinations of practices from different methodologies. For example, we use almost all the tricks from extreme programming, except, say, Planning Poker. As a result of such experiments with adaptations of methodologies, a process is built that best suits the team.
We understood the weaknesses of the development process of the previous team and eliminated them by introducing several important components that are directly related to the interaction with the client. Here are the most important ones.
The process was structured as follows. We are planning a certain set of functionality that needs to be performed at the current stage. The volume of work, for example, corresponds to the month of development, but this does not prevent us from releasing product releases weekly (in fact, daily), adding new features gradually, and not once. Thus, in a month we release 4 updates, instead of one. This gives us the opportunity to receive feedback and respond to it as quickly as possible.
Continuous integration is an integral part of quality development. Any changes should automatically get to the test bench in a fully assembled form, where they should be checked by a QA engineer. In this case, there are two main reasons: feedback and customer. As quickly as possible to understand that something went wrong, it was very important. In addition, when the client can at any time have access to the latest version of the product (if not always 100% working), it positively affects his loyalty in general.
First of all, the board on which the development process is reflected should generally be :) But the incorrect division of the board by status can have a negative impact on the project. When the task "goes" along the board there should be no doubt what exactly happens to the task and in what status it is. The following columns were defined for this project: Backlog - Todo - In work - Done - Testing - Resolved - Deploy. In another case, most likely there will be a different set. It is important that these columns correspond to the natural course of the problem and are not ambiguous.
A QA engineer responsible for the quality of the product as a whole should be connected to the team. This is not just a tester who “pokes” the system according to the description of the task. This is a person who conducts completely all the scenarios of using the system, tests new tasks, conducts regression testing. His work largely determines the quality of the product, so such a person must be involved in the work.
Stand-up rallies - everyone knows about them, but really not everyone uses them. These mini-meetings lasting no more than 15 minutes are of great benefit to the team and the project as a whole. Every morning (or before noon) we call Skype with a client and each member of the team talks about what was done yesterday, what problems arose, how they are solved or resolved, and also subscribes to what will be done today. This practice, among other things, gradually increases the level of trust between the client and the team. [In Kanban, by the way, stand-ups are different]
After the end of each iteration, you need to demonstrate the work done to the client. You need to show everything that has been done or corrected. Demonstrate, and not just give a link to a dev-server, where the client can see everything for himself. He will look at it himself, but after your demo. It is important to immediately get feedback, perhaps hold some kind of discussion. Demonstration is a very important component. Pleasantly exciting. The whole team takes part, but someone alone directly demonstrates: team leader or QA engineer.
In this article, I have listed several key components of the software development process that have allowed us to build a loyal relationship with a client who has poor experience working with another team. Of course, flexible methodologies offer much more different methods, many of which we use, but here I have cited exactly those that, in my opinion, are more important than others to build a transparent process and customer trust with performers.
It is also worth noting that in order to perform similar techniques and maintain a high tempo, the development team must be of a sufficiently high level. This is especially true of extreme programming practices, the main points of which are aimed specifically at the engineering component.
Thanks for attention. I hope that for beginning teams with processes that have not yet been fully set up, the article will be useful.
Scrum and Kanban: squeeze the maximum, H. Kniberg and M. Skarin .
Extreme Programming, C. Beck .
Lean software production, M. Popendik and T. Popendik .
Recently, a client came to our company who refused to continue cooperation with another contractor. The reasons are standard. The developers created the product on the principle of a black box: a list of tasks was determined, they left to do all this, and then immediately rolled out everything that had happened to the client. Hence a lot of problems, the constant distrust of the client, because he does not understand what the team was doing this time, whether they really needed so much time, and if so, why, as a result, the client was still unsatisfied. Hence the result: the product was not what the client expected it to be, spoiled relationships and reputation. Losing situation for both.
We managed to rectify the situation by organizing a transparent development process. When working with the previous contractor, the customer had to spend a lot of time on the technical component of the project, engage in constant checks of developers, instead of concentrating on business. Now the client at any time understands what stage the project is at, has the ability to adjust the progress of work, and gives us quick feedback.
We have long enough developed for ourselves the most successful version of the combination of several flexible software development methodologies that we successfully apply (sometimes it changes in details and adapts to a specific project). The main components of our process will be described below, which, in my opinion, affect the speed of establishing trusting relationships between developers and clients more than others.
How to add transparency?
Flexible development methodologies come to the rescue. In my experience, teams never adhere to strictly one methodology, for example, Scrum or Kanban, most often each team simply adapts combinations of practices from different methodologies. For example, we use almost all the tricks from extreme programming, except, say, Planning Poker. As a result of such experiments with adaptations of methodologies, a process is built that best suits the team.
We understood the weaknesses of the development process of the previous team and eliminated them by introducing several important components that are directly related to the interaction with the client. Here are the most important ones.
Frequent Releases
The process was structured as follows. We are planning a certain set of functionality that needs to be performed at the current stage. The volume of work, for example, corresponds to the month of development, but this does not prevent us from releasing product releases weekly (in fact, daily), adding new features gradually, and not once. Thus, in a month we release 4 updates, instead of one. This gives us the opportunity to receive feedback and respond to it as quickly as possible.
Continuous integration
Continuous integration is an integral part of quality development. Any changes should automatically get to the test bench in a fully assembled form, where they should be checked by a QA engineer. In this case, there are two main reasons: feedback and customer. As quickly as possible to understand that something went wrong, it was very important. In addition, when the client can at any time have access to the latest version of the product (if not always 100% working), it positively affects his loyalty in general.
Correct board
First of all, the board on which the development process is reflected should generally be :) But the incorrect division of the board by status can have a negative impact on the project. When the task "goes" along the board there should be no doubt what exactly happens to the task and in what status it is. The following columns were defined for this project: Backlog - Todo - In work - Done - Testing - Resolved - Deploy. In another case, most likely there will be a different set. It is important that these columns correspond to the natural course of the problem and are not ambiguous.
QA engineer
A QA engineer responsible for the quality of the product as a whole should be connected to the team. This is not just a tester who “pokes” the system according to the description of the task. This is a person who conducts completely all the scenarios of using the system, tests new tasks, conducts regression testing. His work largely determines the quality of the product, so such a person must be involved in the work.
Standup meeting
Stand-up rallies - everyone knows about them, but really not everyone uses them. These mini-meetings lasting no more than 15 minutes are of great benefit to the team and the project as a whole. Every morning (or before noon) we call Skype with a client and each member of the team talks about what was done yesterday, what problems arose, how they are solved or resolved, and also subscribes to what will be done today. This practice, among other things, gradually increases the level of trust between the client and the team. [In Kanban, by the way, stand-ups are different]
Demo
After the end of each iteration, you need to demonstrate the work done to the client. You need to show everything that has been done or corrected. Demonstrate, and not just give a link to a dev-server, where the client can see everything for himself. He will look at it himself, but after your demo. It is important to immediately get feedback, perhaps hold some kind of discussion. Demonstration is a very important component. Pleasantly exciting. The whole team takes part, but someone alone directly demonstrates: team leader or QA engineer.
Conclusion
In this article, I have listed several key components of the software development process that have allowed us to build a loyal relationship with a client who has poor experience working with another team. Of course, flexible methodologies offer much more different methods, many of which we use, but here I have cited exactly those that, in my opinion, are more important than others to build a transparent process and customer trust with performers.
It is also worth noting that in order to perform similar techniques and maintain a high tempo, the development team must be of a sufficiently high level. This is especially true of extreme programming practices, the main points of which are aimed specifically at the engineering component.
Thanks for attention. I hope that for beginning teams with processes that have not yet been fully set up, the article will be useful.
References
Scrum and Kanban: squeeze the maximum, H. Kniberg and M. Skarin .
Extreme Programming, C. Beck .
Lean software production, M. Popendik and T. Popendik .