As Choerodon continues to iterate, it has been used by more and more users for project management and development as part of the development team.
During this process, many users asked the team questions about agile management, or wanted to know how the Toothfish Agile team managed the project.
Today, I’m going to talk about this, and the following is something that should be read carefully by any project or product manager using Agile management.
This article will take the agile management sub-product team as an example, narrated by the product leader of Agile Management personally, hoping to provide some reference and help for everyone, so as to improve team collaboration, enhance team delivery value and development efficiency.
team
Toothfish is designed to help teams carry out agile application delivery and automated operation management. It is composed of agile, test, CI/CD, development pipeline, knowledge management and other sub-products. In addition to each sub-product team, there is also a basic service team such as architecture team. Each team consists of 6-10 people, depending on the development workload.
The Agile management team has been around 8-10 people since its inception and currently has 6 developers (2 front end, 4 back end), 1 product owner (PO), and 1 UI designer, all working full-time on the project with little cross-team involvement.
Pace of development
All the teams of the entire tootfish product kept on the same development pace, 2 weeks per iteration, 2 iterations plus 1 week of continuous improvement, so that the rate of 5 weeks per release steadily moved forward.
One might ask: why 2 weeks instead of 1 week? After long-term verification by the team, some relatively complex requirements can be developed in 2 weeks, and the test acceptance can be completed.
Of course, there is no accurate standard to say that 1 week or 2 weeks is better, which can be adjusted continuously through the running-in of the team.
perform
The team is formed and the pace of development is agreed upon. So what does each iteration have to do? What comes first and what comes second? Who is going to do? These questions are addressed by agile management sub-product teams as follows:
Before the new iteration begins
As mentioned in the previous article, there are many meetings involved in SCRUM development, and there is an important meeting, the Iteration Planning meeting, to discuss and explain the development of the next iteration before the actual development of an iteration begins.
Agile management teams gather the team together on the first morning of each iteration, find a quiet place, and sit down for a 2-3 hour planning meeting.
At the meeting, the to-do list for the next iteration will be opened, and PO will describe these user stories to the development team in combination with the UI interface confirmed before. In the process, according to the function description of PO, team members raised their own questions and reached consensus through mutual feedback and communication. Finally, assign a lead person to each user story and estimate the story, counting the workload of the front and back end to come up with a story point. That concludes the story and moves on to the discussion of the next story.
You might ask, does the planned user story have to be completed in this iteration? What if you can’t finish it? Does that happen to you?
Sure, agile teams handle it like this:
After all the stories were discussed, the assessment found that 100 story points (half a day =1 point) were needed, which was higher than the previous iteration rate (80 story points). At this point, all the problems are prioritized, and PO will remove the story with the lowest priority or several stories (the total number of story points is about 10) from the unopened iteration list. Now that the team has 10 story points planned that are greater than the iteration rate, PO may discuss with the development team whether they can try to complete 90 story points in this iteration, and if they agree, the iteration rate will change from 80 to 90.
There is, of course, a conservative approach: continue to reduce the number of stories at the bottom. However, as a rule of thumb, the reduced story should be relatively independent and not dependent on, or very dependent on, other stories in the iteration.
After the stories are evaluated, the lead development person will be assigned to the person who handles each story. After the meeting, the person in charge will lead the developers involved in the story to split the story together, and create the split task under the corresponding story with sub-task problem type.
Then the sprint begins to officially enter the development phase of the iteration.
System tools: Agile management to-do module, Sketch (UI prototyping)
iteration
During the development phase of the team, everyone works on the priorities of the tasks they were given. During this period, it is necessary to timely communicate with THE PO or even directly communicate with the users who put forward the requirements for the uncertain functions.
There is another meeting in the SCRUM process that everyone is familiar with: the Daily Stand-up meeting. During the development phase, the Agile management team would hold a 10-15 minute stand-up meeting each morning, where they would just throw out the issues, not make a decision on the complex issues, and then the developers and THE PO would discuss and make a decision.
The system tool is the active sprint module of toothfish Agile management
So in an iteration, the developer writes the code, and what do the other members do?
▌ Job 1: Organize the content for the next iteration
The PO breaks down the requirements for the next iteration and describes them as user stories, which are created in the backlog. At this point, PO and UI will start to discuss these stories, PO describes the functionality that the story is intended to achieve, and UI will issue a hi-fi prototype as soon as possible based on the functionality description. (In the initial iteration of the product, PO also issues a simple prototype, and after user confirmation, UI will issue a high-fidelity prototype. With the continuous evolution of iteration, PO drawing is gradually weakened, and more attention is paid to communication, confirmation and product experience.)
During this process, there are some uncertain issues that are communicated to developers familiar with the functional module in a timely manner, such as executability, whether there are preconditions, etc. These issues do not take too much time for developers, who are still focused on the tasks of the current iteration. Once the basic functional design is established, the UI can work graphically.
After UI design is completed, communicate and adjust with PO first, and then invite tootfish product manager or user to participate in the confirmation of the final scheme. After the meeting, PO and UI will work together to optimize and adjust the feedback, and then associate these prototype drawings with relevant stories, so that subsequent developers can view them in a targeted way. On the other hand, it is also a kind of archive.
▌ Job 2: Writing test cases
Once the functionality is confirmed, the tester or PO needs to start writing test cases for each function point of the iteration. For example, all the functions of this iteration are released in version 1.0. PO can find the use cases of version 0.9 in the test management of tootfish, clone them to version 1.0, and create new use cases under 1.0 for the new functions. For the changed functions, find the previous use cases and modify them on this basis. Finally, proceed with the test plan and assign testers.
System tool: Test management of toothfish
▌ Job 3: Test the story
In the team’s own active Sprint Kanban, there is a list of “validation tests.” The team reached a consensus that by the time the cards flowed into this column, development had been completed and the tests had passed by default, and the PO and UI could now be tested against the story in many ways, functional and stylised. Once a problem is found, if identified as a bug by the developer, the associated subtask is called back to the developer, and the defect is created, which is then associated with the story or subtask.
So developers are doing bug fixes as well as feature development in iterations. Only when the bug is verified is the story considered complete and dragged to the completed column of the kanban board.
Work done by all team members in collaboration at the end of the iteration — full testing against test cases
As mentioned earlier, the rhythm of toothfish products is 2 weeks per iteration, 2 iterations per version. Usually in the first iteration, the team’s development tasks will be scheduled until Thursday of week 2, when PO will only do incremental testing and reserve one day for bug fixing. The second iteration is usually only planned for Wednesday of week 2, because the remaining 2 days are full testing and bug fixes for the entire Agile management team.
You might be asking, are developers involved in testing? The answer is: yes, and cross-testing.
The Piggfish test management, which allows bugs to be created at the step of each use case, can be directly associated with the current sprint, displayed on the kanban, at which point the relevant developers will stop their testing work and fix bugs first. After the repair, each was responsible for the regression test of their proposed bugs, and then made preparations before the launch.
In real development work, it’s not always ideal. For example, two days before launch, there are still development tasks to be completed, and they can’t be completed in a few hours. At this point, the DECISION PO needs to make is to give up the unfinished task and enter the test. Rather than delay the release, or shorten the testing time, or even develop features without testing. Because people are always following agile thinking, the product features delivered must be valuable and usable.
There are many other aspects of the agile management team’s daily project management process, such as reviews, retrospectives, technical seminars, technical sharing, forum needs assessment and response, communication and discussion with other teams, etc., to be shared later.
Toothfish agile teams may not be agile project management best practices, and each segment may not be appropriate for the entire project management life cycle of a team, much less for every team. But we need to be brave to try, after a period of runnin, through constant adjustment, I believe that we can always find the agile management method suitable for our team.
Hopefully this will be a reference for teams that are trying to make an Agile transition and still feeling their way through agile. I also hope that the agile management of toothfish can help everyone improve the team, enhance efficiency and deliver more value.
About the Choerodon toothfish
Choerodon is an open source enterprise services platform, based on Kubernetes’ container orchestration and management capabilities, integrating DevOps toolchains, microservices and mobile application frameworks to help enterprises achieve agile application delivery and automated operations management. It also provides IoT, payment, data, intelligent insights, enterprise application marketplace and other business components to help enterprises focus on their business and accelerate digital transformation.
You can also learn about the latest developments of toothfish, product features and participate in community contributions through the following community channels:
- Liverpoolfc.tv: choerodon. IO
- BBS: forum. Choerodon. IO
- Github：github.com/choerodon
- Choerodon Toothfish on wechat
- The Choerodon toothfish