Some Common Questions about Scrum
As Agile methods go, Scrum is unusual. It deliberately challenges the individual and the organization to become disciplined in their approach to software development. It is deliberately non-prescriptive, making it easy to understand its framework while simultaneously demanding a great deal of focus and involvement if you take it on. It does not talk about writing software, because the people who put the framework together knew that if you were to get your people working together first, those people would organize the best development practices for them and make it work because they were empowered to make those decisions. Even well-known and experienced Agilists still draw comparisons between Scrum teams and XP teams saying that XP teams are better because Scrum doesn't provide the development structure necessary to create and maintain high quality code and XP does. Scrum, when properly taught, emphasizes the fact that a solid engineering infrastructure and solid engineering practices are required to get a good result. More importantly, Scrum emphasizes the "people" aspect of software development. That might explain why there are so many more Scrum teams in the world than XP teams. Regardless, when I coach an organization in the implementation of Scrum, I also discuss with the organization their testing and integration practices. I always implement Scrum as a team and work management framework using XP practices like test-driven development, continuous integration, continuous testing, pair programming, collective code ownership, customers on the team, user stories, etc. as a means of creating the solid engineering practices and infrastructure that are necessary.
This article discusses some common issues about Scrum and answers common questions about when Scrum should be used and what options solve certain predictable problems.
Is Scrum of Value with Pure Infrastructure or COTS Software Projects?
Absolutely; Scrum is not about writing software (even though that's the environment it grew up in). In fact, Scrum is frequently used in non-software development environments (see "About Agile Development, Using Scrum in Non-Software Development Environments"). Scrum is about teams collaborating to get the right things done in the right order. The Product Owner defines the right order and "what" the right things consist of. The team decides how things will get built (or get done). For infrastructure and commercial-off-the-shelf projects, just because the team isn't writing software doesn't mean that the same principles can't apply
When is Scrum Not a Methodology to Use?
I have not yet found a project that wouldn't benefit from the collaboration, value-focus, and customer-orientation brought to projects by methods like Scrum. However, technically, there are projects where the benefits of Scrum aren't realized nearly as much as in others.
Fundamentally, products (like many other systems) fall into one of four realms of "hardness" based on how well we understand the technology employed by the product and how well we understand the product's requirements. Products can be:
- Simple. Both the technology and the requirements are clearly understood
- Complicated. Either the technology or the requirements are less than clearly understood
- Complex. Either the technology or the requirements are not understood (or both are not clearly understood)
- Anarchic. Neither the technology NOR the requirements are understood.
The benefits of Scrum are more obviously realized when developing a product that is either complicated (difficult to understand) or complex (large and difficult to predict). There are no methods I'm aware of that function well in the anarchic space.
For products that are simple (easy to understand and predict), Scrum works, but many other methods (including waterfall) would work just as effectively. When the technology is clear and the requirements don't change, developers can estimate and predict with improved effectiveness and there is considerably less likelihood of rework resulting from making design decisions earlier than necessary.
To put it more succinctly, waterfall processes work fine when working on a project where the requirements change EXTREMELY little (bordering on "not at all") and where the technology is COMPLETELY understood and very unlikely to cause any unexpected difficulties. In my years working as an information technology professional, I've run across only a few instances of projects that meet the criteria of no requirements change and completely understood technology. One good example I can use where waterfall worked nearly as well as Scrum is in the case of a team that reported to me, their manager, several years ago.
This team of eight was responsible for building transaction-based interfaces between the various products that communicated with "our" product. The number of interfaces was substantialthere were at least fifteen different types of interfaces and at least ten vendors for each type of interface so, between the active interfaces and the interfaces we were still supporting, we had a library of well over four hundred interfaces. Now, these interfaces were pretty much all driven by tools in our product and most of them followed a popular "standardized" protocol that all of the vendors in the marketplace were beginning to support. In fact, because of the tools and the standardization, building interfaces very quickly became a matter of agreeing on which events were to be supported and which transaction segments were to be supported (data elements themselves became less and less of a problemif a vendor didn't support a data element, it simply ignored it). This team's projects, building interfaces, became a matter of understanding how the vendor supported the standard protocol, and then making (usually) minor modifications to create the interface. In other words, the requirements (the interface structure) became very known and the tools became very predictable. For this team at that time, waterfall would have worked just as well as Scrum, because everything they did was a known and predictable activityvery few surprises occurred during interface development.
Does The Product Backlog Contain All Requirements/Stories?
The Product Backlog is defined as a prioritized list of items that identify valuable work to be done to the product. We put our features here, our defects here (sometimes), and all of the rest of the work that we need to do in order to build the product (test environment set-ups, analysis stories, third party package upgrades, product-specific training, etc.). To that end, the Product Backlog is the root of all of the work that we do. But even within this definition of the product backlog, we recognize that not everything is known about a given item until after the Scrum team has actually built the item. In other words, we learn more and more about the items on the product backlog, up to and during Sprint Planning and even during the Sprint when the item in question is under construction.
The fact that the content of the product backlog cannot be accurately understood until after construction begins affirms the emergent nature of the Product Backlog as well as the concepts set forth in the Uncertainty Principle of Software Development to wit, that the requirements of an application cannot ever be completely known until it is built.
So, the Product Backlog is, in fact, the root source of ALL work to be done on a product, and thus the root source of all requirements that are eventually identified during construction. However, the Product Backlog may not, in and of itself, identify or embody all of those requirements at the beginning of the project simply because many of the requirements not initially known are identified during Sprint Planning and during the Sprint.
Does Using Scrum Mean There's No Reason For Management?
I think the short answer to this question is an emphatic "No!" Given the primary functions of management: staffing, budgeting, controlling -- one need only look at the Scrum framework to see that none of those functions appear in Scrum. Without management, there would be no one to handle the bringing on of new employees. Even if the team plays a significant role in interviewing and approving candidates, it makes no sense for the Scrum team to handle the follow up work that is necessary to do once a new employee is hired. When an employee doesn't perform well on one Scrum team, who is going to evaluate the situation to see if, perhaps, the employee might work better on a different team or should simply be discharged? The Scrum team? I'm pretty sure that would constitute a conflict of interest.
More importantly, management plays a significant role in supporting Scrum teams by helping remove obstacles, by communicating business strategies and policies to the employee population in a consistent manner, by providing a "bigger picture" perspective for employees, by helping individual employees improve their skill set or resolve personal problems, and simply by handling all of the day to day administration that keeps the business going. Like the Scrum Master, nearly everything the manager does is geared toward keeping the Scrum teams highly focused and highly productive.
At the same time, no discussion on this topic would be complete without talking about the role of management with regard to a Scrum team. It is important to review the impact that a manager can have on a Scrum team. When providing support to a Scrum team (removing obstacles, resolving conflict, providing administrative assistance), a manager can be a positive influence on the proper functioning of the team. On the other hand, when a manager gets involved in the daily discussion and decision making of the team, he or she can inadvertently sap the self-managing function of the team. As a manager, one continuously walks a thin line between trying to provide support to the team and trying to avoid having the team (willingly or unwillingly) turnover their empowerment.
Here's a list of DOs and DONTs that managers can apply to help them properly work with Scrum teams:
- DO ensure that Scrum teams know what they are building and why. If they don't have a clear understanding, ask the Product Owner to fill them in.
- DO respect the Scrum process. Don't schedule meetings when the team is supposed to be doing Sprint Planning, Daily Scrums, Sprint Reviews, or Sprint Retrospective meetings.
- DO come into the office on time each morning and leave on time in the afternoon. Don't expect your employees to work a full day if they think you aren't.
- DO discourage gossip and rumors. They waste time and distract employees from getting work done.
- DO set high standards for your behavior toward employees and hold to those standards at all times.
- DO ensure that teams have the training they need to get the job done.
- DO ensure that YOU have the training you need to get the job done.
- DO build rapport with teams through honesty and professionalism. Don't try to win them over by sharing your weaknesses and fears.
- DO help teams understand the nature of the commitment they make at Sprint Planning. Say things like, "Do you truly believe you can finish this, at a high level of quality, by the end of the iteration?" "Do you really feel committed?"
- DO encourage others to admit their part in mistakes and allow them to learn from those mistakes.
- DO steer teams in the right direction if you feel they've missed an important element in their solution.
- DO support individuals who do not seem to understand agile practices or teamwork. Coach them toward better performance, but always be prepared to look for better options for the individual.
- DO support the team when they ask for help.
- DO coach teams to improve their performance.
- DO coach teams to efficiently make sound decisions.
- DON'T keep secrets from your staff. They know when you're doing it and they probably know what it is you aren't telling them.
- DON'T worry about under-commitment. If the team can do more, they have a backlog of items they can go to for more work.
- DON'T blame others for your mistakes. Take responsibility for your part in mistakes.
- DON'T teach. You can lead, share, encourage and stimulate team members to grow, develop and learn.
- DON'T take responsibility for your team's commitment.
- DON'T make decisions for teams.
- DON'T solve team's problems for them; that's what you hired THEM to do.
- DON'T take over if your team makes a mistake; encourage them to understand what they did wrong and to find a way to do it more effectively.
- DON'T participate in daily Scrums. You have to wait your turn after the daily Scrum is over, just like everyone else who isn't on the Scrum team.
Read more IT Performance Improvement
Certain names and logos on this page and others may constitute trademarks, servicemarks, or tradenames of
Taylor & Francis LLC. Copyright © 20082012 Taylor & Francis LLC. All rights reserved.