(Another) Intro to Scrum and Agile
How Scrum improves client and team satisfaction
How Scrum improves client and team satisfaction
Software development presents a variety of new challenges that traditional project management (waterfall) styles struggle to overcome. Scrum is a product development methodology developed in 2002, a year after the Agile manifesto was released. In this post, I'll be looking at what Scrum is and the possible benefits of following the methodology.
Introduction to Scrum and Agile
The Agile framework was born in 2001, when 17 software developers met in Utah to develop and publish the Manifesto for Agile Software Development. This outlines a set of principles for product development created by people intimately familiar with the specific challenges of building software. The Agile methodology relies on experimentation, observation, and a resultant adjustment of team practices to optimize for team productivity. In many ways it is the spiritual successor to kaizen, the principle which Toyota developed in World War II.
The Four Agile Values
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Source: http://agilemanifesto.org/
The Twelve Agile Principles
- Customer satisfaction through early and continuous software delivery — Customers are happier when they receive working software at regular intervals, rather than waiting extended periods of time between releases.
- Accommodate changing requirements throughout the development process — The ability to avoid delays when a requirement or feature request changes.
- Frequent delivery of working software — Scrum accommodates this principle since the team operates in software sprints or iterations that ensure regular delivery of working software.
- Collaboration between the business stakeholders and developers throughout the project — Better decisions are made when the business and technical team are aligned.
- Support, trust, and motivate the people involved — Motivated teams are more likely to deliver their best work than unhappy teams.
- Enable face-to-face interactions — Communication is more successful when development teams are co-located.
- Working software is the primary measure of progress — Delivering functional software to the customer is the ultimate factor that measures progress.
- Agile processes to support a consistent development pace — Teams establish a repeatable and maintainable speed at which they can deliver working software, and they repeat it with each release.
- Attention to technical detail and design enhances agility — The right skills and good design ensures the team can maintain the pace, constantly improve the product, and sustain change.
- Simplicity — Develop just enough to get the job done for right now.
- Self-organizing teams encourage great architectures, requirements, and designs — Skilled and motivated team members who have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products.
- Regular reflections on how to become more effective — Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently.
Source: https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/
Not all of the agile principles are needed or even helpful in all situations. For instance, co-location is an agile principle, but many agile companies do not practice this. Considering how technology has evolved since 2001. Our degree of connectivity allows for ways to compensate for not being co-located. But others — such as maintaining a sustainable development pace — do more than just maximize effectiveness, they can help team members find more satisfaction and enjoyment in their jobs.
Agile vs Scrum
Scrum is an process by which teams can practice being agile. Scrum proscribes four ceremonies — sprint planning, standup, sprint review, and sprint retrospective, as well as three roles — team member, scrum master, and product owner. In addition to scrum, there are a number of other processes which can enable teams to be agile. These include Extreme Programming and Behavior-Driven Development.
Scrum roles
There are three possible roles for members of a scrum team.
Team members
Team members are all the regular members of a team who aren't doing administrative work . This includes primarily developers, designers, and quality assurance engineers. These are the people whose primary objective is to complete the tasks which the team has agreed to complete during the scrum. They are the ones doing the work that leads to a successful product iteration.
Scrum master
The scrum master’s job is to facilitate standups and other scrum ceremonies, such as retrospectives. They identify obstacles team members face and help remove those obstacles. The scrum master may also support the product owner in tasks such as maintaining the backlog and facilitating communication between the team and stakeholders.
Product Owner
The product owner is the person solely responsible for managing the product backlog. This includes writing descriptions of backlog items (stories), deciding on the prioritization of items, and ensuring that team members understand items in the product backlog. The product owner understands the product roadmap better than anyone. They are responsible for providing visibility into the product direction for team members and stakeholders alike.
Stakeholders
Stakeholders include both the rest of the company the team belongs to (internal stakeholders) as well as the general public who will use the software (external stakeholders). Stakeholders aren’t a scrum role themselves, because they are not part of the scrum team. Stakeholders provide valuable input that should help elucidate what the team is making, why the team is doing the work it’s doing, and how the work should be done. Stakeholders are mentioned in the first and the fourth of the twelve scrum principles:
- 4. Customer satisfaction through early and continuous software delivery
- 12. Collaboration between the business stakeholders and developers throughout the project
Product Planning
In agile and scrum, the product backlog is the one source of truth for what work the team will be doing. By spending time grooming the backlog, the product owner develops a clear roadmap for the product or collection of related products. The product is defined as something (physical or not physical) created through a process that provides benefit to a market.
By clearly defining each of the products which make up the product offerings a team is responsible for, the team can derive the highest value benefit from each product. Following a Value vs Complexitya> prioritization framework or order the backlog, the product owner can maximize the value which the team wishes to deliver. There’s much more to say about this topic, which will be left for another time. But to be sure, product planning is one of the most crucial influences on the eighth principle of agile, supporting a consistent development pace. This then leads back to the third principle of agile, frequent delivery of working software.
Workflow / Scrum Ceremonies
A sprint is a time-boxed, or time-constrained, period of time. It’s typically two weeks but can be anywhere between one and four weeks. In each sprint, a team will commit to completing a collection of work. These are represented by units (tasks) from the top of the product backlog. Two week sprints work well when they start on a Monday and end on a Friday. Ending a sprint on a Friday allows team members to have two days where they don’t need to carry a thread from one week to the next.
During sprint planning, team members will the average number of points a team completes every sprint is called the velocity. Using relative velocity as a metric for planning, the amount of effort future feature development will take can become clearer. Identifying and understanding current velocity enables more accurate long term product planning to take place.
The Scrum process uses scrum boards. One major benefit of using scrum boards is that it helps internal stakeholders to quickly see the progress of any task in the scrum, without having to request for an update from the team members who are working hard developing.
Scrum proscribes four ceremonies, meaning four types of regular meetings the team uses. They are sprint planning, the daily scrum (standup), sprint review, and sprint retrospective.
Sprint Planning
Sprint planning happens at the beginning of a sprint. It involves going through the backlog items (also known as tasks, issues, or stories) as a team. For each item, team members collaborate to clarify the intent of the task, assign it a difficult value, and decide which tasks to take into the upcoming sprint. This process forms a commitment that the team makes to complete the sum of that work by the end of the sprint. This should include consideration of how much ad hoc work is expected. Ad hoc work could include bug fixes or high-priority issues which shouldn't be delayed. Planning for steady and sustainable work loads leads to greater satisfaction and clearer expectations.
Daily Scrum (standup)
The daily scrum is when team members get together and cover three points each:
- What did I do yesterday?
- What am I planning to do today?
- What obstacles do I have, if any, which might prevent the timely completion of my work?
The daily scrum is called stand-up because in co-located teams, the idea is that standing for longer than 15 minutes is fatiguing. The scrum team is ideally sized at 7 people ± 2. With that in consideration, each member should spend less than two minutes on these three points. In smaller teams, standups should be even shorter than 15 minutes, rather than team members talking for longer. Standup is the ideal point to eliminate obstacles that team members are facing and connect team members with each other to facilitate collaborative problem solving.
The scrum master’s primary role is centered around the daily scrum. The scrum master facilitates standup by queuing up team members to speak. When a team member starts going into too great of detail on any given topic, the scrum master should politely interrupt to keep the meeting focused on the three standup questions. After each person has responded to the three questions the standup should end. During their individual reports, team members can make plans to have follow-up meetings after the standup ends. Team members may or may not want to have smaller meetings to go more in detail on a topic. If they don't, they may leave to go back to work. This avoids time spent in meetings which don't directly affect individuals, giving them more time to work on their primary responsibilities.
Sprint Review
Sprint review happens directly following the end of the sprint. During the sprint review, the team looks at the work that was completed during the sprint as well as their velocity. This is the time for the team to identify if they accomplished everything they had committed to during the last sprint planning meaning. If the team has accomplished significantly more or less than expected, save the conversation about why that happened for the retrospective. Sprint review Then, that information can be taken into consideration when deciding how much work to take on in the next sprint planning meeting.
Sprint Retrospective
The sprint retrospective is one of the more unique features of scrum as opposed to other frameworks. Retrospective is a time for the team to identify what worked well and what didn't work well in the last sprint. There are a number of conceptual frameworks by which retrospectives can be run. Let me know in a comment if you are interested in reading more about different frameworks for retrospectives. In my favorite method (LLLI), every team member as well as the product owner should answer the following questions:
- Liked - What did you like?
- Learned - What did you learn?
- Lacked - What did you lack?
- Improvement - What's a way you could improve
This is the principal way in which a scrum team can practice the final agile principle, Regular reflections on how to become more effective. This is the secret weapon of scrum to help teams practice kaizen, seeking for continuous improvement. When team members have the support, trust, and motivation that the fifth agile principle references, retrospectives can be a powerful vehicle for team growth and professional development.
Supporting developers
By clearly defining roles, interactions between the various people involved in the development process can be optimized. For the most part, and product owner and scrum master are the channels through which the team can interact with stakeholders. By providing a clear process and points of contact for people outside of the team, team members themselves are provided with a great gift — long periods of uninterrupted development time. The American Montessori Association explains the value of uninterrupted work periods. While it’s meant in the context of children, it may also be applicable to adults.
[An] uninterrupted work period is vitally important, as that is when the building of coordination, concentration, independence and order, and the assimilation of information are able to occur.