Scrum/Agile Frequently Asked Questions (FAQ)

Q: I am the CTO of a small company I helped start and one of the more experi
enced developers there. Unfortunately I'm also one of the main voices in employe
e performance appraisals and hiring/firing decisions. I would like to have the b
enefits of a self-organizing team, but a couple people on the team have told me
they'd like me to attend their standup meetings and contribute to technical deci
sions. Does Scrum prohibit this?
A: My guess is that the benefits of attending outweigh the drawbacks in your
case. But instead of prescribing an answer, I'll recommend your Scrum Master us
e this process to find out: Conduct an anonymous safety check (as described in M
odule 6: The Sprint Retrospective Meeting) and raise the question with the team.
I'd also consider trying it which ever way you haven't been doing it for one Sp
rint, as we tend to overestimate what we know beforehand.
Q: What should we do if the Scrum Master and Product Owner are the same pers
on?
A: As far as I know, the Scrum Police aren't going to break down your door i
f you do this. But if those two roles are combined, it would be more honest to u
se the term "project manager" (or even "Agile project manager" if that's not an
oxymoron.). According to Ken Schwaber (who pretty much defined Scrum), the Scrum
Master has no authority. The Product Owner has explicit authority. So by defini
tion they're not the same person. Scrum intentionally divides the traditional pr
oject manager's responsibilities between the Product Owner and the Team, with th
e Scrum Master acting as a kind of facilitator. Per Schwaber, "The team is utter
ly self managing." Module 1: Introduction to Scrum elaborates on this.
Q: What about combining Scrum Master and team member roles?
A: That's probably less harmful, though most of the places I visit have so m
any organizational impediments that a full time Scrum Master may be the key to e
xperiencing the breakthroughs they'd be capable of if they stopped pretending to
do Scrum. When a team plateaus with one Scrum Master, it may be time to switch
to a different one with different skills.
Q: How should we pick a Scrum Master?
A: Pick the certified one! No, seriously, ask the team and Product Owner to
decide. Revisit the decision again after a while. If you can mark off most of th
e items in the Example Scrum Master's Checklist, you're doing better than most.
Q: Why should I attend Scrum/Agile training instead of just reading books an
d using these e-learning modules?
A: For many people, understanding the e-learning modules, the Scrum Referenc
e Card, and the Agile Manifesto will be sufficient to pass a certification test.
If you find a good Scrum trainer, you'll spend most of your class time in inter
active team activities going beyond the basic concepts into practical applicatio
n and case studies. (According to Yogi Berra, "In theory there's no difference b
etween theory and practice. In practice, there is.") Some trainers (including ou
r competitors) require completion of this e-learning series before class so that
more time can be spent on more advanced activities. A good trainer will check y
our understanding more thoroughly than these modules can. While some people do g
et good at doing Scrum and Agile without any training, our participants report t
raining helps them get better at it faster.
Q: Can I obtain Scrum certification online, without physically attending a c
lass?

A: The most generally-recognized "Certified ScrumMaster" (CSM) credential is

part of a class from a ScrumAlliance Certified Scrum Trainer.
Q: The module scenarios describe a single team. What about large organizatio
ns?
A: Danube Technologies, Inc. (later acquired by CollabNet) was a small compa
ny when we started doing Scrum (and related technical practices) for our own dev
elopment ten years ago. It was relatively easy for us because there weren't a lo
t of established habits to overcome. While people in large organizations have ex
perienced benefits from Scrum and/or Agile, we haven't seen many large establish
ed organizations do great at it on the first try. Add geographic distribution, a
nd the problem is even harder. Sometimes the best we can do is protect one team
from the rest of the bureaucracy until that pilot effort demonstrates there may
be benefits for others.
It is also possible to have multiple teams using an Agile approach to work o
n one product. Most coaches who've worked with large organizations attempting Ag
ile have come to prefer feature teams over component teams. Feature teams work o
n multiple components to deliver features end users can see, rather than mere in
ternal deliverables. Unfortunately large organizations are traditionally set up
like factories, with people organized around architectural components (e.g. the
server side and the client side) or grouped by functional discipline (e.g. a Q.A
. department in another country). In the traditional structure, it's harder for
any one team to get work into a customer-deliverable state. This forces Product
Owners to prioritize by internal constraints rather than customer business value
. While the feature team approach is more Agile, it presents political and techn
ical challenges. We may need to ask individuals to act as component guardians to
protect the architectural integrity of particular components during the transit
ion. I think of a component guardian as kind of a tour guide for a component, sh
owing the feature teams how to use the component while making sure they don't wr
eck it in the process.
Q: I understand the theory of why vertical feature teams are better than com
ponent teams, but when we tried this we wound up with lots of duplicated effort,
inconsistent user interfaces, and poor design of common components such as plat
form and database tables. How can vertical stovepipes be avoided?
A: In addition to the component guardian approach above, you may be able to
mitigate these issues by forming informal communities of practice that include p
eople with related concerns spanning the multiple feature teams. For example, a
person interested in User Interface from Team A should still cooperate with his
UI-interested counterparts on Teams B and C. (Note that I'm avoiding specifying
job titles like UI Designer, Tester, DBA, etc. because titles do not aid team se
lf organization.) If cross-team collaboration is an unfamiliar habit, consider a
dding specific tasks for this during the Sprint Planning Meeting. For an example
see the Spotify case study.
Q: I am working on a really big product. How can I learn more about large sc
ale development using Scrum and Agile principles?
A: The most thorough written explanation I've found is in Scaling Lean and A
gile Development by Craig Larman and Bas Vodde. There's also a much shorter onli
ne overview of the Larman/Vodde approach. Unfortunately there are also highly-pu
blicized approaches that conflict with Agile principles rather than employing th
em. It's tempting to use "safe" approaches that don't require fundamental change
s. The Product Owner is supposed to be a business decision maker; beware approac
hes that turn the Product Owner into a middle manager buried under layers of hie
rarchy. Scrum relies on self-organizing teams; approaches that enshrine roles su

ch as "software architect" restrict this.

Q: Why don't the modules show burndown charts?
A: Burndown charts are less important parts of Scrum than you probably think
they are. But you can read about them in the "Artifacts" section of the Scrum R
eference Card. My favorite Product Owner does find the release burndown chart us
eful for forecasting -- probably the only legitimate use of velocity. Of course
he revises his release forecast every Sprint, letting go of some stuff he origin
ally planned to get newly discovered requirements he comes to realize is a highe
r priority as it emerges.
Q: What do you mean by "There is no Scrum methodology"?
A: Scrum was intended to be framework of empirical feedback loops about both
the product and the process used to develop it, not so much a conventionally de
fined process. Responsibility for the process is shifted from the methodologist
to the practitioners. I sometimes think this is an uphill battle due to methodoe
ntropy: the inevitability of methodologists taking over approaches that were onc
e intended to liberate people from methodologists.
Q: What is "the boss/worker game"?
A: The game where the boss pretends he can actually control people and the w
orker pretends to comply. It's also a literal game Ken Schwaber taught us for Sc
rum training. Scrum aims to replace the boss/worker dynamic with a Product Owner
to (self-organizing) Team relationship. The Scrum Development Team self organiz
es to achieve the vision and objectives of the Product Owner, while the Scrum Ma
ster creates the environment more conducive to this. Giving up the illusion of c
ontrol is often the key to gaining influence.
Q: Thanks for all insights in the scrum training class last week. I had one
question that I didn t get a chance to ask that is about testing. Currently we have a
3 week sprint followed by a code freeze
where we take a snapshot of the code branch an
d then a 3 week testing cycle in a test environment on this branch. This is so t
hat there is a controlled environment for testing without a lot of code changes
happening. I know you mentioned that testing is part of the sprint in a scrum en
vironment. So I guess as each user story is getting completed we would execute a
ll the manual and automated tests for it before moving on to the next user story
and there is no separate testing phase.
My question is, if testing is mixed with development, how we can still get a
controlled environment
where code is not in a flux.
A: I guess there's two separate issues: what has worked for some people, and
what you should do.
The first time we used Scrum at our small company (eventually acquired by a
medium-sized company) we were able to build a moderately complex application whi
le relying mostly on manual regression testing. That got painful as the applicat
ion got bigger. So we hired someone (we'll call him Sai) specifically to create
automated tests for the existing code, working mostly by himself creating unmain
tainable test code. The dominant genius on the team (we'll call him Bob) was tal
ented at architecture and code, but wasn't really sold on the eXtreme Programmin
g practices of Test Driven Development (TDD includes creating automated tests as
part of the code writing workflow), pair programming, and continuous design. Th
e automated testing practice fizzled, as they always will without a whole team c
ommitment. The team did eventually deliver a satisfactory product, but at the en
d even Bob admitted it would be better to do TDD from now on.

Bob, very smart, but not the most flexible team member, left for other reaso
ns. Ever since then that team has used an increasingly rigorous definition of "d
one" until the automated regression tests became good enough to eliminate the ne
ed for code freezes or even slowing down very much for manual regression testing
before a release. The automated tests are initiated many times per day as part
of the coding process, and backstopped by a continuous integration server which
occasionally alerts us that someone accidentally broke something. There's more t
est code than actual production code. Manual testing still occurs, but the manua
l testing focus is much more on looking for new bugs, much less on regression fa
ilures.
Somewhere along the way we abandoned 30-day Sprints and settled on two-week
Sprints. Even days before a release, there's no code freeze, though it's natural
to slow down a little and focus on low-risk fixes, cosmetic issues, double chec
k the documentation, rather than radical changes. Some teams do one-week Sprints
, and others claim the product is shippable any day of the week. Shorter Sprints
, plus a rigorous definition of done, plus work-in-progress (WIP) limits force u
s to let go of waterfall habits. It's similar to the way Toyota forces the elimi
nation of slop in their production system by reducing inventory to previously un
thinkable levels.
So that's one pathway that took many months and probably wouldn't have happe
ned without personnel changes. One of our clients actually wound up firing a key
architect everyone thought was untouchable because she just wouldn't collaborat
e -- their only regret was waiting so long to do it. I don't actually know what
you should do, but common impediments to this are: developers who think testing
is someone else's job, a mixed commitment from the team/organization to learn th
e new practices, a mountain of legacy code (why try when it seems hopeless?), an
d simply not having the new skills yet.
Q: Does incremental development introduce the risk of an architectural hodge
podge?
A: The risk of technical debt (high cost of future change) is always there,
and seems to be exacerbated -- not mitigated -- by a traditional big design up f
ront (aka waterfall or "Sprint Zero") approach. The assumptions behind the big u
p front design turn out to be wrong as development progresses and we learn more
about what is really needed through feedback. The sunk cost fallacy reduces our
willingness to change a design we've spent months on. Scrum is intended to tight
en the feedback loops so those mistakes are discovered earlier. But this won't w
ork if every minute of every subsequent Sprint is spent on construction only. Te
ams should reconsider their design approaches on a continuous basis. Agile engin
eering practices such as Test Driven Development (TDD), pair programming, contin
uous integration, and merciless refactoring can improve our ability to melt down
what was there before continuously rather than accumulate layers of paint on to
p of layers of paint. Of course, this is easier said than done.
Q: I see how TDD, pair programming, merciless refactoring, and continuous de
sign/redesign might prevent design entropy, technical debt, bad code, or whateve
r you want to call the stuff. But our codebase has years of accumulated crud. In
fact, we're having trouble hiring developers who are willing to work on it -- i
t seems programmers who have choices prefer to work on new stuff that isn't alre
ady a mess. Should we throw it away and start from scratch?
A: While a complete rewrite may be appropriate, most of the times I see comp
anies attempt this it turns out to be several times more effort than they expect
ed. It's possible your best bet is to incrementally clean up what was there ever
y single Sprint along with adding the new capabilities (at a slower rate of cour
se). Your definition of done should start to include "we left it cleaner than we
found it." Each time you add a feature, add test coverage to the legacy code it

interacts with. As your test coverage starts to spider into the legacy system y
ou'll finally reduce the risks of refactoring the parts of it that are causing t
he most pain. (For many pages more about this, read Working Effectively with Leg
acy Code by Michael Feathers.) Obviously the team will need to take this drag in
to account when planning Sprints. Taking a little time to add tests (incremental
ly) and replace bad code (incrementally) will feel like going too slow to someon
e in your organization, but trying to work faster than current skills allowed is
what got your organization into this mess in the first place. There is somethin
g worse than going "too slow": not knowing where you are!
Q: Does [XYZ famous successful company] do Scrum?
A: Scrum is just one pathway to Agility, just like going to the gym is only
one way to get in shape. There are some pretty unadaptable companies "doing Scru
m" (or at least saying they are) and some other companies that act out the Agile
values naturally, without doing Scrum. An organizations impediments are the sam
e whether we expose them with Scrum, Lean, Kanban, XP, or any other approach tha
t invites reflection. Note there are some "successful" companies today that surv
ive for the moment only because of momentum. The real factor in staying competit
ive tomorrow is whether we're going to use our feedback loops (e.g. the Sprint R
eview and Sprint Retrospective) to learn and adapt our organization.
Q: I was surprised by the statement "The project manager by definition is no
t the SCRUM master" since I find good project managers do exactly what is listed
on your reference card under SCRUM master.
A: I'm thinking of rewriting the statement to be less obnoxious. The project
manager role as traditionally defined requires some authority, and there's a co
ntradiction between that positional authority granted by the organization and th
e intent of the ScrumMaster role with no positional authority. But I think most
project managers, or least the good ones, discover they have no real control ove
r people and are able to contribute more by removing impediments, including impe
diments to team self organization. We're trying to define a ScrumMaster role tha
t explicitly contradicts some of the defined expectations placed on project mana
gers. Now I'm trying to think of a more clear way to say that....
Q: I am new to agile and wonder if you can answer a question about vertical
slices for me. I know, at least theoretically, what a vertical slice is but not
sure when vertical slices are created for each sprint. Is a vertical slice creat
ed for each sprint?
A: Yes, every Sprint we attempt to build a thin user-visible slice of functi
onality that cuts as far through the architecture as necessary, often involving
multiple components. Developing that slice involves a mix of work that used to b
e done in separate phases in the traditional waterfall process: analysis, design
, implementation, testing, integration, and possibly other activites such as doc
umentation and regulatory compliance checking; this is what we mean by definitio
n of done. Agile approaches attempt to eliminate phases, so we mix these activit
ies into every Sprint. To achieve a rigorous definition of done, the Product Own
er and Team need to come up with ways to split the large fuzzy user requirements
(often called "epics") into small specific user requirements (often "user stori
es"). In modern definitions of Scrum we set aside time for this requirements ana
lysis work during the Backlog Refinement (aka. Grooming) Meeting Ideally every P
roduct Backlog Item would also represent a thin vertical slice as well.
Q: I've heard the term "Sprint Zero" and it sounds like a disguised waterfal
l phase to me. Is a Sprint just any two week period?
A: No. A Sprint is a self organizing team's time-boxed attempt to build a (p
otentially) shippable product increment according to goals negotiated with Produ

ct Owner. Analysis, design, environment set up, getting know each other, etc. ar
e all important activities, and Scrum emphasizes some reduction to practice on t
he very first Sprint as a reality check on all that abstract work. For better or
worse, Scrum emphasizes empirical feedback every Sprint. We do some of our anal
ysis through exploratory action, and have to be willing to throw some stuff away
when we learn we guessed wrong. This is the nature of complex work anyway -- Sc
rum just speeds up the action and feedback cycle. Once we understand the definit
ion of Sprint, it's clear that "Sprint Zero" is self contradictory. When Ken Sch
waber wrote his most popular book defining Scrum, he didn't just write "potentia
lly shippable product increment" once, he wrote it 18 times. By Scrum's definiti
ons, anything that prevents us from doing that every Sprint, including the first
one, is an impediment. The most common impediment to Agility is not having lear
ned how to do it yet, and the second is being in an organization that's structur
ed in a way that discourage it.
Q: I see that the Agile Manifesto values customer collaboration over contrac
t negotiation, but contracts are the reality where I work. Can I still do Scrum?
A: We had this situation at our company also. In one case we turned over the
Product Owner role to the customer, making them more of a partner than an adver
sary. While there isn't a perfect solution, there are other types of contracts t
hat protect the interests of both parties in an Agile world. The customer is in
a much safer position if the team is doing their job of keeping the product in a
shippable state at all times. To learn about Agile contracts, see Craig Larman/
Bas Vodde's http://www.agilecontracts.org/, Agile Team Meets a Fixed Price Contr
act by Marcin Niebudek, 10 Contracts for Your Next Agile Software Project by Pet
er Stevens, and Money for Nothing and Your Change for Free by Jeff Sutherland. (
Hat tip: this list courtesy of Roger Brown.)
I have reviewed your ScrumMaster Checklist and would like to utilize
Q: Hello
Agile practices into a complex project that is currently waterfall. My experienc
e has mostly been with Agile methods but also have worked on waterfall. This cur
rent project is not a saavy project management team and most of the PMs are new
to their role. We have four work streams that are currently working independentl
y in requirements gathering. My program manger is supportive of moving away from
waterfall.
What would you suggest as first steps in an immature tech company looking to take
on a fairly complex project with a large contingency of inexperienced project te
am members?
Sincerely,
[name withheld] | Project Coordinator | [large health insurance company]
A: Gather a small core of the best developers, testers, and requirements exp
erts. Try to keep everyone else out of the way for a while. This pilot team shou
ld develop a functional walking skeleton that initially only supports the bare b
ones highest priority features and contains automated regression tests (in the s
ame language as the system being developed) and continuous integration so they c
an detect when features are broken within a few minutes. I'd rather have a team
that's too small than a department that's too mediocre. Are you in the business
of developing the product, or the business of keeping people busy? The FBI Senti
nel project is an interesting example. At one point they had 135 Lockheed contra
ctors, but didn't get anything done until they reduced that to 10. Or ask the pe
ople who built the ObamaCare website whether it's smart to use hundreds of peopl
e to create enormous incomprehensible analysis and design artifacts before you'v
e got one potentially shippable product increment.
Once we start see working, fully-tested product increments, that initial see

d team and their Product Owner can figure out how and whether to involve all the
other people. That's what I'd do if I were spending my own money and developing
the product was more important than all the politics involved. I don't know if
this approach would be politically practical without a deep organizational commi
tment to Agility that sometimes isn't found in health care IT companies.
I'd recommend working with Randy Ashton, who has years of experience in Agil
e for health care IT.
Probably the world expert in large scale agility is Craig Larman, who has wr
itten much more about this.
Hope that helps!
Q: I know Scrum's definitions specify one Product Owner, but ours is really
busy. Should we split the Product Owner role, or assign it to a committee?
A: For part of the American Civil War, the Army of the Potomac was officiall
y commanded by General Meade, but his command was overshadowed by his boss Gener
al Grant. In my opinion, because no one person was really responsible for the de
cision, they stumbled into one of the stupidest Union mistakes of the Civil War:
The Battle of Cold Harbor. In Scrum, one person must ultimately make the decisi
ons. We do want to offload that person as much as possible though. For example,
the Scrum team I enjoyed being on the most had a full time UI designer so that t
he Product Owner didn't have to figure out every little detail of how stuff shou
ld look. Other teams may benefit from other kinds of domain experts. People othe
r than coders are welcome on a Scrum team; that's what we mean by cross-function
al.
Q: This all sounds great in theory. Do you have any real world examples?
A: Here are a couple examples of large scale Scrum worth studying: J.P. Morg
an Global Core Processing Technology and Spotify.