CODING Project Collaboration recently launched “Classic Project Management” to support traditional project management. CODING now fully supports agile project management as well as traditional project management. So the question is, how do I choose between classic project management and Agile project management? This paper will provide reference for selection from the perspectives of concept differences, common RESEARCH and development models, applicable scenarios and practical applications.
Value concept
Let’s start by looking at the differences in terms of ideas. The iron triangle of project management revolves around scope, cost, and time. Traditional project management is characterized by a strong plan-driven approach, where people and time can be allocated only after the scope of requirements is fixed, and risks are actively tracked and controlled during the project process. Agile projects are value driven. In Agile project management, cost and time are fixed first, requirements are frequently refined during delivery, and high-value requirements are delivered in a fixed time box.
Behind traditional and agile project management lies the philosophical difference between pre-defined and experimental processes. Predefined processes focus more on planning and controlling change. The experimental process is more open to change, getting feedback through rapid practice and then adjusting forward. PMBOOK categorizes the development life cycle of a project as predictable (plan-driven), adaptive (agile), iterative, incremental, or hybrid.
A project may have one or more of these phases, and different teams within an enterprise may use one or more project management models. For example, for enterprise core systems, outsourcing projects and projects with strong delivery nature, traditional project management will be carried out. These systems either require little change in requirements or require detailed project plans and business commitments. For Internet products, demand and users are often volatile, and an agile model can get market feedback faster, which is not and is not suitable for long-term detailed planning.
Research and development model
With the concept differences in mind, let’s take a look at common development models. Waterfall is the most common model in traditional project management, and Scrum is the most common model in agile project management.
The waterfall model
The waterfall model is widely believed to have been developed by Winston Royce in 1970. The core idea of waterfall model is to simplify the problem according to the process, and separate the realization and design of functions, so as to facilitate collaboration. The waterfall model divides the software life cycle into six basic activities, including plan making, requirement analysis, software design, program writing, software testing and operation and maintenance, and defines their fixed order from top to bottom, which is like the waterfall water falling down step by step.
In addition, the waterfall model places great emphasis on documentation. The output of the previous stage is the input of the next stage, and the document is the only information connecting the stages. From a waterfall perspective, with inadequate design and documentation, if team members leave before the project is completed, knowledge is lost and the project may struggle to recover from the loss. New team members and even new teams should be able to take over the project by reading the design document if it is available.
When Royce first came up with the model, it wasn’t to prop up the falls. On the contrary, he points out that the waterfall model can be risky because it is worthless for projects with constantly changing requirements.
The waterfall model provides a structured and easily understood linear process of stages. It also provides easily identifiable milestones during development. For this reason, the waterfall model is used as a starting example for developing models in many software engineering textbooks and courses. Up to now, it is still one of the important development models used by software development enterprises. Waterfall model can be applied to projects with fixed requirements and scope, solid product itself, and easy to understand technology.
What Royce really came up with was a modified waterfall model. He put prototyping on the same level as waterfall, and it was like an iteration in agile, an iteration to validate the project’s executability and reduce risk. Let’s take a look at how the idea of iteration is deeply used in Scrum.
The Scrum framework
Scrum is a framework for solving complex and changing problems. Based on empirical and lean thinking, an iterative and incremental approach is adopted to optimize future predictability and control risk, helping teams and organizations create value.
In 1986 Hirotaka Takeuchi and Ikujiro Nonaka outlined a new holistic approach that they likened to rugby, with a cross-functional team completing the process at different stages and the team “moving the ball around as a unit”. This method can improve the speed and flexibility of commercial new product development.
This analogy has been used and evolved over the years, culminating in a 1995 paper by Jeff Sutherland and Ken Schwab at OOPSLA ’95, an annual ACM conference in Austin that first proposed the concept of Scrum. The two worked together over the next few years, combining ideas with experience and industry best practices to form what we now know as Scrum. In 2020, the duo released the latest edition of the Scrum Agile Guide, which can be found in the accompanying reading.
The Sprint is the heart of Scrum, where ideas are turned into value. They are fixed-duration events lasting from 1 to 4 weeks. A new Sprint begins immediately after the end of the previous Sprint. All of the work required to achieve the product goals takes place within the Sprint, including Sprint planning meetings, daily station meetings, Sprint review meetings, and Sprint retrospectives.
The vitality of Scrum lies in the small, quick steps it provides in the face of a changing market. The production team “gets their hands dirty” to get quick feedback on the product and improve it. In order to maintain a tight iteration pace, the Scrum framework requires “transparency” of information and processes in the project management process. Transparency makes inspection possible, and frequent “inspections” can quickly uncover problems in a project. Inspection makes it possible to adapt quickly to problems found. Scrum practices empower organizations to respond to change.
Practical application
We do not think that traditional project management model and agile project management model are mutually exclusive, they have their own characteristics and applicable scenarios, and both projects have digital appeal. In addition to agile management mode, CODING project collaboration recently launched a classical management mode. You can use waterfall development based on CODING practices, incremental development, Scrum framework, and more. We hope to be able to provide more organizations with more teams, diversified project management solutions, rather than one hammer to hit all the nails.
The following figure lists the workflow comparison between agile project management mode and classical project management mode in CODING project collaboration:
CODING’s recent launch of Classic Project Management aims to solve the five challenges of traditional project management:
- Unified and coordinated, information of different stages and functions is summarized on the same platform;
- Global view, summary of project progress in the planning page, real-time grasp of the progress and situation of multiple iterations;
- Project progress, plan, iteration overview and other pages to track progress, process transparent, progress controllable;
- Resource management, plan page can view member tasks, assignments and coordinators at any time;
- Quality control, tracking test progress and defect repair progress through test management, defect management, etc.
In addition to the above capabilities, the coding-based file Web disk and Wiki knowledge base enable the team to easily manage documents in the traditional project management process, which can be accessed and shared directly through the Web at any time, and the historical version of files can be traced back at any time. In addition, you can reference related documents to save time and worry.
The classic project management model can be used in a very flexible way. The following two examples can be used to practice the big waterfall and the small Waterfall:
Great falls
Define a project as a software development project with a start and end time. Use iterations to divide the project into six phases: planning, requirements analysis, software design, coding, software testing, and operational maintenance. Do it in chronological order. The output documents (requirements documents, design documents, test documents, etc.) after each stage are completed can be recorded into the file disk and Wiki. Completion of the last iteration indicates completion of the project.
cascade
In the waterfall usage scenario, each requirement has six states: defined, designed, implemented, tested, run, and maintained. Set up the required workflow, only adjacency state can flow, not jump. Corresponding to these six states, the requirements are decomposed into six phases of tasks. After the tasks in each phase are completed, the requirements move to the next state.
Take “User Management” in the following figure as an example. At present, the tasks related to requirement analysis and design have all been completed, and coding and implementation tasks are being processed. The tasks related to testing, operation and maintenance in subsequent stages have not yet started.
In addition to the above two approaches, teams can practice more collaborative approaches under the classic project management model.
Team to evaluate
After having a basic understanding of concepts, models and application practices, at the end of the article, we provide a concise assessment to recommend the matching between Agile and classic project management patterns. You can check the boxes in your head based on the current situation of the team for rough reference.
1 Stability of demand
0 for stable demand — 10 for unstable demand
2 Service and IT interaction
Business and IT interaction difficulty high score 0 – Business and IT interaction difficulty low score 10
3 Project Impact
The correlation degree of critical systems is 0 points higher — the correlation degree of critical systems is 10 points lower
4 System modularity
0 points for low system modularity — 10 points for high system modularity
5 Environmental openness
Low environmental openness 0 points — High environmental openness 10 points
A score of 0 to 20 is more recommended for classic mode and a score of 30 to 50 is more recommended for Agile mode
Experience classic project management
References:
- Jim Highsmith. “Agile Project Management”
- Project Management Institute. PMBOK Guide (6th edition)
- 2. The Way to Be Agile and Tidy by Robert C. Martin
- zh-chs.scrumguides.guru/
- En.wikipedia.org/wiki/Winsto…
- Zh.wikipedia.org/wiki/Scrum#…