Agile Thinking and Methodology for Managing Projects - Case 1
Why Agile Methods?
Background and pain points:
- With more than 100 ongoing projects per month, our company has a large number of projects.
- Mid-month planning is required for the next month's projects.
- At the beginning of each month, you need to analyze the actual status of the project for the previous month, including the schedule achievement rate, quality and cost pre-factual ratio.
- Project information is mainly managed through Excel, making it difficult to track changes and cumbersome to compile statistics. - Expansion of project scope occurs frequently.
- Monthly reports on the status of projects are required, and the workload of organizing the contents of the reports is high, which not only consumes a lot of man-hours, but is also prone to errors.
Solution:
We plan to develop a project management system into which we will enter project information and automate the generation of various reports.
On institutions:
Since this is an in-house project, it is not possible to form a dedicated team for design and development. The plan is to utilize members in between projects for part-time development, meaning that developers without a project budget can join the project management system development team at any time.
About the duration:
Although the system did not have an exact deadline as requested by the client, we wanted to develop an initial version as early as possible and refine the functionality over time as we used it, which is exactly what we did by adopting the Agile MVP (Minimum Viable Product) philosophy.
On the demand element:
We had a general idea of the basic requirements of the system and wanted to automate all aspects of project management to reduce manual intervention.
Our goals include the automatic generation of project reports in the future, which will be automatically sent to the relevant stakeholders. However, many details have yet to be refined, so we hope to develop our management system in a "snowball" fashion.
It is worth noting that there is no certainty as to how long part-time staff will be able to stay on the project. If there is a profitable project, our human resources may be drawn away immediately.
We held a 1-hour meeting to clarify member roles and decided to adopt an agile mindset for the project.
It is important to note that we are using Agile thinking rather than strictly following Agile methods. Therefore, we will manage the project flexibly based on Agile thinking, combining organizational capabilities, member capabilities, and project characteristics.
■ Defining roles
- Project sponsor: Head of Department
-Product Owner (PO, Product Owner): PMO member
- Agile Coach (Scrum Master, SM): part-time department head
- Development Team: 1 full-time SE + 4 SEs + 1 part-time architect
- Users: Heads of Departments, Responsible Persons of Teams, Project Managers (PMs), PMO members
■ Define product direction
1. I act as the project sponsor and share with the PO my product idea, pain points, and the vision I hope to realize.
Users were gathered based on the vision (department heads, responsible people in each team, PMs, PMO members) and a lot of fragmented requirements were collected. The vast majority of these requirements were valuable, but there were also some impractical requirements that did not need to be realized through the system.
■ Developing a Product Backlog
Organize and categorize the collected requirements into User Stories, both Epic and User Stories, and put these User Stories into a Product Backlog.
Gather project sponsors and users to explain the user stories in the product's to-do list.
The purpose is twofold: 1) to harmonize the perceptions of all parties;
2) Validate the feasibility of the project management system. Users may terminate the project at this stage if they do not see much difference from Excel.
■ Developing Sprint lengths
The Scrum Master discusses with the PO to define the goals and length of the Sprint. It is important to note that Agile thinking emphasizes involving team members as early as possible to increase team buy-in.
Although there are practices at this stage that are not fully in line with Agile principles, we are not calling in developers for the time being as team members have not yet been released from the project.
Eventually, we defined the length of each Sprint as two weeks, with releases every two weeks. After each release, the project sponsor and users worked together to try it out and provide comments and suggestions.
■ Architect appearance
Nonfunctional Requirements Sorting The part-time architect enters as the first official member of the development team.The PO introduces the architect to the background of the system and works with the architect to gather and organize information on the number of users, data volumes, etc.
The architects start working on the system design, and since the system architecture is relatively simple, there are no technical challenges to overcome, and there is already an existing infrastructure to work with, we give the architects 1 week to do the initial work, defined as Sprint0.
During this 1 week, the architect's tasks include:
1. Technology Selection: Spring Boot + Vue + PostgreSQL
2. Building the framework
3. Development of coding norms
4. Configuring continuous integration/continuous delivery (CI/CD)
■Develop Product Backlog for Sprint
The PO adds the user story to the Product To-Do List (Product Backlog) in Sprint1 based on the release guidelines (Product Roadmap).
Description:
is a list of requirements that acts as a requirements container containing multiple items, which can be Epic or User Story.
2. Any requirements and ideas can be used as user stories, which means that user stories can be undefined and do not have to be validated by reviews and discussions.
However, the user stories in the product to-do list are requirements that have been reviewed and validated by the team, and these can be developed in subsequent iterations.
▪ Admission of development members
The PO talks to development members about the product vision, the overall plan, the user stories in the product to-do list, and the user stories in Sprint1.
Also start listening to the suggestions and comments of the members, at this stage you can modify the user stories in the product's to-do list.
[Additional information]
Specific responsibilities of the Scrum Master in an Agile project include:
Facilitate teamwork:
Help the team understand and follow the Scrum framework, ensure smooth communication between team members, and assist in resolving conflicts and obstacles.
Ensure the implementation of agile practices:
Ensure that the team works according to the principles and practices of Scrum, including planning meetings, daily station meetings, review meetings, and retrospectives.
Assist the product owner:
Supports product owners in the management of product to-do lists, helping to clarify requirements and ensure that to-do lists are clearly prioritized.
Removal of obstacles:
Proactively identifies and resolves obstacles that the team encounters in their work to ensure that the team is able to move forward successfully.
Promoting self-organization:
Encourage team self-management and self-organization to increase team autonomy and responsibility.
Training and mentoring:
Provide training and mentoring to team members on Agile and Scrum to improve the team's Agile capabilities.
Communicate with stakeholders:
Act as a bridge between the team and external stakeholders to ensure information is transparent and shared.
Promote continuous improvement:
Continuously improve the workflow and efficiency of the team through review and feedback mechanisms.
Metrics team performance:
Help teams use metrics and data to evaluate the effectiveness of their work and drive data-driven decisions.
Promote a culture of agility:
Spread Agile thinking and culture throughout the organization and promote the widespread adoption of Agile practices.
The role of the Scrum Master is not limited to management, but more importantly to guide and support the team to work in a more efficient way.
Why Agile Methods?
Background and pain points:
- With more than 100 ongoing projects per month, our company has a large number of projects.
- Mid-month planning is required for the next month's projects.
- At the beginning of each month, you need to analyze the actual status of the project for the previous month, including the schedule achievement rate, quality and cost pre-factual ratio.
- Project information is mainly managed through Excel, making it difficult to track changes and cumbersome to compile statistics. - Expansion of project scope occurs frequently.
- Monthly reports on the status of projects are required, and the workload of organizing the contents of the reports is high, which not only consumes a lot of man-hours, but is also prone to errors.
Solution:
We plan to develop a project management system into which we will enter project information and automate the generation of various reports.
On institutions:
Since this is an in-house project, it is not possible to form a dedicated team for design and development. The plan is to utilize members in between projects for part-time development, meaning that developers without a project budget can join the project management system development team at any time.
About the duration:
Although the system did not have an exact deadline as requested by the client, we wanted to develop an initial version as early as possible and refine the functionality over time as we used it, which is exactly what we did by adopting the Agile MVP (Minimum Viable Product) philosophy.
On the demand element:
We had a general idea of the basic requirements of the system and wanted to automate all aspects of project management to reduce manual intervention.
Our goals include the automatic generation of project reports in the future, which will be automatically sent to the relevant stakeholders. However, many details have yet to be refined, so we hope to develop our management system in a "snowball" fashion.
It is worth noting that there is no certainty as to how long part-time staff will be able to stay on the project. If there is a profitable project, our human resources may be drawn away immediately.
We held a 1-hour meeting to clarify member roles and decided to adopt an agile mindset for the project.
It is important to note that we are using Agile thinking rather than strictly following Agile methods. Therefore, we will manage the project flexibly based on Agile thinking, combining organizational capabilities, member capabilities, and project characteristics.
■ Defining roles
- Project sponsor: Head of Department
-Product Owner (PO, Product Owner): PMO member
- Agile Coach (Scrum Master, SM): part-time department head
- Development Team: 1 full-time SE + 4 SEs + 1 part-time architect
- Users: Heads of Departments, Responsible Persons of Teams, Project Managers (PMs), PMO members
■ Define product direction
1. I act as the project sponsor and share with the PO my product idea, pain points, and the vision I hope to realize.
Users were gathered based on the vision (department heads, responsible people in each team, PMs, PMO members) and a lot of fragmented requirements were collected. The vast majority of these requirements were valuable, but there were also some impractical requirements that did not need to be realized through the system.
■ Developing a Product Backlog
Organize and categorize the collected requirements into User Stories, both Epic and User Stories, and put these User Stories into a Product Backlog.
Gather project sponsors and users to explain the user stories in the product's to-do list.
The purpose is twofold: 1) to harmonize the perceptions of all parties;
2) Validate the feasibility of the project management system. Users may terminate the project at this stage if they do not see much difference from Excel.
■ Developing Sprint lengths
The Scrum Master discusses with the PO to define the goals and length of the Sprint. It is important to note that Agile thinking emphasizes involving team members as early as possible to increase team buy-in.
Although there are practices at this stage that are not fully in line with Agile principles, we are not calling in developers for the time being as team members have not yet been released from the project.
Eventually, we defined the length of each Sprint as two weeks, with releases every two weeks. After each release, the project sponsor and users worked together to try it out and provide comments and suggestions.
■ Architect appearance
Nonfunctional Requirements Sorting The part-time architect enters as the first official member of the development team.The PO introduces the architect to the background of the system and works with the architect to gather and organize information on the number of users, data volumes, etc.
The architects start working on the system design, and since the system architecture is relatively simple, there are no technical challenges to overcome, and there is already an existing infrastructure to work with, we give the architects 1 week to do the initial work, defined as Sprint0.
During this 1 week, the architect's tasks include:
1. Technology Selection: Spring Boot + Vue + PostgreSQL
2. Building the framework
3. Development of coding norms
4. Configuring continuous integration/continuous delivery (CI/CD)
■Develop Product Backlog for Sprint
The PO adds the user story to the Product To-Do List (Product Backlog) in Sprint1 based on the release guidelines (Product Roadmap).
Description:
is a list of requirements that acts as a requirements container containing multiple items, which can be Epic or User Story.
2. Any requirements and ideas can be used as user stories, which means that user stories can be undefined and do not have to be validated by reviews and discussions.
However, the user stories in the product to-do list are requirements that have been reviewed and validated by the team, and these can be developed in subsequent iterations.
▪ Admission of development members
The PO talks to development members about the product vision, the overall plan, the user stories in the product to-do list, and the user stories in Sprint1.
Also start listening to the suggestions and comments of the members, at this stage you can modify the user stories in the product's to-do list.
[Additional information]
Specific responsibilities of the Scrum Master in an Agile project include:
Facilitate teamwork:
Help the team understand and follow the Scrum framework, ensure smooth communication between team members, and assist in resolving conflicts and obstacles.
Ensure the implementation of agile practices:
Ensure that the team works according to the principles and practices of Scrum, including planning meetings, daily station meetings, review meetings, and retrospectives.
Assist the product owner:
Supports product owners in the management of product to-do lists, helping to clarify requirements and ensure that to-do lists are clearly prioritized.
Removal of obstacles:
Proactively identifies and resolves obstacles that the team encounters in their work to ensure that the team is able to move forward successfully.
Promoting self-organization:
Encourage team self-management and self-organization to increase team autonomy and responsibility.
Training and mentoring:
Provide training and mentoring to team members on Agile and Scrum to improve the team's Agile capabilities.
Communicate with stakeholders:
Act as a bridge between the team and external stakeholders to ensure information is transparent and shared.
Promote continuous improvement:
Continuously improve the workflow and efficiency of the team through review and feedback mechanisms.
Metrics team performance:
Help teams use metrics and data to evaluate the effectiveness of their work and drive data-driven decisions.
Promote a culture of agility:
Spread Agile thinking and culture throughout the organization and promote the widespread adoption of Agile practices.
The role of the Scrum Master is not limited to management, but more importantly to guide and support the team to work in a more efficient way.