Scrum – Keeping It Simple
In the world of IT, as systems become more powerful and complex, managing these complex systems becomes easier and easier. A big part of what I have dubbed the IT revolution comes from a new group of revolutionaries pushing forward the message that serious does not need to be complex. In the world of agile development, we have been advised that agile does not mean fragile. Today I am going to zoom in to a little old thing called Scrum.
When Scrum was invented and first implemented, it was meant to be a simple framework with few roles, meetings, and artifacts. I now feel no choice but to ask, what in the world happened to the simplicity? As it has evolved, Scrum and agile project management in general have become polluted. I have even heard many agile scrum coaches proclaim that a ‘vanilla Scrum’ implementation will only work in small organizations with simple projects. Although this could be no further from the truth, I still feel the pain from teams who are suffering from being bitten on their Scrum-butts!
All too often, at the direction of someone in an agile management position, we abandon the simple things we know to be true. Whether it is done in an effort to find the holy grail of increased efficiency, or to make the adoption an easier to swallow pill, does that make it all right? Does simple with few rules, roles, and artifacts necessarily mean easy? Where do we draw the line?
In this article, I intend to present why teams choose to struggle with something so simple. Let’s start by taking a walk down Scrum Lane and discussing some of the pieces that people struggle with most.
The first of three concepts we will discuss today is roles. I cannot help but notice that one of the largest questions organizations face as they transition to agile is “where does my role fit into the mix?” People are constantly trying to squeeze what they do into the agile mold, when in fact there are truly only three positions, regardless of agile methodology: Customer, Implementor, and Facilitator. In Scrum, the three roles are Product Owner, Scrum Master, and Team Member. Each role has been called a number of different names, but the simple truth is no matter what HR calls you or what is on your business card, you should fall into one of these three roles. If you do not, it may be time for you to do a serious introspective and identify how you can modify your role to fit better into one of the three identified.
The second concept up for discussion is the correct Scrum meetings. Scrum was founded on the premise of three meetings. The first is the Daily Standup (or Daily Scrum). The daily meeting is a chance for the team to report their progress to each other! This is the perfect time for the team to use subtle pressure to ensure accountability for each individual. The meeting has only three questions for each individual to answer:
1) What have you done since we last met?
2) What are you planning to do until we meet again?
3) Is there anything preventing you from completing the items you committed to?
The meeting is capped at fifteen minutes in length. No problem-solving happens here. The team simply identifies issues and takes them offline to resolve. Attaining the right level of detail is the key to making this meeting successful. This meeting should happen in the same location at the same time, every day without exception.
The second meeting is Sprint Planning. The most common misconception is that no initial preparation takes place prior to this meeting, which is simply not true. Key considerations must be met to achieve success. The product backlog must be properly groomed and backlog items must be ready to be placed into a Sprint. An architectural runway must also be in place for the team to be able to successfully plan for the work. Many people forget these critical steps, and when this falls squarely on the team, the team fails. Effective Sprint planning largely contributes to a team’s success in adopting or implementing Scrum.
The team should meet at the beginning of the Sprint to review the work for the upcoming sprint and break the work down into small tasks and tests. This is a learned art and you should never expect a team to catch everything on the first pass. This meeting should be brief and time-boxed equivalent to one hour per week of your team’s sprint length. Four week sprint = four hour meeting. Proper execution in the Sprint Planning meeting is critical to the team’s success.
The third Scrum meeting is Sprint Review, which includes the demo and retrospective. Of all the Scrum meetings, this one can prove to be the most beneficial to the success of the team. The entire concept of inspection and adaptation rides on the premise that the key stakeholders will have a chance to review what the team has created and to provide instrumental feedback. This feedback is what helps the team stay focused on exceeding the stakeholder’s expectations and allows all key parties to be on the same page. The retrospective is the only opportunity that the team has to inspect and adapt the process. Although at times the meeting may turn toward evaluation of individuals on the team, it is critical to maintain focus on the process and look for ways to prepare an agenda that allows the team to stay focused on delivering meaningful results in the retrospective. The team will be grateful that you helped them stay on track.
The third and final concept to keep Scrum simple is focusing only on the three artifacts. The three Scrum artifacts are as follows:
1) Product Backlog – This should be a well-managed list of work to do in upcoming sprints. The work should be broken down in a manner that makes it easily consumable within a single sprint.
2) Sprint Backlog – This backlog should contain all of the small tasks & tests needed to complete a subset of work from the product backlog. This is the actual work that the team commits to deliver.
3) Burndown Chart – This visual indicator is a constant reminder of the work remaining to be completed as part of the sprint commitment.
I think too often we try to take this very basic framework and overcomplicate it to fit our organizational culture. If we get back to basics, and focus on keeping it simple, we will all re-discover that Scrum is a true flavor of agile project management and it really does work!