This is an old revision of the document!
Table of Contents
OnSemi Agile Project
Problem Statement
Most companies are hierarchical. Managers make decisions which are cascaded down the ranks to be carried out. While feedback is often encouraged, responsibility almost always remains with the manager. The subordinate accepts that his boss can overrule any suggestion. Afterall, that's why bosses are paid more for.
A sense of ownership is a powerful motivator for inspiring extraordinary work performance. If the norm is a traditionally top-down approach in the company, it is difficult to convince staff that any change is good, efforts will be recognised and it will be beneficial for all in the long run. This is explained well by Whirlwind of Work (WoW) in Covey's 4 Disciplines of Execution.
As such, culture change requires a concerted effort to pilot a demonstration of what can be done. Theories in management books and seminars and trainings remain intangible, until the staff can see and feel for themselves that they actually work, and will yield positive results.
One of the many core principles of the Agile Manifesto is:
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
Why Scrum ?
Scrum promotes self-organising teams, fosters ownership, accountability, and collaboration. Scrum empowers teams to make decisions and have ownership over their work. This leads to increased engagement, enthusiasm, and a sense of accomplishment.
The cross-functional nature of Scrum teams help eliminate silos, leading to smoother workflows.
To foster cadence, Scrum's regular meetings and artifacts (like Product Backlog and Sprint Backlog) ensure everyone has a clear view of progress and priorities.
Implementation Plan
Phase 1: Discovery - 2 weeks
- Identify 3 staff to draw up plans
- Appoint a Product Owner to seek feedback and draws up Product and Sprint Backlogs comprising User stories
- Appoint a Scrum Master to attend CSM (Certified Scrum Master) course
- Recruit another upto 6 staff/developers to form pilot Scrum team
Phase 2: Scrum pilot - 3 months (5 sprints x 2 weeks each)
In each 2-week sprint (i.e. 10 working days), there is a “cadence” of activities that happen. It is important to have the whole team physically seated together, away from their respective “WoW”, to foster team cooperation, reduce “silo” behaviour, and allow any simmering issue to surface quickly to be resolved.
- Day minus 1: (4 hours) Pilot Scrum Team conducts Sprint Planning
- Product Owner presents Product and Sprint Backlog for discussion
- Team estimates “story points” and agrees to Sprint Backlog (i.e. scope of work)
- Days 1 to 9:
- Scrum Master conducts Daily Stand-ups every morning (15 mins): Every team member answers 3 questions:
- What did you do yesterday?
- What are you planning to do today?
- What obstacles/issues do you face?
- Product Owner refine Product Backlog and prepare next Sprint Backlog
- Developers jointly work together to achieve Sprint Goals
- Day 10:
- Sprint Review (2 to 3 hours): Team presents completed work to stakeholders and seek feedback (Remember to book stakeholders' time early in advance)
- Sprint Retrospective (1 to 1.5 hours): Team discusses the Sprint just completed and how to work better together
- Sprint 2 Planning: See Day-1, iterate
At the end of each Quarter (i.e. every 3 months), it is a good practice to tally up what has been done, achieved, improved and learnt. To consider whether, and how, to take this initiative forward, as well as if any additional resources/support is needed.
Phase 3: Embrace and Extend - 6 months
- Recruit upto another 9 staff for Scrum Team 2
- Product Owner and Scrum Master to attend trainings
- Scrum Masters to conduct Scrum training for developers
- Both Scrum teams to run concurrently
- Informal Scrum of Scrums between Scrum Masters to coordinate backlogs/activities, until there is a need to formalise it.