Today, our workplaces and deliverables are less predictable than they used to be and now they transcend industries to be more common in manufacturing and construction. In those fields, efficiency is defined as repeatable work controlled by predictable processes and management. In our technologydriven world and knowledgebased workforce, many of those simple, repeatable, wellunderstood processes have been automated, either by machines or technology. That pushes us into more uncertain and unrepeatable work. Uncertainty and ambiguity breed chaos and risk. Tackling all uncertainty is impossible. Capturing and controlling small pieces is more feasible, even if you still won’t have full control. However, some organized or manageable chaos is better than unbridled chaos. This is what Scrum attempts to do.
Scrum tries to take some of that immediate chaos and box it. Wrapped in that timebox is what the team wishes to tackle in a short amount of time. What goes into that proverbial box is a conversation and decision that requires all the right players and representatives, collectively known as the project’s stakeholders. Once a timebox and its contents are determined, then in that short, structured time period, you try to accomplish what needs to be done. Remember, we are working in an unpredictable environment, so what needs to be done, and what we actually want to be done, is in flux and demands feedback. Feedback loops, reflection, checkins, and other mechanisms engaged in the dialogue are struggling to keep chaos at bay while producing the most needed and most valuable products for the project and business.
In a nutshell, that is just one way to look at Scrum really, all of agile project management. Scrum is the most wellknown agile project management approach. I don’t want you to think that the Scrum approach to project management is perfect and without limitations, but we are going to walk through how Scrum tackles the chaos of modern projects without it claiming to have all the answers. Not having all the answers is actually a strength of Scrum. It is what gives it its flexibility and adaptability, and this is how Scrum successfully navigates the uncharted waters. It sets a course for what’s nearest, constantly checks to validate what is the best course, and changes its course as needed. This can only be done with “all hands on deck,” to stay with the ship metaphor for a moment.
The regular assessment of the progress is based on the project’s goals compared to the actual work completed. This allows the project’s direction to be reoriented or adjusted. You’ll base the new direction on what has been done, instead of basing it on speculation or the plan that was created from predictions at the beginning.
There are too many unknowns at the start of these kinds of projects. Day One is our dumbest day. We are going to learn more and be able to do more and make better decisions as we get further into our project. A foundational view in Scrum is that trying to predict and plan everything on Day One is fruitless.
The common staging of projects — with requirements gathering, designing, developing, integrating, testing, and deployment, or some variation thereof — is not productive if we have no way of knowing what is going to happen along the way. Instead of trying to predict everything and have it cascade through a series of predetermined stages, we mix all the stages together. Then we’ll break the mix into fixed timed iterations called “sprints.”
From the start, we are attempting to produce a workable and shippable product. We must start out small and build on it. We clear the fog and gain clarity on what is or is not needed. That discovery is accomplished by presenting small or broad highlevel product. Customers are much better at articulating what they need or want with something tangible. I have worked with customers too many times who think they know what they want, but they are basing that on something else they have seen or done. They don’t know how to see it differently. They don’t know what they really want until they see ideas come to life — whether the ideas are way off target or close to their expectations. Although he probably never said it, I like a quote attributed to Henry Ford, which I feel is appropriate here, “If I asked customers what they wanted, they would have said a faster horse.”
Think of it more as gaining real world progress, instead of laying out a predictable forecast and progressing in a linear fashion. Divide the work in short regular bursts over longer unchecked timevariant work periods.
When attempting to control chaos, you cannot inject more chaos. Scrum has some basic rules and structures that individuals and teams can tweak to fit their own needs, but in many situations the Scrum methodology runs a certain way to maintain the desired chaos level.
Scrum Roles and Responsibilities:
Who is involved in Scrum agile projects? What is everyone’s responsibility and role? The answers are fairly straightforward. There are only three roles in Scrum:
- Product owner
- Scrum development team
These roles each have their specific responsibilities and expectations.
The product owner is the one person who looks out for and makes certain the project is reaching its highest value. He or she must make sure the return on investment, or ROI, is fully maximized. The development effort and overall project must meet economic and business justifications.
The product owner is the voice of the customer and the business. He or she is responsible for setting and updating the product vision. Having the clearest sense of the product’s objectives and the various stakeholder interests and expectations, the owner is best suited to prioritize the product backlog. He or she will constantly reprioritize the product backlog as the project advances and adjust it to longterm expectations, such as release plans. The owner will also ensure the backlog is accurate and current. He or she helps the Scrum team understand the purpose, value, and reason for the backlog items. To ensure this knowledge is accessible and up to date, the product owner also seeks ways to increase visibility and transparency.
Additionally, because he or she is the owner of product vision and backlog, the owner is the final arbiter of questions and debates around the requirements — which are bound to come up throughout the development of the product. As we are coding the need, it is easy for us to get pigeonholed on a particular aspect or function. We may be unclear on the bigger need or how exactly a requirement is to be understood or incorporated. The product owner provides the correct guidance so that we can be confident that the interpretations are meeting the expected value and business need. That is the role product owners serve — to make certain the highlevel longterm vision and the analysis of the business aims are reflected on the work being planned and performed.
Since he or she holds the clearest understanding of what the product is meant to accomplish, the product owner will accept or reject the product increments. Likewise, the product owner must make the decision on whether to ship the product. In such cases, he or she might be forced with the decision to either continue development or discontinue the project.
They may contribute to the project as a team member, but they hold more of a leadership role in the team dynamics. The Scrum development team encompasses a majority of the individuals on a Scrum project. They are the crossfunctional professionals who build the project’s product. Cross functional means they represent skill sets of testers, business analysts, domain experts, and of course, those who traditionally fall under the development or developer category. This is critical due to the blending of what is common in waterfall or traditional project management phases of separating the work. The various jobs are either done concurrently or accomplished some time during the iteration — or in Scrum methodology terminology, the sprint.
The Scrum development team typically consists of about seven individuals — plus or minus two — self organized around the work. They are not assigned external roles or micromanaged. They have the autonomy to reach commitments negotiated with the product owner for the next closest iteration sprint. The needs of a sprint may change from one sprint to another throughout production. Consequently, the members of the Scrum development team may differ based on the needs at hand. Ideally, the teams whose members stay relatively consistent and are involved long term are the most productive. Scrum tries not to move people or split members between teams, but if needed for the project or sprint, then it’s what must be done.
The most effective Scrum development teams are those that are collocated. Collocating the team to be near each other — ideally in the same room or physical space — has many benefits. Collocating encourages collaboration, more team engagement, and small informal learning opportunities.
This learning is referred to as “osmotic learning.” I personally feel that this is the most impactful part of having teams collocated. I have been on project teams where we have been set up in a large room with flexible seating. The spontaneous conversations that emerge in that environment are invaluable. If you are separated and isolated, there is no flow of information. When I have been on projects where I have been completely disconnected physically from the rest of my team, I missed out on a lot of important discussions and exchanges of information. For me to have been privy to the information shared, there had to be a cognizant effort by a project team member to write down what was discussed and share it with me. Typically that would be via email. But for them to take that step, the team members would have to think about everyone that needs the information, how to translate it to text, and mail it out. Little bits of information or wisdom may not be shared.
If you and I are having a conversation, we each learn from it and retain the information. We might not think about others who were not part of the same conversation. We may decide to share the conversation with others on the team, but some people complain about getting too many emails and then push back on that method of communication. I will usually choose too much communication over no or incomplete communication, but that is a discussion for another time and another course.
Osmotic communication may not seem like much, but to give one last example, I can recall a particular situation where I was fortunate enough to be collocated on an agile project. Two of the developers had moved over a whiteboard in our shared room to brainstorm and debate alternatives for how to design what the project was working on. Historically, only the results from such a discussion would have been shared; in some projects it wouldn’t have been shared at all if it had been determined not important to my role or someone didn’t take the time to share it. But having that background knowledge was unbelievably beneficial to me and my work on the project.
The third, and last, role in Scrum agile project management is the ScrumMaster. You can probably tell that the title was invented by the creators of the Scrum methodology. The person in this role is essentially the steward of the Scrum project management processes and methods. He or she facilitates the processes of Scrum to fulfill the project’s needs, with heavy attention to the enforcement of timeboxes. The ScrumMaster makes sure that the Scrum processes and their purposes are understood by the team and the product owner, in some cases explaining aspects of Scrum to those outside the project.
Think of ScrumMasters as assistant coaches. They work to make certain the product owner is able to do the work needed on the backlog. They communicate as much as needed. They create the best, most efficient environment so the Scrum development team can be as productive as possible. The ScrumMaster works to remove or deflect impediments which may distract, slow down, or block the Scrum development team from accomplishing their work. That may even extend to shielding the team from external interference. A ScrumMaster wants to keep the team “in the zone.”
Like the other roles, the ScrumMaster holds a leadership role, though he or she has no management authority over the team. A ScrumMaster works for the team, not the other way around. As a servant leader, the ScrumMaster facilitates and guides, and does not direct and reprimand.
The roles of product owner, Scrum development team, and ScrumMaster are the only three roles in the Scrum agile project management methodology. Next we’ll discuss what events happen in a Scrum project.
There are a few events that occur in Scrum project management:
- Sprint planning meeting
- Daily scrum
- Sprint review
- Sprint retrospective
- Backlog refinement meeting
Imagine you are part of an agile team working on an app for your company. The app will support many of the features and activities currently used by employees of the company and various departments. Different employees and departments are going to use some of the same features, but there will also be some features that are unique to the department or individual. For simplicity’s sake, the company you work for is called LearnSmart and the project is codenamed SMART.
There are a series of meetings necessary to coordinate our implementation of Scrum. You are the ScrumMaster. You attend all the meetings and facilitate them, but you have no decision making authority at these meetings.
At the start of each sprint, there is a sprint planning meeting. Here is where the product owner and the Scrum development team try to figure out what items on the product backlog can become a workable product by the end of the sprint.
Sam is the product owner for this SMART app project. He is responsible for communicating which of the product backlog items are the most important from the perspective of the business. In this sprint, Sam is presenting items related to getting users — a.k.a. company employees — to login and see their points and status compared to other employees.
The Scrum development team consists of Jasmine, Janet, and Joe. They negotiate with the product owner on the amount of work they can realistically implement during the timebox without accruing technical debt. Technical debt is the stuff in and around the work which becomes hard to remove later, or impedes its ability to become “Quality.”
The amount that gets done during the sprint can vary based on the team, the backlog items, and many other factors. Not every sprint contains the same number of backlog items. Therefore, the sprint planning meeting is critical to determine what is reasonable during the upcoming sprint using the information of past performance, expectations of future performance, and what the team believes can create a potentially shippable product before the sprint concludes. This sprint goal keeps the team focused and coherent on the initiative at hand in this increment.
During the sprint time period, 15 minutes are set aside every single day to synchronize activities and create a plan for the next daily cycle. These daily meetings are sometimes referred to as “standup meetings,” because they are ideally conducted standing up. Research has shown that the most effective meetings are those that take place standing up. When people are standing, they are more engaged and active. Sitting down roots people in place and makes them passive. The primary benefit of these meetings is to make sure the meetings don’t take too long. When people are too relaxed and passive, it is easy for them to let the conversation linger and there is no urgency to move on. I said to set 15 minutes aside, but the goal is to not take all that time. If you are efficient in your daily scrums, you find that 15 minutes or less is plenty. When you first start out, staying within that time is difficult, but you must stay disciplined and keep the meeting moving. That is your role as ScrumMaster. You are responsible to keep things efficient.
These daily Scrum meetings are meant to be quick. We can use football for this analogy, which we will. In a football huddle, the team quickly convenes in a tight group. Usually standing. They may talk about what happened in the previous play; but most of the conversation is about what must happen in the next play. They are thinking about the next play and maybe what the next series of plays may be. Like in football, a development Scrum team does not necessarily know where they will be after the upcoming play or day. They have plans and desires to be at a certain point at the end of the upcoming day, but things may not go as planned. Reconvening quickly every day aligns the team and the product owner, and preps them for the upcoming day.
Unlike football huddles, which can vary drastically in timing, daily scrums should be held at the same time and in the same location every day. This creates consistency and reduces complexity. It becomes an ingrained habit in everyone’s minds and actions and ensures that the meetings are regularly attended. Once there is a day with no daily scrum held, we’ll see that important component of agile project management crumble.
To make sure you get the best attendance at the daily scrum, you must keep them punctual and timely, but more importantly, effectual. No time wasting, no side stories. Keep everyone on subject. Everyone wants to be working. The sprint can be an exciting time and you want to keep things moving. In which case, the discussions revolve around three simple questions that each Scrum development team explains in turn.
- What did I do yesterday that helped the development team meet the sprint goal?
- What will I do today to help the development team meet the sprint goal?
- What impediments do I see that can prevent me or the development team from meeting the sprint goal?
Any other comments, discussions, or outlying conversations can be tabled until after everyone has had an opportunity to answer those three questions. When those conversation topics are brought back up, the daily scrum is technically over. Those who are not involved in the side conversations are free to leave and continue their work.
The development team improves their communications and reduces the need for additional meetings by having these daily scrum meetings. Through daily meetings they see the trends, work together to identify can remove any blockages, and constantly leverage the power of selforganizing teams. Say, for instance, Jasmine on the Scrum development team has run into a problem on what access is necessary to obtain certain data in the database. The team and ScrumMaster can work together to remove that impediment. The team can also adjust and adapt as needed. If Janet already has permission for the data in the database, she can offer to pull in the requested data. If team members were working completely on their own with little interaction, this simple solution may not have emerged. Jasmine may have spent additional days trying to gain access, instead of utilizing this daily platform to share and support. The sharing of information and knowledge is crucial to a wellfunctioning team.
As the ScrumMaster, you organize and lead the daily scrum. You do not participate in the same manner as the development team members; instead, you enforce the rules and make sure the scrum meets its intended aims.
Once the sprint has reached its predetermined end, an inspection of the increment is needed. During this informal meeting, all the project stakeholders, including the Scrum development team, the ScrumMaster, product owner, and others representing the business or customer, collaborate on what was done in the sprint. The sprint review meeting is not a status meeting. The sprint review meeting is a presentation of what occurred in the increment to gain feedback and foster more collaboration.
The sprint review is typically a fourhour meeting for a one month sprint. Longer sprints have longer reviews and shorter sprints mean shorter sprint review sessions.
As the sprint development team presents the product or progresses in a build, they answer any questions and provide insight into the development. The product owner evaluates and decides which of the done work is truly “done” and what remains “not done.” The team with the product owner discusses what must still be done on the product backlog and what will be done next.
The sprint retrospective session is held before another sprint starts. The Scrum team as a whole looks back at how the sprint went. This is a chance to audit their processes, procedures, tools, and relationships to find improvements. This is especially powerful when you are first starting out, but equally important for all sprints and all teams. There is always something to learn and something to improve. Even more so, it is a time to celebrate what is working well and has improved. It is a look back at what went well and what can be done. Sometimes the things that went well are also the things that can be improved.