preface
The story of our Agile practices and the technical transformation aspects has been covered in my other questions on the Agile Road, but in this article I want to introduce the various technology-independent approaches that teams have taken to transition to Agile.
background
I’ve always found it a waste of time to talk about agile methodologies outside of the context of the application, so let’s give a brief overview of our team and project. The project is a legacy system that needs a lot of updates and optimizations and is two months away from commissioning. The team is broke and mostly new. 2 years experience at most, zero testing experience, and more importantly, no clear requirements from users.
Agile methods
Time box
The next milestone of the project is trial operation. Since the trial operation time is very short, less than two months, we chose the iterative time box, i.e. the iteration cycle, as one week. After eight sprints of hard work, the system was finally ready for commissioning. However, having worked overtime almost every sprint for the last two months, it was clear that the one-week iteration cycle was not appropriate for a team that was new to Agile. After two months of weekly spirnt development, team members were generally stressed and out of shape. After the completion of the trial run node, the team was deeply encouraged. In order to ensure the team’s continuous fighting strength and the project had no clear node requirements, we adjusted the time box to two weeks in the following iteration development. The status of team members has been improved. After discussion, we confirmed that the time box of two weeks is appropriate, and the time box will be two weeks without special circumstances.
Task board
The first utility we found in Agile was the task board. Through the task board, everyone in the team can be aware of the work of others in the team, and the progress of the project can be intuitively understood with burndown chart and accumulation chart.
Our task board started out as a normal whiteboard, divided into three columns: Todo,Doing and Done, followed by multiple lines, each for a team member.
Later, we continuously improved the task board over time, forming the appearance as shown in the figure below.
Task board
Added: 1. Improvement task area, which displays the improvement items resulting from the review; 2. Personal temporary area for members to place tasks completed in real time; 3. Rush channel, used for special emergency temporary tasks. 4. MVP area, which is used to place the most priority task selected for each cycle, which is usually TDD or pair transformation to do 5. Chart area: hand-drawn charts including burnout chart, rate chart and cumulative chart are used to show project progress.
Daily station will
Another simple and useful tool we’ve found in Agile is the daily stand. We usually do this in front of a whiteboard and answer three questions every day:
- What did you do yesterday?
- What are you doing today?
- What’s the difficulty?
It is necessary to say something about the answers to these three questions. First of all, do not let the daily station become a report meeting of team members to you alone. The purpose of the station meeting is more effective communication rather than report. Finally, be sure that every team member should attend without exception. Punishment measures such as giving red envelopes, inviting everyone to drink or sweeping the floor can be set up.
Planning meeting
Planning meetings are the first big thing the team does in each iteration cycle, with PO giving user stories and priorities, the team doing task breakdowns and assessments, and discussing business details with PO or BA. Consider using a planning poker format. It is important to note that all members of the team attend the planning meeting together. Clarifying needs and priorities is the first priority. This planning meeting can be time-consuming in the beginning, and SM needs to bring attention to the timing and scope of the discussion. Points to note:
- Planning meetings are the main way agile teams capture requirements and involve the entire team;
- Get the team consistent on the granularity of the size of the assessment task;
- PO and core testers must not be absent. In case of absence, they need to find a designated person to attend for them and ensure that the designated person can meet their standards.
Review meeting
Retrospectives are the last big thing the team does in each iteration cycle, led by SM, to determine what the team did well, what it did badly and, more importantly, what needs to be improved. Some things to note about retrospective meetings: 1. The development team must attend 2. Don’t let the meeting become a self-evaluation meeting. It’s a team approach, not an individual one. It is not appropriate for the leader of the organization to be the first to speak, otherwise team members may agree. Improvement items are determined by the team rather than assigned by the leader
Other related
Test-driven development
Test-driven development (TDD) has been tried before and failed for the simple reason that people are not at the level required by TDD, so there is no more deliberate requirement. Here are some lessons about TDD. 1. TDD has high requirements for developers, mainly reflected in design ability, development ability, unit testing ability and self-discipline ability. 2. TDD is not suitable everywhere. 3. Don’t focus solely on testing coverage.
Pair programming
Extreme programming was first adopted by Kent Beck, the master of Smalltalk at that time, in 1996 when he was hired to lead the development of C3(Chrysler Comprehensive Compensation), a Comprehensive salary project of Chrysler. This software development approach was formally proposed in the book Parsing Extreme Programming, published in October 1999. We tried pair programming, but it didn’t go anywhere. I think the ability and culture didn’t meet the requirements of pair programming and the project wasn’t very suitable for pair programming. There is also some experience with pair programming. 1. Respect and understand; 2. Adjust the pair constantly; 3. 5. Not all projects are suitable for pairing
Code review
Code review is an effective way to improve team performance. It usually involves sitting down to review everyone’s code before leaving work. Be careful not to schedule it too tightly so that everyone is not in the mood to review, but to ask what to eat and so on. Also pay attention to review things not people, find the situation is not right immediately intervene.
conclusion
The form of agile discussed in this paper, and the decision whether an organization can adopt agile to improve its efficiency is whether it can accept the agile idea of continuous improvement and full responsibility. We must pay attention to not ignore the introduction of agile culture in the team, otherwise the agile transformation is only formal, and the result is generally failure in the transformation. The best way is the one that suits you.