“Scrum” is a phenomenal subject — i.e. if you are familiar with it. As an Agile project manager, I have seen my fair share of so-called “Scrum Masters” and “Agile Experts” claiming to be masters of their craft. The truth, however, is that they don’t know a lot of things about Scrum and Agile. In fact, I was surprised that some of the “experts” didn’t even know that Scrum Master and Product Owner are not the same individual.
Anyhow, this case study illustrates different real life examples of Scrum Project Management. Despite its egregious length, I think that the topic is non-conclusive. We’ll keep on adding new updates to this phenomenal write-up for aspiring project managers. Take it as a start on all things related to Scrum and modern day application of Agile Framework at different companies in the industry right now.
Scrum Project Management is a framework from the Agile project management methodology. The term Agile refers to a way of managing projects that incorporates constant improvement, scope flexibility, team involvement, and delivering crucial quality products.
Some of its approaches, other than Scrum, include Extreme Programming (XP) for quality upfront building, Lean thinking for waste elimination and the Agile Unified Process (AUP) approach to developing business application software using agile techniques.
In this ebook, we will discuss why Scrum is a robust and scalable framework for agile teams and consider some great success stories from around the world for teams using the Scrum framework.
Introduction — Why Scrum?
Developed by Ken Schwaber and Jeff Sutherland in the early 1990s, Scrum Project Management provides a lightweight process framework that encompasses iterative and incremental practices. It helps quicker delivery and better frequency in the software release by organizations. The projects cycle involves a set of repetitions called sprints where at the end of each sprint, the project team releases an improved, validated and potentially deliverable product.
This framework contradicts the traditional Waterfall approach, which is based on extensive analysis, planning of requirements and documentation before starting the development phase. This method often results in low-quality products due to delays in milestones, financial issues and lack of prioritized characteristics for the products. In the end, the customer receives a delayed product, with an outdated or unrequired feature set having high cost at the same time.
Scrum has been used in all walks of life — such as schools, government, software and hardware development, marketing, and everyday operations in organizations. It has proved especially effective in areas that deal with iterative and incremental knowledge transfer.
What is Scrum made of?
Scrum is made of sugar, spices and a secret ingredient that Power Puff Girls are made of! Just kidding. There are three main components, but none of them are like the aforementioned stuff. Read on…
The Team: Scrum teams are self-organizing teams, with 5 to 11 members. These teams need to be adaptive to change and highly flexible. They also need to be cross-functional, with all proficiencies required to achieve the project without dependency on team members. The Scrum team is divided as follows:
Product Owner: The Product Owner is a single person, responsible for the Product Backlog, which is a list of features that are prioritized with short descriptions of the functionality required. The Product Owner needs to ensure that the Product Backlog elements are clearly stated and transparent to the team — about the current situation and what’s planned next.
This means that the Product Owner should:
Any suggestions regarding changes to backlog need to be addressed directly to the Product Owner.
Development Team: As the title implies, this team carries out the development work, which is incremented during the sprints and potentially deliverable by the end of each sprint. This team is a disciplined, self-organizing and cross-functional. In essence, it means the team members need to discipline their own work pace and be multi-skilled across various functions.
There are no titles, regardless of the level of work done by the team members; and there are no sub-teams, regardless of domains diversity in domains e.g. testing, operations, analysis. The Development Team is accountable for the whole for the work to be delivered.
Scrum Master: A Scrum Master is a facilitator and holds the responsibility for promoting and supporting Scrum. The Scrum Master carries out employee coaching through Scrum — the theory, values, rules, and practices. The following are some of the ways a Scrum Master can be of help to the entire team:
Scrum Master’s Service to the Product Owner: The Scrum Master can help the Product Owner by in some of the following ways:
Scrum Master’s Service to the Development Team: The Scrum Master can benefit the Development Team by:
- Training the Development Team in self-discipline and cross-functionality
- Minimizing roadblocks for the Development Team and maximizing value
Scrum Master’s Service to the Organization: The organization needs the Scrum Master to:
- Direct and guide the organization in its Scrum implementation
- Help staffs and stakeholders understand and endorse Scrum and empirical product development
- Pave way for maximum productivity of the Scrum Team, and
- Boost efficiency of Scrum application together with the other Scrum Masters.
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of a working product is always available.
Primarily, Scrum comprises 4 formal events or phases for review and adaptation:
The Sprint, which is the main activity in Scrum, is a time-period lasting between 1 and 4 weeks. On average, the Sprint covers 2 weeks.
Sprint Planning Meeting: This meeting renders the activities that go towards planning exactly what needs to be done. Team members take up different tasks based on the highest priority. The Product Owner and the Development Team then define the tasks to be covered within the corresponding sprint.
Daily Scrum or Daily Standup: The Daily Scrum is an approximately 15-minute, daily event that highlights the activities of the team. Each team member shares the work done the day earlier, work done that day and then identifies any problems. The purpose of this daily meeting is to ensure all the team members are on the same page and their activities in sync.
Sprint Review: The Sprint Review is carried out at the end of each sprint where the team discusses and shows the goals achieved. This review meetup also gives the stakeholders a chance to give feedback and suggestions about the product.
Sprint Retrospective: The Retrospective Meeting, also held at the end of the sprint, encourages the team to assess the goals achieved. The team identifies the issues, weak or strong activities and ways for improving the new upcoming Sprint.
Scrum Project Management stands on the 3 main artifacts that help focus on deliverability and business value. These are:
- Product Backlog: The product backlog is a list of functionalities that are to incorporate in the deliverable. It is prioritized by the product owner such so that the team can focus on the topmost requirements. This eliminates any confusion or time wasted on unnecessary elements.
- Sprint Backlog: The Sprint Backlog is also a list of prioritized functionalities or activities that need to be done during the corresponding sprint.
- Increment: The increment refers to the reviewable, authenticated work done at the end of the sprint. It denotes all the Product Backlog items completed, combined with the value of the increments of all preceding Sprints. At the end of each Sprint, the new Increment must be “Done” as per the Scrum Team’s definition. Different Scrum Teams can have different ways to define “Done” depending on the required items to be completed. To ensure transparency throughout the project, each team must understand the type and extent to which the tasks must be completed.
1. Case Studies from the Industry
1.2. Scrum at Intel Story Started With a “Small Problem”
The Product Development Engineering (PDE) group provides the test collateral to endorse lucrative device screening and classification in the microprocessor industry. Stuck between the design and manufacturing teams, PDE was most often under pressure, struggling with deadlines, requirements, and deliverables.
The sub-teams at PDE, about 50 employees, agreed to work on a more integrated method in product development. It was decided that the Agile methodology, the Scrum framework would be adopted combined with another engineering best practices.
Adopting an entirely new framework was not going to be easy because of the waterfall culture deeply embedded at Intel over the long years. According to this culture, the teams were organized in distinct functional towers. The towers individually worked on different functionalities of the project, one transferring the completed function to the next.
Due to this, some of the teams had to face unusual burdens, especially in the later stages of product development. This, in turn, leads to high turnover at the end of a project. Also, because the domain experts of each team had different skill sets, they couldn’t work together or share responsibility.
It was agreed to introduce Scrum into the first, relatively relaxed phase: the development of pre-silicon infrastructure and readiness work. If Scrum could succeed in this phase, there were more chances of it growing into the more stressed, pressurized, later phases of the product development i.e. when daily work depends on the state of the actual silicon, requirements of customers related to design, manufacturing and fabrication along with external business conditions.
Initially, 6 teams with their numerous sub-teams participated. CollabNet was employed for Scrum education and training. About 20 group leads and technical leads joined the 2-day Certified Scrum Master training. It comprised an introduction to Scrum principles and practices.
The training was followed by a retrospective meeting in absence of Collabnet representatives. The participants in that meeting discussed their ideas and reservations regarding the adoption of the Scrum framework. The participants finally agreed to try the Scrum approach for 3 months. A Process Action Team (PAT) was created for monitoring the development of Scrum. Despite the agreement, there was already a sense of discord amongst the groups.
About 5 months later, scaling work across the Scrum teams had turned into a huge challenge. The organization was not sure how to manage the dependencies between multiple teams and improve inter-team communication. Another course was carried out by CollabNet that focused on major principles of sprint planning, release planning and scaling across multiple teams. After learning some more best practices, adding more roles to handle the technical issues and more layers of the organization, within a year 12 Scrum teams were established, each with about 5 to 9 developers, within a year.
Roles were defined that included Business Owners, Product Owners, Technical Owners, Scrum Masters, Teams, Transient, Conduit, and Story Owners.
- The Business Owners comprised senior managers looking over multiple teams.
- The Product Owners were functional group managers.
- The Scrum Master was a cross-team engineer with no stakes in the team. The Teams were responsible for a single output.
- Transient included multi-skilled personnel for a sprint or two at a time.
- Conduit represented more than one professional such as contractor supervisors
- Story Owners were technical experts with particular expertise. These would inform what tasks are to be done and who can they be assigned to.
After many fluctuations in the Sprint timings, cross-functional team communication and adding extra Scrums from the Manufacturing department, there was finally a visible difference in four major ways: Cycle Time, Performance to Schedule, Morale, and Transparency.
Reduced Cycle Time: Scrum was a major contributor to a 66 percent reduction in cycle time.
Performance to Schedule: Schedule slips and missed commitments were eliminated. Capacity-based planning and a 2-week rhythm were established and maintained.
Improved Morale: There were a significant morale boost and job satisfaction along with improvement in communication.
Increased Transparency: Formal standard was adopted. Problems and weak practices were uncovered.
Scrum has been a major contributor to a consistent, repeatable, 66 percent cycle time reduction in the creation of our work product.
Scrum was a successful step in Product Development Engineering. It helped the transformation to inspect and adapting, self-organizing, an empirical planning-based organization from a command-and-control, plan-based organization.
In 2013, the staff of St. Michael’s School, were in search of methods to improve relationships between the local community and the students — aged 12 to 15. The school is located a few miles outside of Wolverhampton, in Central England. The idea was to get students to design an application more effective collaboration between the teenagers and the police; and especially, in a crime rate reduction.
They heard of Royle and his Scrummy School initiative. According to Royle, the Scrummy School concept was developed at the University of Belgrade, in collaboration with Jasmina Nikolic. She is a pioneer in the use of Scrum, Kanban, and Open Space in different contexts, especially education and this was her original thinking of using Scrum in education.
Royle wanted to trial the initiative in a school, so he and Wayne Hill, the deputy head of St. Michael’s decided to give it a try.
The story started with approaching the local police service — the West Mercia Police, and Police Constable (PC) Hughie Treasure, a community liaison officer. Fortunately, with the support of the PC Treasure, the experiment began.
An Open Space meeting was held among the police, students, and university staff to generate ideas. The plan was developed next. Royle decided to use a “rapid version” of Scrum, to better align with the structured and diverse school day. There were 5, 20-minute Sprints. After the first Sprint, the students could manage the remaining themselves. Finally, an app and paper prototype was designed with an “elevator pitch” presentation for the police.
Keeping in mind the limited timelines and diverse skills, Royle felt that Scrum especially would be most useful for the project at hand. Moreover, it could offer an environment for students to work in teams on their own, making them feel more connected to the project.
As Royle explained, “Using an Agile learning philosophy with Scrum is about developing what team members can do rather than what they can’t,” he says. “Rather than assessing what children cannot do, the Scrum framework allows them the opportunity to use their inherent capabilities and to develop new skills in a safe environment.”
Some of the mentionable benefits that this experiment brought about were:
The project delivered reinforced the success of the Scrummy School program. Royle encourages that schools adopt this concept; however, all schools differ in programs and its incorporation should be managed to keep special considerations in mind.
2.3. Swiss Construction Company
One of the biggest challenges the construction industry faces is to create buildings that can stand trials: foreseeable and unforeseeable. There is a lot of planning involved and project managers need to use tried and tested templates, checklists and models with multiple stages.
Certain tasks need to be done before others can be started. Moreover, problems need to be discovered as early as possible. At times, the implementation of certain tasks takes so long that the entire project needs to be revised to accommodate the new requirements. This can result in recurring costs, delays in schedule and negative impact on the overall quality.
In a research paper, Implementation of Scrum in the Construction Industry the use of Scrum for construction of a building was studied. The project involved the building of 3, four-story, multi-family buildings for the Swiss market, with a total floor area comprising 2'100 m 2divided into 11 flats and 200 m 2of commercial space. Scrum was implemented in the design phase of an ongoing project, whereby the design, engineering, and production were carried out in Estonia. The prefabricated timber-modules then had to be transported to Switzerland.
The Scrum framework emphasizes on-time problem identification and solutions. For construction, not only is discovering problems early on in the process vital but also to study, inspect and adapt accordingly. Sprint reviews and retrospective in the Scrum method provide structure and discipline to do so.
The results of this study highlighted the potential of Scrum as follows:
3. Other Use Cases and Applications for Scrum
The Scrum framework can be incorporated into multiple scenarios, especially when it comes to Information Technology. It can contribute to effective team and project management resulting in proficiency in project monitoring and delivery.
3.1. Use Case 1: Web Development
Problem Statement: Important changes need to be carried out in an existing company website. The team needs to be assigned tasks and timeline.
Product Owner: Team Lead
Development Team: Developers
Scrum Master: Project Coordinator
Basic Flow of Events:
- The website needs to be updated under different categories.
- The development team needs to be delegated the tasks and the timeline.
- Product Owner creates a backlog i.e. the prioritized changes to make.
- The development team and the QA team is created.
- Sprint of 7 days is decided.
- Scrum master is assigned to facilitate the meetings and issues.
- Tasks are assigned to the team
- A daily 15-minute Scrum is set up for holding team meetings
- Each team member for both teams reiterates the tasks are done and those in the pipeline
- Website is updated each day with the work done
- QA notifies of issues on the same day.
- Each week the Sprint Review meeting is held with the CEO for an update on progress.
3.2. Use Case 2: Game Development
Problem Statement: A client requires a game to be developed from scratch.
Product Owner: Team Lead
Development Team: Programmers
Scrum Master: Project Coordinator
Basic Flow of Events:
- The scope of the project needs to be defined within the time and budget.
- The development team and the QA team need to be delegated the tasks and the timeline.
- Product Owner creates a backlog i.e. the requirements and the most significant features to work on and the platform.
- The development team and the QA team is created.
- Weekly sprint is decided.
- Tasks are assigned to teams
- A daily 15-minute Scrum is set up for holding team meetings where each team member for both teams reiterates the tasks are done and those in the pipeline
- The Scrum Master coordinates between teams for the tasks being done.
- The programmers provide update daily Scrum.
- QA notifies of issues on the same day.
- A weekly Sprint meeting is held to reinforce successful practices and eliminate unsuccessful ones
- The product owner, the scrum master and the development team arrange to present a monthly Sprint Review to the customer.
3.3. Use Case 3: Software Testing
Problem Statement: A client company is outsourcing Quality Assurance for its next online chat software.
Product Owner: QA Team Lead
Development Team: QA testers
Scrum Master: Project Coordinator
Basic Flow of Events:
- The product needs to be explained to the testers.
- Software testing methods and the platform is decided.
- Product Owner creates a backlog i.e. the most important application features to be tested.
- Features to be tested are assigned to the QA team.
- A sprint of 10 days is decided.
- Daily Scrum of 20 minutes is planned for team updates.
- Based on the updates, product owner re-assigns tasks or re-prioritizes testing.
- The sprint meeting after 10 days is held with the client company.
- Software bugs are reported daily and a report is made and sent by the Scrum Master to the client.
- The programmers at the client-side update the software.
- The monthly Sprint Review is held between the client and programmers and the QA teams.
- A new backlog is created according to the changes in the software for the next Sprint.
Problem Statement: Customer issues are increasing and there is no standard plan for solving customer problems.
Product Owner: IT Support Manager
Development Team: Support personnel
Scrum Master: IT Support Team Lead
Basic Flow of Events:
- Customer issues are communicated to the support team.
- The support team communicates problems to the development team for improvements.
- Problem log is created.
- Product Owner creates a backlog i.e. the most important issues the customers face.
- The Scrum Master communicates the issues to the support team.
- The support team communicates those issues to the programmers.
- A daily, 20-minute scrum meeting with the Product Owner, support personnel and the Scrum Master.
- A weekly sprint meeting is held to discuss the frequency of repeated issues with the support team and the programmers’ team.
- A monthly sprint review meeting is held between the IT support manager, Programming Team Lead, Support team, and the Programming Team.
nTask is a task management system that is based on the Scrum framework. It is created to facilitate the adoption of Scrum in project planning and process alignment. The following are some of the ways nTask can help you plan and achieve your project goals better.
nTask gives a transparent view of all the projects and corresponding tasks and sub-tasks through its Taskboard. Any project created or modified is communicated to the team, immediately. There is no need for rechecking progress updates, meeting invitations or project reports.
The transparent mode of tasks, being updated, modified or deleted, help the entire team to be fully aware and know exactly what is being accomplished and when. With its Filter option, you can choose to see updates for selected projects based on priority or the task at hand. With the Status option, the status of the selected task can be seen i.e. whether it has started or not, completed or in progress.
The Projects section allows tasks to be defined and assigned by the Product Owner. The update for each task is provided by the assigned team members themselves without a need for the project manager’s request. Each task update is followed up by the team members.
The Activity Logs help define task activities, which can be re-used in the future without having to redefine them. This is especially helpful if the task is required for another project or if needs to be reassigned to another team member.
The Timesheet module allows for effective monitoring and evaluation of project progress. It helps individually asses the timeline for different tasks as well and the milestones reached or pending.
Meeting invitations can be handled through nTask. You may define a fixed time for the meeting or send out a suggested time to the team, to be finalized after team response.
nTask also allows you to note down all the important points discussed in a meeting. The minutes can be then reviewed and published for the rest of the team.
The automated updates on projects, tasks, and meetings cater to better team collaboration and discussion. No time is wasted in the manual arrangement of the project and task follow up, communicating meeting of minutes or project update.
Real-Time Comments provides an easy way to communicate with the team. Whether it is the exchange of information or new ideas, this makes it easy for the team to stay on the same page.
The interdependent tasks are highlighted and each team member can check the updates instantaneously as updated by the other team members. This gives each team member a chance to be aware of the situation and plan the next task, accordingly.
If you are a Scrum Master in an ever evolving IT office, we would love to hear your views. Feel free to drop a question or share your thoughts through the comments section below.
Originally published at https://www.ntaskmanager.com on August 23, 2019.