If you are taking anyone's Scrum class, any type of Scrum Master certification test, Agile certification, or you just want to improve your knowledge and dispell popular hype and misconceptions, you'll have a much better time if you also study the Scrum Reference Card, the four values of the Agile Manifesto, and the twelve principles of the Agile Manifesto. Paying close attention to these resources and this e-learning series provides all the information you'll need to pass Scrum Master certification tests such as Certified Scrum Master (CSM). Statistically, non-native English speakers (often people who grew up outside the US, UK, Canada, etc.) have more difficulty with these tests and classes, requiring more study time to overcome the language barrier.
If you are an Agile trainer, coach, or consultant, I recommend having your clients complete these modules before your visit. Informed clients get much better value for their limited time with you.
There is no Scrum methodology, no Agile methodology.
-
Q: I am the CTO of a small company I helped start and one of the more experienced developers there. Unfortunately I'm also one of the main voices in employee performance appraisals and hiring/firing decisions. I would like to have the benefits 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 decisions. 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 use this process to find out: Conduct an anonymous safety check (as described in Module 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 Sprint, as we tend to overestimate what we know beforehand.
-
Q: What should we do if the Scrum Master and Product Owner are the same person?
A: As far as I know, the Scrum Police aren't going to break down your door if you do this. But if those two roles are combined, it would be more honest to use 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 definition they're not the same person. Scrum intentionally divides the traditional project manager's responsibilities between the Product Owner and the Team, with the Scrum Master acting as a kind of facilitator. Per Schwaber, "The team is utterly 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 many organizational impediments that a full time Scrum Master may be the key to experiencing 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 the 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 and using these e-learning modules?
A: For many people, understanding the e-learning modules, the Scrum Reference 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 interactive team activities going beyond the basic concepts into practical application and case studies. (According to Yogi Berra, "In theory there's no difference between theory and practice. In practice, there is.") Some trainers (including our 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 your understanding more thoroughly than these modules can. While some people do get good at doing Scrum and Agile without any training, our participants report training helps them get better at it faster.
-
Q: Can I obtain Scrum certification online, without physically attending a class?
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 organizations?
A: Danube Technologies, Inc. (later acquired by CollabNet) was a small company when we started doing Scrum (and related technical practices) for our own development ten years ago. It was relatively easy for us because there weren't a lot of established habits to overcome. While people in large organizations have experienced benefits from Scrum and/or Agile, we haven't seen many large established organizations do great at it on the first try. Add geographic distribution, and 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 on one product. Most coaches who've worked with large organizations attempting Agile have come to prefer feature teams over component teams. Feature teams work on multiple components to deliver features end users can see, rather than mere internal 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 technical challenges. We may need to ask individuals to act as component guardians to protect the architectural integrity of particular components during the transition. I think of a component guardian as kind of a tour guide for a component, showing the feature teams how to use the component while making sure they don't wreck it in the process.
-
Q: I understand the theory of why vertical feature teams are better than component 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 platform 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 people 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 self organization.) If cross-team collaboration is an unfamiliar habit, consider adding 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 scale development using Scrum and Agile principles?
A: The most thorough written explanation I've found is in Scaling Lean and Agile Development by Craig Larman and Bas Vodde. There's also a much shorter online overview of the Larman/Vodde approach. Unfortunately there are also highly-publicized approaches that conflict with Agile principles rather than employing them. It's tempting to use "safe" approaches that don't require fundamental changes. The Product Owner is supposed to be a business decision maker; beware approaches that turn the Product Owner into a middle manager buried under layers of hierarchy. Scrum relies on self-organizing teams; approaches that enshrine roles such 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 Reference Card. My favorite Product Owner does find the release burndown chart useful for forecasting -- probably the only legitimate use of velocity. Of course he revises his release forecast every Sprint, letting go of some stuff he originally planned to get newly discovered requirements he comes to realize is a higher 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 defined process. Responsibility for the process is shifted from the methodologist to the practitioners. I sometimes think this is an uphill battle due to methodoentropy: the inevitability of methodologists taking over approaches that were once 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 worker pretends to comply. It's also a literal game Ken Schwaber taught us for Scrum training. Scrum aims to replace the boss/worker dynamic with a Product Owner to (self-organizing) Team relationship. The Scrum Development Team self organizes to achieve the vision and objectives of the Product Owner, while the Scrum Master creates the environment more conducive to this. Giving up the illusion of control 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 and then a 3 week testing cycle in a test environment on this branch. This is so that 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 environment. So I guess as each user story is getting completed we would execute all 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 while relying mostly on manual regression testing. That got painful as the application 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 unmaintainable test code. The dominant genius on the team (we'll call him Bob) was talented at architecture and code, but wasn't really sold on the eXtreme Programming practices of Test Driven Development (TDD includes creating automated tests as part of the code writing workflow), pair programming, and continuous design. The automated testing practice fizzled, as they always will without a whole team commitment. The team did eventually deliver a satisfactory product, but at the end 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 reasons. Ever since then that team has used an increasingly rigorous definition of "done" until the automated regression tests became good enough to eliminate the need 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 test code than actual production code. Manual testing still occurs, but the manual testing focus is much more on looking for new bugs, much less on regression failures.
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 check 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 us to let go of waterfall habits. It's similar to the way Toyota forces the elimination of slop in their production system by reducing inventory to previously unthinkable levels.
So that's one pathway that took many months and probably wouldn't have happened without personnel changes. One of our clients actually wound up firing a key architect everyone thought was untouchable because she just wouldn't collaborate -- 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 the new practices, a mountain of legacy code (why try when it seems hopeless?), and simply not having the new skills yet.
-
Q: Does incremental development introduce the risk of an architectural hodgepodge?
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 front (aka waterfall or "Sprint Zero") approach. The assumptions behind the big up 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 tighten the feedback loops so those mistakes are discovered earlier. But this won't work if every minute of every subsequent Sprint is spent on construction only. Teams should reconsider their design approaches on a continuous basis. Agile engineering practices such as Test Driven Development (TDD), pair programming, continuous integration, and merciless refactoring can improve our ability to melt down what was there before continuously rather than accumulate layers of paint on top of layers of paint. Of course, this is easier said than done.
-
Q: I see how TDD, pair programming, merciless refactoring, and continuous design/redesign might prevent design entropy, technical debt, bad code, or whatever 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 -- it seems programmers who have choices prefer to work on new stuff that isn't already 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 companies attempt this it turns out to be several times more effort than they expected. It's possible your best bet is to incrementally clean up what was there every single Sprint along with adding the new capabilities (at a slower rate of course). 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 you'll finally reduce the risks of refactoring the parts of it that are causing the most pain. (For many pages more about this, read Working Effectively with Legacy Code by Michael Feathers.) Obviously the team will need to take this drag into account when planning Sprints. Taking a little time to add tests (incrementally) and replace bad code (incrementally) will feel like going too slow to someone 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 something 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 Scrum" (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 same whether we expose them with Scrum, Lean, Kanban, XP, or any other approach that invites reflection. Note there are some "successful" companies today that survive for the moment only because of momentum. The real factor in staying competitive tomorrow is whether we're going to use our feedback loops (e.g. the Sprint Review and Sprint Retrospective) to learn and adapt our organization.
-
Q: I was surprised by the statement "The project manager by definition is not 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 contradiction between that positional authority granted by the organization and the 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 over people and are able to contribute more by removing impediments, including impediments to team self organization. We're trying to define a ScrumMaster role that explicitly contradicts some of the defined expectations placed on project managers. 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 created for each sprint?
A: Yes, every Sprint we attempt to build a thin user-visible slice of functionality that cuts as far through the architecture as necessary, often involving multiple components. Developing that slice involves a mix of work that used to be done in separate phases in the traditional waterfall process: analysis, design, implementation, testing, integration, and possibly other activites such as documentation and regulatory compliance checking; this is what we mean by definition of done. Agile approaches attempt to eliminate phases, so we mix these activities into every Sprint. To achieve a rigorous definition of done, the Product Owner 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 stories"). In modern definitions of Scrum we set aside time for this requirements analysis work during the Backlog Refinement (aka. Grooming) Meeting Ideally every Product 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 waterfall 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 (potentially) shippable product increment according to goals negotiated with Product Owner. Analysis, design, environment set up, getting know each other, etc. are all important activities, and Scrum emphasizes some reduction to practice on the 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 analysis 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 -- Scrum just speeds up the action and feedback cycle. Once we understand the definition of Sprint, it's clear that "Sprint Zero" is self contradictory. When Ken Schwaber wrote his most popular book defining Scrum, he didn't just write "potentially shippable product increment" once, he wrote it 18 times. By Scrum's definitions, 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 learned how to do it yet, and the second is being in an organization that's structured in a way that discourage it.
-
Q: I see that the Agile Manifesto values customer collaboration over contract 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 adversary. While there isn't a perfect solution, there are other types of contracts that 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 Contract by Marcin Niebudek, 10 Contracts for Your Next Agile Software Project by Peter Stevens, and Money for Nothing and Your Change for Free by Jeff Sutherland. (Hat tip: this list courtesy of Roger Brown.)
-
Q: Hello – I have reviewed your ScrumMaster Checklist and would like to utilize Agile practices into a complex project that is currently waterfall. My experience has mostly been with Agile methods but also have worked on waterfall. This current 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 independently 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 team members?
Sincerely,
[name withheld] | Project Coordinator | [large health insurance company]
A: Gather a small core of the best developers, testers, and requirements experts. Try to keep everyone else out of the way for a while. This pilot team should develop a functional walking skeleton that initially only supports the bare bones highest priority features and contains automated regression tests (in the same language as the system being developed) and continuous integration so they can 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 Sentinel project is an interesting example. At one point they had 135 Lockheed contractors, but didn't get anything done until they reduced that to 10. Or ask the people who built the ObamaCare website whether it's smart to use hundreds of people to create enormous incomprehensible analysis and design artifacts before you've got one potentially shippable product increment.
Once we start see working, fully-tested product increments, that initial seed 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 commitment 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 Agile for health care IT.
Probably the world expert in large scale agility is Craig Larman, who has written 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 officially commanded by General Meade, but his command was overshadowed by his boss General Grant. In my opinion, because no one person was really responsible for the decision, 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 decisions. 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 the Product Owner didn't have to figure out every little detail of how stuff should look. Other teams may benefit from other kinds of domain experts. People other than coders are welcome on a Scrum team; that's what we mean by cross-functional.
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. Morgan Global Core Processing Technology and Spotify.
