1. Some reasons why we consider Agile
1. We are in a keep changing world, everything is changing quickly, as an organization we
need a good way to handle the keep changing requirements in time, we need to respond
to the new requirements from market quickly, otherwise we won’t survive
2. The best way to handle change is making yourself be flexible: be open to change, be
positive to change, have the capacity to handle change
3. SCRUM is not going to resolve all the issues in product development, but it’s a good way
to be flexible, it make development team and stakeholders be easier to accept/handle
the change
4. Some issues in the typical WoW of product development and how SCRUM can
resolve/avoid
a. Delivery period is long – usually longer than 1 month, the feedback loop from
customer/stakeholder is long, maybe realize that the feature is not the exactly
what customer wanted after the whole project is delivered, the reason can be
communication misunderstanding, customer change the mind, etc.
SCRUM: Fixed Time-Box Continuous Delivery – SCRUM team deliver user
stories per sprint (usually it is two weeks) and do the Demo with product
owner/external customer every sprint, receive the feedback in time, adjust in time,
and handle the changed requirement in the next sprint.

2. b. We all know that requirements cannot be 100% identified at the beginning not
matter how experienced the product owner is, and how long time he/she
spending on the requirement analysis, some requirements will be found and
identified during the development phase. And sometimes customer may also
want to update the requirement after the project is launched. That means
requirement change always happens. But in waterfall the requirement/Scope
change is difficult – Engineers are defensive to the change, product manager
maybe unhappy because the changes always be refused.
One of the responsibilities of the typical PM is managing the scope change – only
deliver the scope which is agreed to in the Statement of Work. If product
manager raise any requirement change, PM will ask the change be approved by
Change Management Board firstly, if it is not approved and then need to start a
new project to handle the changed requirement. And even the change
requirement is approved, PM and development team still prefer to refuse the
change because it will cause redundant code, delay and then negative emotion.
SCRUM: In SCRUM it’s easier to accept the requirement change – product
manager/product owner can put the change in the next sprint, it won’t impact the
ongoing sprint.
c. Project scope change cause team members changing during the project due to
PM may want to deliver the project in scheduled timeline – then will Increase the
cost of communication/cooperation
SCRUM: In SCRUM, the team members should be stable – fixed number of team
members, same team members in different sprints/projects. Then the
communication cost will be stable and low, and there will be easier cooperation.
On the other hand it will be easier to build up the team’s capacity and SCRUM
maturity.
d. People from different department only focus on their responsibility part –
engineers may from different departments: software engineer, hardware engineer,
QA, sourcing, NPI, Mechanical engineer, Product Owner, etc. They may prefer
to protect their department or their individual firstly when issue happens during
the product development.
SCRUM: in SCRUM, the team is a self-organized group, the team takes the
responsibility to deliver DONE user story from the beginning to the end. The
DONE here means high quality, in time, in budget. It’s not scrum master’s
responsibility, it’s not individual’s responsibility, and it’s the whole team member’s
responsibility. It’s real team work! All team members should work together to
make sure the user story is finished in a right way.
e. Buffer
In the typical product development, because engineers and PM they know that
there may will be a lot of requirement changes during the implementation phase,
so they prefer to set big buffer when create the project plan, it causes the critical
features can’t be delivered to market in the fast way.
SCRUM: in SCRUM, there will be more trust between product manager and the
scrum team due to the requirement/scope change will not impact the ongoing

3. sprint, and then reduce the potential of that PM and development team to give
big buffer when do the point estimation.
f. In the waterfall, PM don’t know the real progress, especially in the coding/design
phase
Because the coding/design has not been verified, so it’s difficulty for the PM to
judge the ream progress.
SCRUM: in SCRUM, the user story can’t be treated as DONE until it was verified
or checked by Product Owner. The progress which was shown in the burn-down
chart is the real progress. The progress is visible to team members and
stakeholders.
How to deploy the scrum in an organization
1. Setup scrum team and all team members should sit together in one open space,
by this way to build up open, transparency, team work atmosphere
2. Organize all team members to attend the SCRUM/Agile training together, make
sure all team members know what’s SCRUM
3. Organize team discussion to discuss how can be a self-organize team, allow
team to decide the team building activity, to recruit team members by themselves,
In the ideal condition scrum team should have the authority to decide which
features/projects to develop, etc.
4. Select teams/projects to pilot the scrum, run scrum activities
5. Collect feedback and Lesson Learn – Run retrospective meeting to identify
what’s the well done, what’s the need to be improved. Take actions and follow up
and continuous improve.
6. Run scrum in other teams
7. Improve the scrum maturity, such as broaden team member’s competence:
someone in the team has multiple competences, for example he or she can
handle both software and hardware issues.
8. Scrum master is a servant leader but not a project manager, scrum master need
to motivate the team members, coach the team members to build a self-
organized team, maintain the white board, and build up the team’s scrum
maturity. Not just assigning to task to team members, following up the progress,
and reporting progress which usually are the responsibilities of a typical PM.
SCRUM Activities
1. Product Owner creates the User Story – the user story should have the clear
description, definition of DONE, Priority. example: as a customer, I want to do XXX
then I can achieve XXXX, the priority of this user story is XX
2. Product Owner goes through the user story to the team members; make sure scrum
team members understand the user story correctly, make sure all guys are in one
page.
3. Play point game – team members sit together to estimate the point of the user story
(to finish the user story from coding/design to verification). There should be the base
user story which will be used as ruler when do point estimation. And someone who

4. gives the highest point estimation to the user story need to explain the reason, same
to someone who gives the lowest point estimation.
4. Scrum Master makes a rough Project Plan – how many sprints to finish the whole
project based on the historical velocity date. It’s a rough a PP. Program manager and
Product manager should use this PP carefully.
5. Start the first sprint. Run daily stand-up meeting, coding/design, testing, Demo,
rebase code, running regression testing, fixing defects, delivery.
6. Start next sprint. If need we can play the point game again to get more accurate
point estimation.
7. Finish the whole project
8. Run Retrospective meeting – to identify what’s well done, what’s need to be
improved. Scrum master assign people to follow up the action points.
9. Scrum tools
(1) While board – To do list, ongoing list, Done list
(2) Burn Down chart – To visualize and track the progress
(3) Standup meeting – to update the white board and communicate, should be quick
and brief. Encourage team members to do face to face talk for complex technical
discussion.
(4) Automation Testing – then team can check the code quality quickly after rebase
and delivery, also can identify which release/delivery introduce the issues to the
main branch quickly. TDD will be the best!
(5) Common space of the scrum team
(6) Velocity – to plan how many points will be finished in the sprint
(7) Point Game – make the point estimation of the user story
(8) Retrospective meeting
(9) Git, ClearCase, ClearQuest, HPQC, SVN,JIRA, SharePoint