Summary: Some things you need to know about Agile development from personal experience.

Agile development mode is the general mode of modern software development. According to statistics, more than 90% of software development has adopted agile development mode since 2018. Regardless of the advantages and disadvantages of agile development mode and waterfall development mode, considering the current data statistics and the transformation results of major companies, especially companies like SPACEX and the whole rocket super hardware are adopting agile development, adopting agile development must have certain advantages.

The author has been involved in software development for 20 years. He has experienced the traditional waterfall development mode, participated in professional agile development training, and obtained certified certificates. He has led the team through the whole process of waterfall to Agile, from a Scrum team of 10 people to a multi-Scrum team of hundreds of people. First, I would like to share an interesting experience. At the earliest, the company tried to be Agile. The boss added one QA from different fields to form a Scrum team of 10-12 people (I worked as part TIME PM of PO and PART time SM of QA). The boss wanted the team to be able to do everything from requirements to design to development to testing (it was before DevOps and we didn’t run operations). The first project I received was the test across Web, Server, client and complex scenes. Due to the unbalanced division of labor in the project, I was required to work in the project and learn new knowledge across the field at the same time. This was done slowly for 3 months, and the team grew rapidly in the process. Later, due to a special event, I took the team to a new project, and the development and management process of this project was different from that of the whole company. The whole team added a PM (this PM is responsible for a lot of things, we are just one), and the thing itself is the End2End feature, including the client side (too much) and the server and Web API side (too little). At the same time, the client was across multiple platforms (Win/Mac/iOS/Android), there was no special team to test us, and our team had to do all the testing work (developer testing + system level testing) before the release. In the whole process of research and development, I also had to cooperate and communicate with the Us and Ireland team, which was a great growth experience for everyone in the team. From an ordinary developer, I became a Senior Manager at Microsoft in just a few years. This article is not about Agile processes per se, but about what you need to know about Agile development from personal experience.

1. Figure out why the team is moving to Agile mode!

The fundamental difference between Agile and waterfall development is “iterative” + “incremental”. The emphasis here is on incremental development. If your team is developing a project or product that is agile, but not in an incremental way, the team will be confused as to why agile and what agile brings. The author’s project was the first to adopt the waterfall development mode, usually a release every 3-6 months. When steering agile team is inspired by the largest customer affirmation, because six months of the program, at the time of two months, the client can try out the primary function of the version, the customer for a few months after the product is full of interest, even though a lot of problems in the use, but they are very happy to go to use, and put forward a lot of comments and feedback in use. These feedbacks are of great help to the team. In the process of monthly iteration, customers see the improvement and change of functions step by step. Before the product release, customers have already had a comprehensive understanding of the product they are about to get. Even some product features and usage habits are suggested by them. The changes brought about by this development model are at the root of many teams moving to Agile. If you adopt Agile to your team and then develop in a way that just breaks up six months of product development into one or two weeks, without really understanding agile or enjoying the benefits of it, it doesn’t make a lot of sense to move to Agile.

2. Agile has nothing to do with product quality!

As I’ve said more than once in various articles, the quality of the product has little to do with the development process, at least not the Agile Waterfall model. Product quality needs people + time. With the right people and enough time, product quality can be improved. In my previous company, I was engaged in online collaboration products (Welink+ video conference). Our product Release mode is one Feature Release (DeliverFeature) every month and one Patch Release (FixBug) every week. During the epidemic last year, the demand for products based on the epidemic situation surged. In order to cater to the market, we worked overtime, and the whole function developed was more than 100% more than usual. In this case, the quality of the product can be imagined, and many problems have been known before the release. Due to the market needs, the product is often on the production line with hundreds of bugs under the approval of VP. Then, Patch Release after Patch Release will be used to fix these bugs. The quality of your product is ultimately determined by your testing, whether it’s developer testing or QA team testing, and ultimately the quality of your product is guaranteed through thorough testing prior to release. Of course, the importance of developer testing is not discussed here.

3. One of the most important things for Agile is to manage your backlog!

One of the most important things about agile development is that what is going to be done is always changing, and that change determines what is going to be done over time. The backlog is what is often called. Managing your backlog is extremely important. Backlog management is the foundation of the entire agile high gear.

Backlog management usually refers to the following aspects:

  • All the things you might be doing in the next two years, and give each one an estimated priority (number, letter) and estimated amount of work (T-shirt Size, XS, S, M, L,XL, XXL…). .

  • Backlog is related to user needs, r&d code refactoring, and architecture evolution techniques.

  • The team sits down periodically to decide what to do roughly over the next 3-6 months, including the requirements and technology backlog, balancing technical and user requirements.

  • When deciding what to do, the architect should be technically Design Ready (usually recorded in a wiki), including the architectural Design (Design) and the work division (US/Task), and then it can be implemented in the project iteration.

  • During each iteration planning, the team sits down and decides what to take from the Ready backlog.

From the perspective of backlog management, the product manager and architect are very important, both of whom are responsible for the preparation of the entire iteration in addition to the normal iteration process. The whole team is more like a high-speed machine to “produce” the “goods” one iteration at a time. You can see why so many organizations are moving to agile development, except for the first point, which is to maximize human resources to generate value.

4. Large projects break up Agile teams as End2End as possible

Usually, companies will divide the organizational structure according to certain rules. Take my previous company as an example, it was divided by region (Shanghai, Hefei, Hangzhou and Suzhou) at the first, and then by domain (Client, Web and Server). Even within a field, there are different subdivisions. But in general, making a product feature involves different areas, different sub-areas of the same area. It’s hard to have an organization where everyone can do everything. Large projects, in particular, run into a lot of problems if each Scrum team is divided by domain and multiple domain teams work together on a single feature. My previous experience is that in a large project, many different functions will be planned in each iteration and assigned to different Scrum teams. Each Scrum team will combine staff according to the functions to ensure that each team can complete almost all the work independently, and End2End will deliver features. At this time, the composition of the team has two characteristics: 1) different organizations (different LMS), 2) the team members are constantly changing. In fact, this mode is extremely challenging and requires high collaborative working ability.

5. Agile team PO and SM are the guarantee of the team

In the process of product iteration, many things are very tedious, but also subject to a variety of interference, as well as pressure from various aspects. At this time, PO and SM are the core of the whole team. For PO, he should take all the responsibilities as long as he can, so as not to let the team have any worries. Usually, someone in management position can take the role of PO. SM is there to help the team manage the project, and it is highly recommended that the right woman be appointed. For SM, whenever she can do something related to the project, she will take the initiative to help the team to complete it, such as meeting organization, status update, team building and other things, so that the team can Focus more energy and have more motivation. The common mission of PO + SM is to ensure that the team is fully engaged in the work during the iteration cycle.

6. The ultimate determinant of Agile success and effectiveness is people

When we say 3, 4, 5, you will find that we are talking about PM, Architect, PO, SM, and Team. We are talking about people, not processes. Agile processes give the whole team more autonomy and require everyone on the team to be strong in terms of intention and ability. When you talk about it, it’s like a small startup team, and yes, that’s why startup teams are so effective. In fact, in large organizations, a lot of times, for a variety of reasons, you can’t do that, so you have to adapt the process itself to your own people.

We want evolutionary agility, not standard agility!

If you go to different companies, each company’s team is going to be different and evolving in the process of agile development. The reason is that different companies have different cultures, and the composition of people is so different that a team full of great people may not be able to do agile well. Agile teams themselves evolve as an architecture, as they grow, as people change, and even as organizational structures change. Take my previous team as an example. Our Scrum team did not have the definition of PO, but its responsibilities were jointly completed by ProductManager, Deliver Manager and Architect. Together with SM, these four people would form a fixed combination and lead multiple teams according to the project. Form multiple Scrum teams. This is very different from traditional agile teams and is not necessarily replicable. So in this article, I can’t tell you how to successfully transition from waterfall to Agile, and I can’t tell you how to improve your team’s agile effectiveness. But as you can see, people are the foundation of an Agile Team, and a Team (PO+Architect+SM+PM+Members) is critical to its success. And the right combination of your teams, let those teams serve a product. When these teams work together, they prove their value by implementing product features iteration by iteration to meet user needs and create value for the enterprise!!

Click to follow, the first time to learn about Huawei cloud fresh technology ~