Take Kanban to save you--my "red" project

This case describes how to use Kanban and lean development techniques to save a "red" project.

Background

This article is about a large client user development project that has been around for almost a year. Backwards and forwards, the development team maintained a base of 10 to 15 members.

At the beginning of the project, the team used the traditional waterfall development model. Before the code development phase is the requirements analysis phase, the requirement analysis usually takes 2-3 months and is postponed. What is more, in the requirements analysis phase, the scope of the project is often changed, often beyond the prior agreement between the customer and the development team. The requirement analysis cycle took nearly 6 months to complete, roughly 100% of the progress timeout, as the customer insists on the need to "identify" the requirements and the development team must get the customer's "signature" on the requirements document.

Although the fact is that the requirements analysis phase has exceeded the planned time, the date of the project end has not been changed to conform to the actual situation. The result is that the development team is forced to deliver more of the extra functionality in less time. Ultimately, the development deadline is not complete, and because the test is also a hasty end, the development of validation is not sufficient.

In addition, because the project manager is unable to manage the customer, the protection team is not interfered by the customer, the whole team operates in an "interference driven" mode. A typical pattern is when a customer shouts a quality question to the project manager and then communicates the message to the team. So no matter which crisis appears, can not be repaired in time. The team does not have the means to concentrate on one issue and to do the work without interruption. When I parachuted into this project, the customer's relationship with the development team was very bad and the customer refused to pay. Users are also reluctant to accept developed functionality, reliability, and performance. The project has been overrun by hundreds of thousands of dollars and plans have been planned for several months behind schedule. Neither the client nor the development team can bear the brunt of the project's failure, so something must be done to get the situation back.

Control

When you face this situation, the first thing to do is never panic. In this case, the customer is very excited and has no confidence in the team, and the customer and team even accuse each other. Morale is bad and getting worse, only because management expects the team to work hard to fix the problem.

This time, you must not add to the fire, one wrong again, the same way to continue your mistakes. Experience has shown that the best way to do this is to target data and facts, rather than personal emotions. It is important that we explore the root cause of the cause, so that we can find the direction to correct it. But there is no need for the team to feel that everything they are doing is wrong, and that will only make it worse. Identity is equally important, and there are always one or two things the team does well. ）

In this case, the main problem is the poor quality of the product, and the number of defects that have been found supports this claim. We must allow the product to successfully deliver some functionality so that the customer can use it. It is imperative to create an environment in which the team can focus on only one issue during a certain time period.

Establish quality culture

If we repeatedly emphasize the importance of creating software to be able to work properly, and as a prerequisite for software development, this seems ridiculous. But this is one of the main areas where most software projects continue to be challenged.

In the early stages of the project, the development team spent several months trying to document the needs of the customers they thought they wanted. On the contrary, this leads to a false feeling that the development team and the customer think this is the software they will eventually deliver. In addition, only those team members who are required to analyze with customers during the requirements analysis phase are analysts. Developers will not be able to begin work until the analyst believes that the requirements analysis is "done".

This triggers a series of subsequent phenomena:

Developers have to digest and explain the needs of their customers, forming 200 to 300 pages of documents as atomic units.

Even after both parties have "signed" The requirements document, the customer continues to change the requirements. This means that the work of the developer is consistently denied and changed.

This results in the development duration having to be extended beyond the previously scheduled completion date.

The test must wait until all the development work is "done" before the final stage begins. The test was forced to end in haste as the deadline had expired.

Quality is no longer a measure of whether the development software works correctly, but is a measure of how often computing testers and developers interpret requirements in the same way.

The end result is that hundreds of bugs abscond from the development process and eventually appear in front of the customer. Admittedly, bugs are the worst waste because they are the developed state of the wrong needs. This means that customers spend money to buy the software they develop, and then they (or the team) have to digest the cost of making it work correctly.

Obviously, the way the development team works doesn't put quality first, in fact, it puts the quality at the bottom. Because analysts, developers, and testers are rigidly put into the project, each GU is doing a separate task. They never work together like machines that are integrated together, nor do they feel the responsibility of collaboration and the sense of belonging to the system's quality. Whenever there is a problem, they blame each other. In short, they failed to create and accept such a culture of quality.

The most important decision we have decided to take control of quality is to require the developer to complete the acceptance test of the work item that is being developed before the code is written. This is what people call acceptance test-driven development (acceptance test driven development or short ATDD). With ATDD, we literally put quality first.

The way we use ATDD to fit this project is that we require relevant acceptance tests for each work item in backlog. As a result, requirements that are not covered by code are effectively documented. This also forces testers and developers to have the same understanding of the same starting line before coding begins. The developer's work focused on letting those failed acceptance tests pass. It is important to clarify that the tests are developed based on the work item level, rather than developing a batch of work items at the same time.

This approach radically alters the way that guesswork works, and the code developed is either right or wrong. Tests either pass or fail. It's so simple, it's not right, it's wrong. Since each developer's focus is on only one work item, the number of acceptance tests that a developer needs to understand for a period of time is never too much compared to the previous mode of work to understand the entire analysis document. The status process of the acceptance test is:

Failed. The test failed immediately because the code did not implement the functionality and passed the test.

has been developed. Let the test pass code already written. When the developer implements the code, they confirm the process state.

Pass. The tester confirms that the code that was developed did pass the test.

The positive results of the transformation of product quality have been obtained only by using the ATDD method.

During the first 8 weeks of using ATDD, we turned a document that was not covered by any test document into a project with a full set of tests and Test history documents, guaranteeing the overall quality of the code that was developed.