Portfolio Resume

Anson's Portfolio: Scrum Master

Last update: Jun-2021
Scrum team in Hong Kong.

Project Background

In year 2012-2014, I worked for the IT department of a world class garment manufacturer as a Scrum Master.

The manufacturer has more than 10 garment factories in Asia countries such as Malaysia, Vietnam, Thailand, Indonesia. She has a large extent of market share, producing high quality and diversified garment products for many famous apparel brands in the world.

To cope with the complex business logic of material planning, order processing and production planning, a lot of resources have been invested in IT systems development. A package of robust MRP/ERP systems were being setup to cater the related transactions and workflow between factories and the head quarter in Hong Kong.

Since the MRP/ERP systems are vendor products, some custom requirements would be implemented by bespoke applications. In this way, agile development teams have been formed for the purpose. I was selected as the Scrum Master for one of the Scrum teams, focusing mainly on pre-order processing and production planning domains.

The following sections briefly introduces the practical implementation of how we applied Scrum methodology to support business needs.

Scrum Life Cycle

(1) Create Product Backlog
  • This is the initial stage of a project. It is usually an one-off process of the entire project, or can be reviewed again upon the high-level requirements changed.
  • As the Scrum Master, I needed to review and discuss the requirements with PO and BA, determining the do-able UR items based on their priorities, difficulties together with the time constraint.
  • Finally, the agreed items would be transformed into product backlog as user stories. To ease the sprint backlog setup, BA and I would also record the details such as data flow, process flow, agreed UI/fields (if any), etc.
(2) Create Sprint Backlog
  • When users confirmed the user stories, sprints arrangement would be started. User stories would be splitted and assigned into multiple sprints.
  • All stakeholders were required to participate in Sprint Planning meeting to confirm the items of that sprint. The decision was made according to the priorities and dependencies. For example, if PO wants to see the prelim effect of an UI design for further decision making, the related tasks will be put into early sprint. Or if a task is the prerequisite of other tasks, that will also be placed into early sprint.
  • A sprint would not last for too long (usually 2-4 weeks), so that stakeholders could be able to see the product quickly to ease the continuous discussion. It could also benefit the developers by shortening the time of each milestones, keeping up the momentum.
  • Finally, developers would pick up the tasks according to the story points (i.e. difficulty and time effort). As the Scrum Master, in case of disagreement, I would make the final judgement based on my experiences and understanding on the developers.
(3) Product Development
  • Once confirmed the tasks of that sprint, development would be started right away. Morning stand up meeting would be hold every on business day, to update the progress, clarify UR, knowledge sharing, technical discussion, etc.
  • As the Scrum Master, I would liaise with all stakeholders, resolve technical and non-technical difficulties, so that Scrum team could be able to focus on the development.
(4) Sprint Review
  • When the sprint development completed, a Sprint Review meeting would be arranged to demonstrate the completed product.
  • We would also review the level of success, the things to improve, so that we could improve the subsequent sprints in terms of time constraint, task arrangement, QA process, etc.

Challenges

Multiple User Cultures:  Users came from multiple countries with different cultures, we needed to adjust speaking tone and mind set all the time.
Version Handling As we used one system instance to serve all factories, and very often they would have different requirements on a single function, so version management and source branching were critical. Application and configuration design were also important to cater the differences.
On-site Observation Very frequently we needed to observe the factories production lines to understand the actual operation flows, additional efforts were required for traveling.

Achievements

RequirementFulfilled >95% requirements and expectations. Gained compliments from business units.
Time ManagementLaunching projects on time with high quality standard.