This article will summarize the pit we stepped on in the process of transformation in the past period of time, as a cautionary tale. Also talk about what good practices you can try in the transition process to take the path of gradual change.

Today, we’ve been on the agile transition road for 16 months. From the excitement of the start to the indifference of the present, I still think of it as “Patternson broken”. I thought that with the adoption of agile, everything would be better over time. However, it is not so simple. Limited by the organizational structure, we cannot just copy the operation mode of agile, let alone adapt to our product research and development.

While the agile transition has not progressed as well as expected, we have implemented some of our best practices and improved product development efficiency in the process. This article will summarize the pit we stepped on in the process of transformation in the past period of time, as a cautionary tale. Also talk about what good practices you can try in the transition process to take the path of gradual change.

1. Introduction to Agile, Are we doing Agile right

Where people are exposed to Agile, they don’t know much about it, and they tend to take it literally: “Agile is fast”. When people get upset, they ask, are we doing agile right? On the other hand, as we are new to Agile, we start to theorize, strictly follow the methods and rules defined by Agile, with awe for Agile, naive to think that everything prescribed by Agile is good, and other methods and methods are imperfect and flawed. Yeah, those were my two biggest mistakes when I first started agile.

1.1. Look beyond being agile and fast

Fast is simply a consequence of agile. Simply focusing on this result will not help our transformation. As for the definition of fast, we used to refer to the pace of others to make products, find outstanding enterprises in the industry for comparison, and think that is fast. However, we rarely pay attention to the category and complexity of the corresponding products, ignoring the details of their organizational culture, organizational structure, quality of people, and trade-offs in the development process. I see other people’s children are all good, and my own children are full of problems, but I don’t understand how others solve those problems and what the cost is. I just want to take advantage of other people’s advantages and ignore their shortcomings.

If you want to think about its benefits, consider its harm; if you want to think about its success, consider its failure. “– Thinking about Sixteen Cheap Ideas

When we were doing agile transformation, we introduced external consulting training. During the training, the teacher gave an example: “When they were making products, they could deliver more than 20 versions a day.” It takes us more than a month to ship a version of our product. Although we knew that the product the teacher gave us as an example was a Web product completely different from our product, we still couldn’t help thinking that we could send one version every week, or even faster, since others had more than 20 versions a day. Yes, our eyes are completely attracted by the “fast”, so everything revolves around how to carry out reform faster, trying to make full use of resources, all kinds of parallel, but lead to chaos.

Stay true to your original aspiration and seek truth from facts

We are a company that mainly sells consumer hardware products. Before agile, we used a waterfall development model that worked well with low product complexity and fewer developers. However, as the product grew in complexity, the number of developers and dependency increased, the development model became cumbersome, even a basic message was broken, it became difficult to integrate a release, and release dates were always delayed. As a result, we didn’t ship on time, had long launch cycles, and became “less agile” in product development. However, to actually solve the problem, we need to improve in the following aspects:

  • Establish a new communication mechanism to ensure effective communication of cross-field collaboration.
  • Requirements are effectively prioritized, quantity controlled, and delivery rates committed to the priority requirements.
  • Avoid creating too large a team organization. If there is one, break it down into small teams of appropriate size according to the independence of the business.
  • People should be decoupled between teams, and try to avoid having one person on multiple project teams.
  • Be transparent and try to allow team members to make their own decisions based on the information they have, rather than asking their superiors.
  • Establish cross-disciplinary team and conduct promotion and guidance on agile development knowledge.
  • Introduce continuous integration.
  • Limit wIP, avoid one person to carry out multiple work at the same time, in principle, no more than 2 unfinished tasks.

And so on…

We are no longer focused on whether we are performing the activities specified in Agile, or our current project process is not fully agile, we are more focused on what is the most effective solution to our current problems.

1.3. Our stumbling block

This article begins by looking at the mechanisms that the organizational structure prevents us from fully introducing agile development. I’m sure everyone who has done agile transformation has encountered this problem. Here are some of the practical issues we encountered in the Agile transition, and don’t be surprised when you encounter them. It is difficult for a traditional, mature organization to change, especially without active leadership at the top.

Without a product manager, agile teams focus only on development and release, regardless of the beginning or the end.

The organizational structure of our company adopts the form of weak matrix, and the Agile team plays a more collaborative role in developing front-end requirements. They do not need to be directly responsible for the product, nor do they care about the feedback of the product in the market.

Clear boundaries between testing and development responsibilities.

In the ideal Agile world, we start testing during development, but we still need to test after development, going down the “little waterfall” path.

Short cycle iteration is not possible and iteration is abandoned.

Because of the “little Waterfall” approach, there was no way to do shorter iterations, and iterations of more than 2 weeks were no longer meaningful for a monthly release.

Good functions will be sent out, there is basically no function gray verification, the more functions pile up, maintenance is more and more difficult.

Demand people think that their ideas are perfect and can effectively increase the value of the product, and they are more concerned with their requirements, not the product.

There is no project manager, only the project leader, and the project leader is not focused and professional.

Since the company’s projects are in the form of weak matrix, the projects are more collaborative, and the project leader is more likely to play a role of teamwork. As the project leader often holds multiple positions, he or she cannot effectively and continuously invest in optimizing the project process.

And so on…

2. Small steps to success

Of course, we have a lot of problems in the transformation, and there is still a lot of room for optimization, but compared with the past, we have made a lot of progress. The following methods have obvious practical significance in the process of actual project development, and are not excluded by the traditional organizational structure:

2.1. Cross-functional teams

For traditional enterprises, departments are generally divided according to functional attributes, and all departments cooperate to complete projects. However, the cost of cross-departmental collaboration is obviously too high, and when the product requires frequent cross-departmental collaboration, such a model is obviously not competent. At this point, the company is bound to expose the development inefficiency caused by such defects. At this point, it is logical to establish a virtual cross-functional team dominated by the business division or core department. Cross-functional teams can effectively solve the problem of frequent collaboration and communication during product development. In such teams, the actual developers, testers, and requirements people communicate directly with each other, with a higher frequency, less distortion of information, and less bickering between departments.

2.2. Daily morning meetings

The morning meeting is a standard activity for cross-functional team communication. It is held at a fixed place and at a fixed time for about 10 minutes every day. It is a very effective team synchronization mechanism. While the morning meeting looks simple, it is not so easy to hold well. The recommendation morning meeting in Agile mainly includes the following three aspects.

  • What did you do yesterday?
  • What are you doing today?
  • What’s the problem?

As agile people, we started out with scripted morning meetings, but with standard models, we were never able to run such meetings. The following are some of the problems we encountered.

  • During the morning meeting, most of the information has little actual meaning to improve the progress of the project.
  • When a colleague describes what she did yesterday and what she will do today, most people don’t care.
  • Most of the engineers’ morning meetings are self-absorbed and don’t care if what they say is delivered effectively.
  • When promoting the morning meeting rotation organization, it was found that most people did not have the ability to effectively organize the morning meeting, which was not very good practice.
  • The morning meeting was very discrete, so we could not see the progress of the whole project.

2.2.1. How to have a good morning meeting

As the Agile Manifesto says, “individual interactions trump processes and tools.” In the morning meeting, the progress of the current project should be made transparent to the whole team, and team members should be encouraged to timely and actively solve problems based on their current situation through communication. How to achieve rapid and effective communication? I think the following points need to be done:

  • Team members have a clear idea of the project’s goals and current status.
  • The tasks in the project have clear priorities, with clear accountability and current progress information.
  • Morning meetings have clear rules and everyone knows what to do and when.
  • Everyone who attends the morning meeting can easily follow the progress of his or her associates.

Want to accomplish these, of course little not a reasonable look board wall. It is the core carrier of the whole morning meeting. During the morning meeting, all project members discuss and update the information of the blackboard wall based on it.

2.3. See the wall

It seems that the board wall is just a simple Posting of the information to be displayed in the project to a version, but if the Posting is not reasonable, the whole morning meeting will be in a mess, the idea is scattered, and ultimately lead to the failure of the morning meeting. Next, I’ll talk about the evolution of our kanban.

In the beginning, we used a viewboard wall like the one in the picture above, on which only user stories were written. At the morning meeting every day, everyone gathered in a circle and told what they had done yesterday, what they had done today and what problems they had. When a user story changes state, it moves to the corresponding column.

Gradually the problem came to light, and we found that there were a lot of cards on the kanban wall, and it got bigger and bigger, because we always wanted to do more user stories, and whenever a user story got stuck in development, we would start a new user story, and we couldn’t accept someone being “idle.” On the other

Because everyone speak, and not with the card directly, cause we can’t speak very good information and see the wall, so that the wall has become a background, not have much practical significance, we begin to question, take turns to speak problem is not reasonable, shift the one host, one by one according to the board on the wall of the information, In order to realize the rotation of hosting, we regularly change different people to inquire and discuss, but sometimes some people do not know how to host effectively, resulting in little effective communication after the morning meeting. Due to the limited amount of information recorded on kanban cards and the large number of cards, it is difficult for the project leader, let alone the rest of the team, to keep a clear picture of the current progress of the project. So we changed the kanban to look like this:

In this way, it looks a little clearer than the previous kanban, and can clearly understand the current tasks of vision, software and testing. Unfortunately, there is still the problem of constantly pushing back user stories, resulting in too much work in process of Kanban.

In addition, some user stories are too large and stay in a certain location for a long time, and we cannot clearly understand the current progress of the user story.

Here attached the way, someone will always feed the demand of smaller particle size split, split the a user story to 1 to 3 days of work, it’s a pity that we haven’t been implemented, or we just put a big user story split into several small user story, but in our this agile turn team has not completely, We prefer a complete delivery of requirements. Because only in this way can our black box test be effectively tested, otherwise it will make the test repeat test, waste test resources, and the front-end demand will feel bad for a demand that is not in the release state.

In order to effectively follow up the progress of the larger user story, we begin the task, we set a task granularity can’t more than three days of work, we tend to repeat the task team members are taking to the granularity of the workload is less than a day, because it is good for our daily morning meeting for follow up, so the kanban card is divided into two categories, The following kanban appears.

We divided the cards on the kanban into user stories and tasks corresponding to the user stories, and when all the tasks related to the user stories were completed, the user stories were moved to be published. User stories are linked to tasks using numbers, which makes our morning meetings more specific to discuss, rather than just report back, and makes the progress of the project clearer than ever.

However, the problem still exists. When there are too many task cards, it is relatively difficult to find the corresponding relationship between task and user story, and the progress of user story cannot be understood at a glance. Similarly, such kanban will still have a large influx of front-end demand to the back-end, resulting in the backend overload and efficiency reduction. Thanks to lean’s limited-work in process concept, and combined with our previous experience, we ended up using the following type of plywood wall.

In this viewboard, there is only the user story card, and the user story card has broken up the different tasks of the user story. We no longer want multiple domains to work on the same user story in parallel, but after one domain is finished, it flows to the next domain. On the surface, it seems more efficient to carry out the work in parallel, but in this way, the information in various fields is not consistent, resulting in more rework, which leads to low efficiency. Since the quest and story are on the same card, we can see the current state of the user story at a glance from the kanban.

In addition, we divided the cards into three colors, corresponding to three priorities, so that people can be more autonomous when they receive tasks. It is also very important that we set wIP limits for each area based on the number of people in each area, currently limiting one person to no more than two projects at a time. We went from a push mode to a pull mode. In this way, the resource matching situation of domain boundary can be clearly exposed, and the related domain can be protected from the confusion caused by too many tasks, which leads to the decrease of efficiency. We go from the need to do more to “stop starting and focus on getting done.”

No more than two simultaneous work items for one person is not a standard answer, and we don’t fully follow that standard internally. For areas where there is little blocking, one may also be an appropriate choice.

2.4. Version Planning

Our products cover five technical fields including iOS application, Android application, watch terminal, server and H5. In the early days, we suffered from the interdependence of various areas, and a bug in one area was not fixed in time, resulting in a delay in the overall release, which happened quite often.

Therefore, we adopted the concept of version train, with release as the priority and functionality as the secondary. That is, it must be released at a fixed time, and if the corresponding feature does not meet the release requirements, it will be postponed to the next release. This led to a couple of nagging problems. Our release didn’t have a clear theme, just a bunch of completed requirements, resulting in a lack of highlights for each release.

In addition, because there was no planned release, there was no way to give the front end a clear psychological expectation of when their requirements would be released, and they didn’t know what requirements our next release would carry. In terms of development, there is also a lack of a clear sense of purpose and a sense that I will do what is needed. So, we finally gave up version train and changed to version planning for the whole product research and development.

Version planning, the most headache problem is to select which requirements into the version for development. Keep in mind that there will always be requirements, and the total amount will always be greater than what you can accomplish with your current version. Therefore, it is a question of requirements gathering and filtering. If there are so many requirements to filter for each release, it can take a large group of people a lot of time to discuss requirements priorities and whether the requirement is being done in that release. In addition, the discussion results are not very effective in such a short time. In Kanban In Action, there is a practice for “priority filters” as follows:

On this kanban, it identifies a team’s capacity and requirements for what to do next. When a requirement is removed, it triggers the entry and discussion of subsequent requirements, so that only a few requirements need to be discussed at a time, and more focused. While this is a good practice, our current team is not comfortable with it because we don’t really do pull development in Lean. Therefore, we adopted the following scheme in version planning:

  • Start collecting requirements two weeks before the next release.
  • A version must have a clear theme.
  • Versions have specific time nodes.
  • Requirements should be clearly defined, should be, can be three priorities, the proportion should be moderate.
  • Release time is delayed when required requirements are not met.
  • The required requirements should ensure a delivery rate of at least 80%.
  • If possible, ensure at least 50% delivery rate.
  • After the requirements are collected, several version planning meetings are held.

It is important to have multiple release planning meetings, because the volume of requirements gathered and the large number of people attending make it difficult to reach a consensus at once. When a meeting is over, give the whole team some offline time to think more and learn more additional information for further evaluation. We usually have two or three of these meetings, one to two hours each, and it’s a process of convergence and agreement.

3. In the future

Our project process still has a lot to be optimized. So far, we can only say that the progress of the project has been orderly. In the coming days, we will need to strengthen our project metrics. Do, do not feel how much planning version of the content, do not feel the project is good or bad. By measuring data, problems in the project are more objectively and clearly exposed.

4. Recommendation book list

For myself, after an agile consulting session organized by my company, I stepped on the road to the department’s agile transformation. During the period, I stepped on numerous holes, thanks to the following books to pull me out of one hole after another. Recommended book list, part of the books have not read, most of the books after reading one or two times is not the way, but also need to read and combat repeatedly, here is embarrassed to write their own feelings and evaluation of these books, so as not to mislead everyone. However, these books are in my transformation of the truth, give me a lot of inspiration and help books, I believe that people who read these books can gain something.

  • Agile Software Development in action – Estimating and Planning
  • Agile Software Testing
  • Lean Startup
  • Lean Startup Practice
  • Kanban Method
  • Kanban In Action
  • One Thousand and One Nights
  • The Myth of the Man-month
  • 4 Steps to Starting a Business
  • “The goal”
  • The Effective Manager
  • Deadline
  • Thinking, Fast and Slow

 

Everyone is a product manager. Reprint without permission is prohibited.