On five ways of benefiting from agile engineering practice

Creating useful software is the door process. This is not a black-white formula for success. However, there are some agile engineering practices, practice has proved that it has repeatedly added value to the enterprise, but the premise is to be considered before use. In this article, I'll share with you 5 specific ways in which your organization can benefit from agile engineering practices.

(Assuming we use Scrum + Extreme Programming (XP) = Agile's basic formula, I'll talk about the XP part of the formula when I speak about agile engineering practices, such as test-driven development, pair programming, and continuous integration. ）

James Shore said in a brilliant blog:

" scrum is simpler than XP and has little impact on the original work, so I see a lot of people starting with scrum. The problem, however, is that the team starting with scrum is much more than the team that started with XP. The XP team will experience more pain at the outset, but in the first year it will be efficient. "

Not only did I agree with what he said, but I have seen it many times in my own eyes. XP is hard. It is difficult to require strict discipline, in addition, its advantages are sometimes difficult to see the bar.

My father is a dentist. He once told me, "It's hard to find a good dentist." Dentists can fill up or kill the nerves, but you won't know for 5 years if he's doing well, because it will take a while before you know he's done well. "XP is very similar.

I know that the best software developers (and thousands of them) are the most disciplined in a high-pressure environment.

Many developers experience the agile/scrum/lean/xp approach. But when the strict deadlines are approaching, or when the team is delayed, or when the company asks the team to "quickly finish", how much discipline can they maintain?

There are many XP practices. The most valuable ones for a business are:

There are many XP practices that are most valuable to business:

Test-Driven Development-TDD is your commercial safety net. Because the test is done before coding, the finished test will fail to run, and then write the code to pass the test. TDD guarantees your product functionality, regardless of whether the company or the technology team is implementing a large scale change or a small change.

Pair programming-Lets 2 developers write the same piece of code, using the same keyboard and the same monitor. Because pairing greatly reduces wasted time and defects, it leads to higher quality code and a high level of collaboration.

Collective code ownership and continuous integration-if each piece of code is not just one person familiar with it, then there is no communication bottleneck. Continuous integration of code into one backbone avoids duplicate and mismatched code.

Refactoring-in the case of the time, the code written is a solution to a known problem. Often, the team solves their problems subtly, and then continues to refactor and modify the code to ensure that the code base continues to meet the latest business needs in the most efficient manner.

However, given that XP is difficult, it requires continuous training and a certain amount of time to ensure that it can be done well, executives want speed. "I want my engineering team to get better agile engineering practices and make us faster," said the technical directors, vice presidents and CEOs. ”

At first, I agree with James shore that XP is really hard, in fact it violates the idea that agile helps the team faster. In fact, XP has a steep learning curve, and it is natural that it takes a certain amount of time to learn, and the team that learns XP is certainly slower than a team that doesn't learn anything.

So, if "faster" is not the real value of agile engineering practice, then what is its real value?

I think the real value of agile engineering practices is that they allow companies to embrace change in some way, which in fact will be a competitive advantage.

Why, then?

As we enter the 2014, this argument will logically be justified. If that is the case, then, for the next decade or so, companies that make the most of the software-building process will succeed .

Yes, we all know the reason, there are many competitive advantages outside the software. For example, hedge funds that can make the most of their mathematical work to predict future stocks will have a competitive advantage. Retail stores that can make full use of fabric and color to predict future fashions will have a competitive advantage. But with 7 times 24 hours of network connectivity and global information sharing, you've just come up with a good idea, and your competitors will be imitating it.

This makes us go back to the idea that companies that can take advantage of software-building processes will have a huge competitive advantage over their competitors. The key word for this concept is "process". It is irrelevant to the technology stack. The key to fully benefiting from the Agile engineering practice is to be able to stick to the minimum process principles when there is a crisis. it's like exercising. If you exercise five times a week on vacation and exercise once a week at work, you actually only exercise once a week. If you're practicing pairing and TDD long before the deadline, you're not going to be diligent in practicing agile processes once you have to put your agility aside by the expiration date.

The five specific ways that companies can benefit from using agile engineering practices are: