Why are there so many problems in my agile projects?

OK, agile. Do not argue about agility. Let's look at some phenomena and tell me whether you have encountered these problems.

No one mentions the real feedback.

After each iteration, I will do the showcase. However, the most frequently collected information from showcase is the UI problem. The font is too small. After each release, a trial version is deployed for the project. However, if you don't see a real user for "trial", let alone feedback. Does agile emphasize feedback? Customers do not have enough time, and they are not end users. They cannot provide enough in-depth feedback. End users are not interested at all.

What about architecture?

Every iteration needs to be pushed out, where there is time for architecture. At the beginning, we made great efforts to add features. In the previous iterations, everyone was very happy, and the function came out very quickly. Later, the team became slower and worse.

The customer said there was no must have

There are too many things to complete. Let the customer determine the priority and find out the must have. But the customer said, these are all very important. Without this feature, or the feature system is useless at all.

There's a long way to go.

More and more team members complain about story every day. But what are these story? If we do this, we cannot integrate it into a vision. The customer said, I gave you vision. You see the feature. What we need to do is our vision, what is the quarrel between your work ).

 

These problems have the same final root cause. Let's first look at the most obvious feedback problem. Why do customers and end users not mention feedback? It's none of them! Showcase is just a few moments away, and the depth of feedback is not so easy to think of in time. How many release products are actually deployed in the product environment? On the one hand, end users still use this old system, which is busy every day. Where can they try our new system? Whether you have set up a test machine next to his desk or send email reminders three times a day. As long as your system is not a necessary part of his work, he will not care about you.

Why can't the systems released by release be deployed in the production environment? Isn't that strange. Yes, it is really strange. However, if you are a customer, you are appointed by your organization to replace the existing system. The existing system has 100 functions. It may take two years to fully develop these functions. However, there is a performance appraisal every three months. Do you want the leaders to see what you have done every three months? So you find an outsourcing company that claims to be able to do agile development and ask them to give you a version every three months. But can this version actually use production? No! The existing system has 100 features, so many users are using them. How can you replace a system that has been built in three months? A "mature enterprise" requires three months for go or not go meeting of such a system.

Maybe you want to say that we are a real green field developer and completely re-write it. So how does this enterprise work before you develop a system? There must be at least one paper process. Without an electronic system, people use paper and pen and various documents to work. IT systems are just the automation of Paper process. Besides, we have not had a few of them in this year, and we don't have an IT system yet. Do we need to start with paper process?

Unless you are doing very innovative enterprise development. Develop new businesses through innovative IT systems. For example, a new transaction application is used to facilitate the market release of the new margin loan product. Most of the time, we were introduced to "replace" the existing paper process, or the existing legacy applications.

 

Suppose we want to replace a legacy application with 100 features. How can we "play" agile? Basically, we assume a greenhouse environment. In this environment, you can assume that you are developing green field. 100 functions are divided into multiple release, and each release is divided into multiple iteration. A pilot version will be released after each release for testing users. In this way, you can add feature iteratively until the original system can be replaced. In my experience, this practice has partly led to the above problems (or even the root cause in some cases ). As mentioned above, this will lead to the lack of real feedback from end users. Second, because the old system cannot be replaced without a feature, it is difficult for the customer to make a correct choice of priority. For the purpose of replacing the old system, all feature is must have. At the same time, this will lead to a lack of clear and unique goal for each release. This feature is often used, and the feature is used, so the team will feel that there is no clear goal.

 

If we do not target the old system? So what should we aim? At this time, you can check out Eric Evan's strategic design. He said, you should think about what drives you to spend million dollars on this project in the first place (why did you decide to spend $1 million on this project at the beginning ). There must be a reason behind this. Based on our understanding of this reason, we can select a certain feature for implementation. Then we started implementation and deployed the implementation for all users to use. Using this strategy, instead of the previous one, forces us to do a lot of things. I believe that these things may help solve the first four problems. In particular, the architecture issues. Why? What is the architecture? Architecture is a way to resolve the problem. How can we force us to think about architecture problems? Create a hole in the existing system, dig out a hole, enclose a wall, and create a new feature. Without an understanding of the entire system, decomposition of modules, and analysis of coupling dependencies between modules, this is impossible. This forces us to make a low-coupling, high cohesion architecture!

 

to make this strategy the best is what I have said before. Continuous deployment is the king. Not only is each release integrated with the old system, but it is then truly deployed. Even we can deploy each iteration. There were no iterations in the Team described by fred george. A feature is deployed immediately after it is developed.