Hello everyone. Last time, we extracted the tasks that should be added as “Project Management” by mapping PMBOK, which should be understood by problem solvers, with they way of proceeding general problem solving (as-is ~ to-be) and Lean Six Sigma.
This time, I would like to write about the relatively new (although it has been around for over 20 years) “Agile” method in project management.
1. What is “Agile”?
As for “agile”, I think we hear more and more about it these days. Originally it was a project management method for system development, but recently, it seems that the awareness has been increasing as it can also be used for non-system projects!
The word “Agile” itself means “Quick, Prompt, etc”, so I think that it is often misunderstood as a method that “can advance projects quickly”.
I would like to explain later, but Agile means that by reducing “rework” in requirements definition, the total project period can be shortened (in some cases) as a result. As for whether the speed of the project will increase dramatically, unfortunately (laugh) it is better to understand that “that is not the case”.
There are many schools/styles in Agile.
Among these, “Scrum” is the most standard way, so I would like to use Scrum as an example below.
A concept that has traditionally existed in contrast to Agile is the “Waterfall”. In terms of system development, it is a familiar flow of “Requirement definition” -> “Design” -> “Development” -> “Test” -> “Deployment”. Now, let’s compare Waterfall and Agile (Scrum).
2. How to proceed with “Agile”
Let’s take a look at how Agile actually works, again in contrast to Waterfall.
The unique character is that “Iteration” is repeated multiple times, and the Iteration is called “Sprint”. Within each sprint, the cycle of “Planning” -> “Analyze” -> “Design” -> “Development/Testing” is operated, and the amount developed in that sprint is released. The length of each sprint is about 1 to 4 weeks, and it seems that there are many about 2 weeks.
In Fig3, there are 3 sprints, but this is just an example and the actual number is determined by project. In other words, it is decided by “product owner”
Agile requires “3 roles”, “3 deliverables” and “5 events”. I would like to explain in order below.
“3 Roles” in Agile
Agile requires members who would be assigned to the 3 main roles.
As you can see from the above figure, Product Owner is the key person. Since Product Owner has all the decision-making authorities, the person who is at a suitable position should be assigned. But in order to make decisions, the person needs to join not only review meetings between each sprint (every other week for a 2-week sprint), but also Daily Scrum (described later) as much as possible. Therefore, it is unreasonable if the person is at too high level. As a solution, it is important to firmly transfer authorities from top management to Product Owner.
“Scrum Master” is a so-called project manager role and also a team facilitator.
“3 Deliverables” in Agile
There are 3 major deliverables in Agile.
“Product backlog” is equal to “Requirements definition document” in Waterfall. Therefore, before starting the sprint, it is important to have the contents of the product backlog (= scope) approved by an appropriate authority within the company (if there is a steering committee, etc).
“Sprint Backlog” is the extraction of the requirements to be achieved during the Sprint from “Product Backlog” at the beginning of each Sprint. Extraction should be done at the time of “Sprint Planning (described later)”, based on the agreement of Product Owner and Development Team.
“Increment” is actual product (in case of system development, the program itself).
“5 Events” in Agile
As mentioned earlier, Agile runs “sprints”, and there are 5 events in each sprint.
At the beginning of each sprint “Sprint Planning” is held and at the end “Sprint Review” and “Sprint Retrospective” are held.
And during the sprint period, a 15-minute “Daily Scrum” is conducted every day. This is the same with “Daily Standup” I wrote about in my previous post.
3. Key points for “Agile”
In what you’ve seen this far, I think some of you may have noticed that to what extent “Product Backlog (=requirements)” can be achieved, and the overall time it takes depends on Product Owner. It’s the unique feature of Agile.
Therefore, when actually implementing agile in-house, as mentioned earlier, it is important to assign the appropriate person to Product Owner and to transfer authorities appropriately to them.
Also, in many cases, that said, I think that the scope and period are often decided. Therefore, I believe that the following 3 points are important in actually implementing Agile.
If you keep these points in mind, I think Agile is a more flexible and effective approach than Waterfall. And the rest depends on projects to apply. I think it’s perfect for products that can be “released little by little” such as mobile apps. On the other hand, I think that it is better to proceed with Waterfall for the mission-critical systems.
– “Product backlog (=requirements)” shall be approved by an appropriate internal authority (steering committee, etc), and Product Owner shall comply with it
– Overall project schedule (scheduled completion date) shall also be approved by an appropriate internal authority, and Product Owner shall comply with it
– Even during the sprint period, if there is a significant change in “Product Backlog” (changes that impact the cost), get approval from the appropriate internal authority
That’s all for this time, and I would like to continue from the next time onwards. Thank you for reading until the end.