Template Do not Copy
Waterfall vs. Agile
Individual Assignment
11/06/2018 | PMGT 572
Template Do not Copy
2
Agenda
1. Introduction
2. Processes & Definitions
3. Initiating
4. Planning
5. Executing
6. Monitoring & Controlling
7. Closing
8. Conclusion
Template Do not Copy
3
Introduction
This presentation aims to highlight the similarities and differences between the traditional waterfall product development project that I worked on during the PMGT510 class and the website development of Chefville using Scrum from the PMGT572 class. This comparison will be based on the project management process groups from the PMBOK.
PMGT510 Waterfall approach to develop a crankshaft
PMGT572 Scrum approach to develop a website
Template Do not Copy
4
Agenda
1. Introduction
2. Processes & Definitions
3. Initiating
4. Planning
5. Executing
6. Monitoring & Controlling
7. Closing
8. Conclusion
Template Do not Copy
5
Processes & Definitions
PMBOK
Purpose Meet (or exceed) the needs and expectations of stakeholders for a project
Definition Application of knowledge, skills, tools
and techniques to project activities to
meet project requirements
Methodologies Traditional Waterfall
Agile practices (i.e.: Scrum)
Framework Project management provides a
framework for working amidst
persistent change.
Project Management Definition
Template Do not Copy
6
Traditional project management follows a Waterfall approach and consists of the application and integration of the five process groups:
1. Initiating 2. Planning 3. Executing 4. Monitoring & Controlling 5. Closing
Processes & Definitions
Traditional Approach to PM
Template Do not Copy
7
Processes & Definitions
Agile uses an “adaptive style of project management”, which is based on a less defined planning phase and which recognizes that “requirements and plan for the project” will change “as the project progresses”. This approach offers the company more room for adaptability and makes late changes less expensive.
Scrum is an Agile methodology, which uses an iterative and incremental approach to developing products and managing work.
Agile Approach to PM
Sources: The Project Manager’s Guide to Mastering Agile , Scrum Essential
Template Do not Copy
8
Agenda
1. Introduction
2. Processes & Definitions
3. Initiating
4. Planning
5. Executing
6. Monitoring & Controlling
7. Closing
8. Conclusion
Template Do not Copy
9
Initiating
Product Vision
Initiating a project using a traditional approach requires to clearly define the scope and goals of the project and to quantify its success criteria and risks. This takes time and will be the basis for all other documents of the project planning phase. On the other hand, the initiation phase of a project using Scrum only requires the product vision. The product vision of Chefville is shown in the next 2 slides. As we can see, the product vision provides just enough information to be able to start the project, without loosing time and still allowing room for changes. Finally, the product vision is more comprehensive and easy to read.
Template Do not Copy
10
We aim to increase the visibility
of our French restaurant
downtown Cedar Rapids (Iowa)
thanks to our Website “Bistrot
du Coin”.
Unlike our competitors (other restaurants in the city), we offer traditional French cuisine, made by a French chef, who studied at the Bocuse Institute.
Chefville Product Vision Statement
Template Do not Copy
11
Chefville Product Vision Board
Target Group Young professional people from
Cedar Rapids and surrounding
areas.
Needs Increase the visibility, popularity of
our new restaurant in Cedar Rapids.
Introduce French cuisine to the Cedar
Rapids area.
Product & Features ✓ Gallery including pictures of food and
of the environment
✓ Menus with pictures
✓ Reservations
✓ Comments & Reviews
✓ Discounts & Special events
Value ✓ Profitable Company
✓ Business Model based on the revenue
of the restaurant and advertisements
of the website.
✓ Goals: Reach $1million of revenue in 2
years. Increase awareness and
popularity of the restaurant of 30%
within 2 years.
Template Do not Copy
12
Agenda
1. Introduction
2. Processes & Definitions
3. Initiating
4. Planning
5. Executing
6. Monitoring & Controlling
7. Closing
8. Conclusion
Template Do not Copy
13
Planning Overview
Knowledge Areas Traditional Tasks Agile Tasks
Scope WBS User stories
Time Gantt Chart Prioritization, Estimation, Release Planning
Cost Budget
Quality Requirements Acceptance Criteria
HR Resources: Role, MS Project Roles, Impediments, Agile Coach, JIRA, WIX
Com Doc Diary, WhatsApp
Risk& Procurement Risk register Iterative approach
Stakeholder Stakeholder register Continuous interaction with stakeholders
In this section, the comparison of the 2 projects using different PM methodologies will be based on each of the knowledge areas of the planning phase.
Template Do not Copy
14
Planning – Scope
The work breakdown structure and the user stories backlog are both used to get a better idea of what work will be required to reach the goals of the project. Both of them will be further broken down into subtasks when required in the planning phase. The main difference is that, once defined in MS Project, the WBS cannot be updated that easily, while the user stories in JIRA are meant to be updated as the project goes, which was very useful during the creation of our Restaurant website.
Template Do not Copy
15
Planning – Time & Cost
Estimating the time and resources required to complete each task, as well as the dependencies between the tasks and the overall cost of the project took me at least 5 full days. The result is presented by the Gantt Chart of this page.
On the other hand, estimating and prioritization the backlog was much faster and much easier to handle. Indeed, instead of trying to define strict hours, costs or resources, we only had to estimate story points. In addition to this, we made sure that all our user stories were independent from each other. This gave us the opportunity to move stories from one sprint to another, during the release planning, without having to worry about dependencies.
Template Do not Copy
16
Planning – Quality
While quality management planning required to be very specific and technical, the acceptance criteria of our website were quite straight forward and understandable by all stakeholders. In addition to this, we checked the quality of our work at the end of every user story, which helped building a working product after only few days. The traditional approach to quality is not done as frequently, and correcting mistakes takes more time and is costly.
Template Do not Copy
17
Planning – Resources
Agile Coach
Using a traditional approach in the PMGT510, as the Project Manager, I was responsible for an entire team, with strict roles and responsibilities, as shown in the organizational chart. I also had to assign tasks to each of the team member, according to their field of expertise and according to the time they had available for the project. When working on the restaurant website project as the Product Owner, I enjoyed having a team fully dedicated to this project. In addition to this, in theory, the Scrum team is committed and self-organized. Nonetheless, for this class, we realized that assigning tasks to team members was much more efficient than just waiting for people to volunteer. In regards to other resources, the main tool used in traditional project management was MS Project, while for the website we used JIRA. Finally, having an agile coach to support the team was very useful, which we had through this PMGT572 class.
Tasks Assignment
Template Do not Copy
18
Planning – Resources
As the Project Manager for the crankshaft product development project from the PMGT510 class, I was responsible and accountable for managing all aspects of the project. In other words, I was responsible for understanding and managing how each functional team is going to get the work done.
Going into more details, as a Project Manager, I collaborated with the team and the stakeholders to define the scope of work, plans and allocates the tasks, manages the budget, prioritizes features and coordinates with other dependent teams.
The Project Manager
Template Do not Copy
19
Planning – Resources
I became the Product Owner of the team Chefville because I had the idea of the restaurant and took responsibility for maximizing the value of the product and the work of the team. I was the one responsible for the project, in regards to decision making and user stories prioritization in the backlog. In other words, as the Product Owner, I was the one able to accept or reject the work, according to the definition of “done” and based on our acceptance criteria.
The Scrum Master of Chefville on the other hand was accountable for facilitating the Scrum process and acted as a Servant Leader. Our Scrum Master was using our WhatsApp group to remind everybody to update the story in JIRA and to make sure that there was no impediment preventing the team to do the work. When issues where identified, the Scrum Master was present and reactive to work on fixing them with the team.
The Chefville team was responsible for delivering working products at the end of each sprint, based on the backlog prioritization. Chefville was cross- functional, composed of 4 generalizing specialists, but could have been more self- organizing. As mentioned before, the team members are supposed to choose the tasks they will work on during the sprint, within their field of expertise. However, this can only happen when the team is fully committed, focused on customer and build- in quality and located in the same work place.
Product Owner, Scrum Master & Scrum Team
Template Do not Copy
20
Planning – Communication
As we can see in this slide about communication, I created in PMGT510 a communication plan defining which document will be done, when, and who it should be sent to. One of the main communication tools which was used, was the Status Report shown in this slide. This was meant to be used to clearly see what was on-going, done, to do and where were the issues.
I personally think that the communication tools used in PMGT572 with the Chefville team were much more efficient because more visual. Indeed, we used a Kanban board in JIRA to check the status of the project, we communicated on a daily basis with WhatsApp and through our Daily Scrum Diary. Finally, our review and retrospective meeting were excellent communication tools to avoid any misunderstanding and to further improve the productivity of the team.
Communication Plan
Status Report
Daily Scrum Diary
4Ls Retrospective
Template Do not Copy
21
Planning – Risk, Procurement & Stakeholders
During my work as Project Manager for the crankshaft product development project, I developed very detailed risk, procurement and stakeholders management plan. In regards to risk management, I built the risk register shown in this slide. To do so, I had to identify each risk, prioritize them, define a way to mitigate them and define a response strategy in case a risk actually occurs. In regards to procurement management, I ran a Make or Buy analysis, to define if it was more interesting for thyssenkrupp to buy steel from a third party, or to make its own steel for this product. In regards to stakeholders management, I worked on a stakeholder register in order to define how to communicate and approach each stakeholder, depending on their original concerns or preferences towards the project.
This being said, during our website development project, the Chefville team didn’t have to worry much about risks or procurement. Indeed, we had nothing to purchase and the risks were identify and addressed throughout the project and during the sprint. However, I found that the Scrum approach to project management handles very well the stakeholder relationship, as it is all about continuous communication with all of them, which makes it much more effective than just having a stakeholder analysis.
Risk Register
Stakeholder Register
Template Do not Copy
22
Agenda
1. Introduction
2. Processes & Definitions
3. Initiating
4. Planning
5. Executing
6. Monitoring & Controlling
7. Closing
8. Conclusion
Template Do not Copy
23
Executing
The main difference between the crankshaft product development project and the Bistrot du Coin website project was about the way to execute the work: waterfall vs. iterative.
For my project in PMGT510, it took me 4 whole months to complete the planning phase of the project. The next step was the executing phase, which takes about 6 month before the customer can actually start seeing the first crankshaft. In other words, from the project kick off, it takes 10 months to deliver value to the customer.
On the other hand, for the Bistrot du Coin website project, the iterative approach to project management enabled the Chefville team to have a working product, tested and validated, after only 2 weeks. Even though a crankshaft and a WIX website are two completely different products, both of them are relatively simple product and should not require 10 months before value can be delivered.
The following slides show how the work was being done, story after story, using the Scrum methodology to build the Bistrot du Coin website.
Template Do not Copy
24
Completed Stories in Sprint 2
Stories related to the Opening Hours & Reservations:
First of all, we looked for the opening hours and reservation applications in WIX. We then
inserted them in their respective page of our website. Finally, we edited these applications
them with our information.
Template Do not Copy
25
Completed Stories in Sprint 2
Stories related to Events: We first created the main page related to Events &
updates and briefly advertised the 3 upcoming events. We then created a dedicated page for each
event that we linked to the main event page. Finally, we worked on each page of each event.
Template Do not Copy
26
Completed Stories in Sprint 2
Stories related to the Social Media, advertisement & Reviews main page: First, we created a Social Media bar for the bottom of the page. We chose the Media we wanted to have. The we created Social Media accounts and connected the links to the
website. Later, we added advertisement to our website, by including a Pernod Ricard picture on the
Home Page. By clicking on the picture, the customer has a direct access to the Pernod Ricard official website.
Finally, we created the main page for the customers and press reviews.
Template Do not Copy
27
Agenda
1. Introduction
2. Processes & Definitions
3. Initiating
4. Planning
5. Executing
6. Monitoring & Controlling
7. Closing
8. Conclusion
Template Do not Copy
28
Monitoring & Controlling
Monitoring and controlling using a traditional or agile approach to project management can be quite similar in some ways. Indeed, I have used burndown charts and many other charts with both MS Project and JIRA.
The main difference is about follow up meetings: in traditional project management, follow up meetings are usually weekly, instead of daily with Scrum. Because of the distance, the Chefville team did not have stand up meetings everyday, but we talked daily via WhatsApp, submitted our daily diary every 2 days and talked once a week during our breakout sessions every Monday. This allowed us to closely monitor and control the work being done and to immediately solve any issue we might have.
Template Do not Copy
29
Agenda
1. Introduction
2. Processes & Definitions
3. Initiating
4. Planning
5. Executing
6. Monitoring & Controlling
7. Closing
8. Conclusion
Template Do not Copy
30
Closing
Using a traditional approach to project management in order to close a project implies lessons learned, closing budget, contracts and archiving all relevant documents.
While the closing phase of a project using Scrum follows a similar approach, it is done on an iterative basis, just like the execution. Indeed, at the end of every sprint, the Chefville team met for the sprint review and sprint retrospective, which have for objectives to see what was done during the sprint, what went right or wrong, what could be improved, added or dropped.
This iterative approach to lessons learned is very useful, as it really helped the Chefville team improve during the project, and not just helping the next project to improve.
Template Do not Copy
31
Agenda
1. Introduction
2. Processes & Definitions
3. Initiating
4. Planning
5. Executing
6. Monitoring & Controlling
7. Closing
8. Conclusion
Template Do not Copy
32
Conclusion
To conclude, I have found many advantages in using the Scrum approach to project management and see real benefits in using this methodology in the automotive industry, in project such as the crankshaft product development project. Finally, I have enjoyed this class very much, as it was very interesting for me to apply the theory of Scrum to a concrete project: the development of the website of the French restaurant “Bistrot du Coin “.
Template Do not Copy
THANK YOU
Individual Assignment
11/6/2018 | PMGT 572
Get help from top-rated tutors in any subject.
Efficiently complete your homework and academic assignments by getting help from the experts at homeworkarchive.com