The concepts of scrum are powerful in business, not only in software development but also in other areas. This post reviews the basics of agile scrum roles, ceremonies, and their impact on developing strategy and managing projects.
Agile Scrum Roles
The scrum team has its origins in rugby, an ultimate team sport. The illustration at right shows the extreme nature of the teamwork!
Here are the key roles that make up the scrum team:
- Product Owner – This key role is the team’s interface with the stakeholders. The Product Owner takes ownership of the requirements – which are not fixed in time. This involves maintaining a close relationship to customer stakeholders to obtain customer feedback (Voice of the Customer) on experience with product features. The Product Owner makes decisions on viability, prioritizing features, and eliminating low value efforts.
- Developers and testers – These folks build the applications in all its features. Often there is no difference in roles between tester and developer – in scrum, developers test and testers develop. The approach is the focus on the priorities and tasks as determined by the Product Owner.
- Scrum Master – This person is not really a team member, but almost an invisible hand to facilitate the smooth functioning of the scrum team. The scrum master is part project manager, part leader, part teacher. The ultimate goal of the Scrum Master is to not be needed anymore – to work himself/herself out of the job by building a strong self-directed team that does not need a Scrum Master anymore.
Building on the roles that people play in the scrums, what do they do? There are a number of specific regular ‘ceremonies’ that are part of the ongoing agile scrum process.
Agile Scrum Ceremonies
- Sprint – This is a time box defined for regular and consistent work cadence and delivery. The most common sprint length is 2 weeks, and in my experience that has been ideal to create a sense of urgency, high level of engagement, and realistic period to accomplish something meaningful.
- Sprint Planning – The planning involves identifying the priority items that the team thinks it can accomplish in the sprint. Sprint planning occurs right at the conclusion of one sprint and just before the next sprint.
- Daily Scrum – This is a regular – usually daily – ‘stand up’ meeting of the team to discuss status. Each team member gets a ‘moment’ to talk about what they accomplished yesterday, what they intend to accomplish today, and any issues they are having. The Daily Scrum is intended to last 15 minutes at most.
- Sprint review – This is a collaborative meeting with stakeholders. It is a key point of collaboration especially for the product owner, seeking feedback and input from the stakeholders. The sprint review covers accomplishments and shortfalls, and usually includes demos of work completed.
- Sprint retrospective – Immediately following releasing deliverables, the team meets to discuss what went well, what fell short, and what can be done to improve in the next sprint.
- Backlog refinement – Also known as backlog grooming, this effort involves going through the backlog of items, like tasks or features, and eliminates, adds, or modifies items based on new points of view learned through recent experience.
The Scrum Master coaches the team through these ceremonies. The Product Owner takes responsibility for the ‘outward facing’ aspects of these ceremonies. The Product Owner interfaces directly with the stakeholders and is the conduit between stakeholders and developers. The developers perform the work.
Agile Scrum and Strategy
The idea of scrum is to allow the team to remain flexible and adaptable as conditions develop. You may have an idea of what customers want from the start, but it needs to be validated with customers. Not only do you need to learn the nuances that might shape what you deliver, but over time – sometime short periods – what customers want changes.
I recommend these strategy resources (paid link):
In the face of change, scrum, with its well-defined roles and processes – provides a degree of certainty and routine that is designed for rapidly changing situations. That’s what makes it so appealing.
Each business has a certain pace of change that it must work within. Some industries, such as construction, change very slowly. Others, like software development, change rapidly. The process for managing products within the company must be aligned as optimally as possible with the pace of change.
The ability for the organization to match these internal processes with the pace of change is a strategic capability! There may even be separate but related capabilities – mapped differently depending upon the demands of each separate environment. The ability to map and adapt better than competitors represents a clear competitive advantage.
My commentary of agile scrum and managing products follows along the same line of thinking.
Agile Scrum and Managing Projects
In the early phases of a startup, the whole company is one project. Getting the adaptability right, and producing minimum viable product (MVP) rapidly to obtain feedback is critical. It can be the difference between being the first to market and falling behind the competition.
In larger companies, projects are organized separate from the operational side of business. This gives the project teams the ability to organize themselves in terms of roles and ceremonies in a way that matches the needs of the project, and not the operations. They can be different.
I recommend these PM templates (paid link):
Programs are driven by strategic goals, and consist of multiple projects. It is entirely possible that for some projects, it will be more appropriate to use a hybrid approach that leans more toward waterfall, where other projects will work better with a hybrid approach that leans toward agile scrum. The decision hinges on the degree of adaptability needed to manage the project.
What is known, and what needs to be learned along the way?
Portfolios can require different approaches in how much they lean toward the waterfall vs agile scrum approach. For example, some projects may support more mature parts of the business, requiring a more waterfall not agile, approach. Other projects may support more developmental efforts, benefiting from an agile scrum approach.
Lucidchart is a tool (paid link) that can help you map and discern the difference among projects in terms of rapidness of change and application of agile scrum.
Conclusion and Further Resources
This post explained the roles and ceremonies of the agile scrum process, and the significance of this approach to strategy and project management.
A question for you: Has agile scrum provided – or could it provide – a strategic advantage to your organization?
The following 2-minute video – presented by Megan Cook, JIRA Software Greoup Product Manager – clearly explains the scrum roles. You can then easily link to further videos on the subject of agile scrum as you desire.