In my previous project management column, I discussed the three critical roles in a Scrum team: the ScrumMaster, the product owner, and the development team. In this installment, I will focus on the ceremonies (also known as activities) common to every Scrum project. But first, it's important to understand the agile concept of ceremony.
What is ceremony in agile projects?
Every project has two elements: the content (what you commit to achieve, such as writing software or implementing virtualization) and the process (the activities you perform to keep the content work on track, such as updating Gantt charts and writing status reports). In the most general sense, when agile practitioners talk about project ceremony, we're referring to the process actions.
Agile zealots often refer to ceremony in a negative sense, inferring that these activities are rituals because they've always been done and not because the activities add value to the project. Ceremony is also used in a more neutral sense (as I do in this column) to simply mean those process activities you must perform to keep your development work on track. Traditional project approaches are referred to as "high ceremony," and the idea of shedding ceremonies that don't add value is central to the agile philosophy; this is captured in the principle to "maximize the work not done."
Disciplined agile delivery teams provide repeatable results by adopting just the right amount of ceremony for the situation which they face.
This definition illustrates the mainstream of agile thinking today, that each unique project requires teams to determine the right amount of process for the particular situation, to adapt the best elements of agile and traditional methods for the culture, the product, the team, and the circumstances.
The three ceremonies
In Scrum, we manage the activities of our collaborative team by performing three key ceremonies: Sprint Planning, Sprint Review, and the Daily Meeting.Sprint Planning
Every business project, regardless of whether it's agile, begins when a project sponsor has an idea for a new or an enhanced business function. As every IT professional or consultant knows, these project ideas can start in a very ambiguous and unformed manner, with the potential sponsor having only the vaguest of ideas about what they want and what it might look like.
Most agile teams utilize some type of envisioning process, in which they work with the product owner and other stakeholders to define the broad goals and business drivers for the project. This broad outline is then refined iteratively into stories (or features), and once these stories are fleshed out (as discussed in my previous column about Scrum), the team can begin the work of prioritizing features and determining where in the series of iterations, or sprints, they might best fit.
Once the backlog is determined, it's typically recorded on a simple chart or a whiteboard or in a planning application such as ScrumWorks. The ScrumMaster, the product owner, the team, and the collaborators will usually work together in a facilitated session to determine where in the overall product roadmap various features might fit. The determination of best placement for a particular feature is often made based on business value, with those features that are expected to deliver the most visible and compelling value first. This is not the only criteria, however; sometimes it makes sense to prioritize the most difficult technical elements first, as a sort of feasibility exercise, to ensure that they will actually work as expected.
When scrum teams select features to include in the initial sprint, they pay close attention to the team's size and capabilities, the amount of ceremony and reporting activity required for the environment, and the business value considerations I discussed above. It's also important to consider the fact that early iterations act as a showcase of the entire project and can be important to building credibility and momentum for the project within the organization. When preparing for the first sprint, politically savvy Scrum teams will show the stakeholders something that illustrates why they're investing in this project in the first place.Daily Meeting
The Daily Meeting is an integral part of most agile approaches and follows a well-known pattern. These sessions typically have a strict time limit; in the case of a strict Scrum environment, the sessions are expected to run only 15 minutes. The Daily Meetings are designed for status only and are prohibited from becoming problem-solving or planning sessions. These sessions are designed to allow each team member to explain three status items to the rest of the team:
- what they accomplished since the last meeting;
- what they intend to accomplish before the next meeting; and
- what impediments they've found or expect to encounter.
Anyone can attend this meeting, but only team members who have committed to deliver work contribute; everyone else is only an observer. This daily status session gives all team members, the ScrumMaster, and the product owner the chance to make any required course corrections on a daily basis, thus keeping the project under control.Sprint Review A guiding principle of agile methods is the feedback loop, and agile practitioners stress the importance of continuously improving the content we deliver, and the process we use to deliver it.
If you're familiar with Extreme Programming, for example, you'll recognize the concept of refactoring, which requires developers to review their work and ensure that it is as tight, elegant, and clear as possible, to ensure maintainability and performance. This idea of refactoring is applied to this process as well, as Scrum teams use the Review Meeting as an opportunity to evaluate the work done so far and the practices and the techniques they used to develop those deliverables.
Sprint Reviews are typically time-boxed to a maximum of four hours and include the product owner and the interested stakeholders, so they can evaluate the suitability of the product to date. This is also the forum for discussing changes in the market, the technology, or the business value proposition that may affect the effort, and for possibly correcting the project's course to ensure that it is still on track to deliver the business benefits envisioned upfront.
It's important to remember the underlying intent of agile methods: to ensure that we deliver the right product for the current need, not the need that existed when we began the project. Applying this idea requires Scrum teams to be open to, and embrace, changes that make sense based on transformations in the business or in the marketplace.
These three ceremonies are clearly more than ceremonial. The ceremonies act as the indispensable glue that keeps the team working in concert to deliver the right product for the environment, without the overwhelming process and procedure that can strangle the creativity out of a project effort.
Next time, I'll look at the three essential tools required to keep the team and the stakeholder community informed of our progress and to ensure that all participants understand the overall effort and their roles and dependencies. I'll also provide insight into real-world applications of these ideas.Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!
Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile practices and migrate successfully.