Agile Practice for Small and Medium-sized Projects II (About Spirit Short Plan)

**The development method is a systematic project that requires the cooperation of all project activities. **

This experience is based on the practice summary of two small and medium-sized projects (one 2000 Manday, one 1500 Manday) in the past two years, and I hope to discuss and make progress with you.

- Use the Spirit method to segment the plan
- Do not easily modify the executing Spirit plan (project summary)
- The reasonable period of each Spirit is 3-4 weeks
- Each Spirit defines a goal other than a specific task, such as: Zero Bugs, elimination of overtime, etc.
- Maintain a steady, reasonable work rhythm to get the team into a "flow" state (bulldozer feel)
- Track Spirit status with Burn Down Chart (not practiced)
- Whiteboard (practice interrupted)
- Set progress alerts, For example, a 30% delay (not practiced) "Disaster Rescue Brings Software Projects Back on Track" P25


Spirit Short Plan is

agile, requiring the project team to actively embrace changes. In real projects, the only constant is change. Therefore, the big plan prepared at the beginning of the project is likely to be very different from the actual situation in two or three months. So, instead of preparing a useless plan for two or three months, it is better to make a rough project plan. Only make detailed plans for the next month or two at a time. We can call it the Spirit Short Plan. Each project consists of a number of Spirit Short Plans. until development is complete.

Short plans are not just defined for reasons of embracing change. From a goal setting perspective, one should always define goals that are within reach on tiptoe , Let the team enjoy the joy of success within three or four weeks, and enjoy the joy of success again in the next three or four weeks. Stimulated by the success of the success, the morale of the team will be surprisingly high. From the perspective of risk control, the end of each Spirit is a Check Point . If an abnormal state occurs, such as overdue, measures should be taken in time to prevent the abnormal state from continuing from one stage to another. That is to say, the abnormal state should be controlled within a specific time range as much as possible, so as to ensure the normal progress of other stages. This is consistent with the principle of closure in programming.

To put it bluntly, when a team member cannot complete the established Spirit goals due to personal reasons, he needs to work overtime to complete his part, which is his responsibility. Of course, if the team members put forward a reasonable explanation to prove that the delay is not caused by personal reasons, the project manager needs to consider whether to agree to allocate this part of the task to the next Spirit. Need to be on a case-by-case basis, not rudely asking for overtime.

In fact, if the team is running well, every team member will complete the project conscientiously, overtime is to become active, and overtime has changed from drudgery to a pursuit. The reason why I say this is because there have been many cases in our team where programmers take the initiative to stay overnight and work overtime on weekends, and I only learned about it later from other colleagues. To have such a team member, what more can I ask for?

Project managers in agile are responsible for maintaining the stability of the current Spirit , for example, not arbitrarily modifying an ongoing Spirit plan. Do not arbitrarily add new quests to an ongoing Spirit. If it is necessary, some tasks that interfere with the workload of the new task should be removed from the current Spirit.

We've had this happen on a project before.

Day 1: The business people ask the development team to change the system from A to B.
Day 2: The business people ask the development team to change the system from A to C.
Day 3: The business person informs the development team that the change is canceled!

Therefore, it has strengthened our confidence in tough change control. It should be reminded that change control is not the same as resisting change , and a suitable scale needs to be grasped.

When the project team successfully completes two Spirits, a Group Flow is formed . Group Flow refers to the state where the entire team as a whole enters the flow state.

Flow , as defined by the psychologist Mihaly, refers to a feeling of fully devoting one's mind to an activity. When the flow occurs, there is a high level of excitement and fulfillment. Different from Group Flow, Flow is a personal state.

When the team works well, it will reflect some characteristics of self-organization, such as proactively requesting tasks, proactively communicating with the team, proactively improving, and so on. These will be discussed in detail in the team section below.

Of course, in addition to fulfilling user needs, doing projects must also have some other goals in the boring coding life, or have some fun. At this point, we can set a brief goal for each Spirit, such as achieving communism, eliminating overtime, etc.