Chapter 10. Scrum – Large and Small

Let's say that you've been training for the past few months for your first 10 kilometer race. You've studied some training schedules, started out slowly, and built up mileage over time. As you've hit a new threshold of fitness, you've begun throwing in tempo and interval runs to build speed. You've learned about hill work from a fellow runner and incorporated that into your training as well. You also learned that you run fastest if you have a bagel two hours prior to your run, but you only found that out after some misadventures with lasagna. You're ready for the big day; you know your fitness abilities, nutritional requirements, and body better than ever before.

Word of your success has leaked out and a running team of 12 has asked you to help them prepare for their first 10 kilometer! Now you have to understand each runner's fitness level, weaknesses, pain threshold, old injuries (and new ones, too!); you must make weekly adjustments to 12 training plans...

Scrum stops the resource shell game

Walk down any street in NYC and you're likely to see someone taking people's money in the shell game—a quick-handed guy (called a thimblerig) moves shells around while a poor guy has to guess which shell the ball is under. The sucker will never be right, because the shell game is a fraudulent game—it tricks players into feeling confident so that the thimblerig can take their money. I see ETT resourcing as such fraud!

When project crunch time is near, managers respond by shuffling around people. This shuffling gives the appearance of efficiency, and since money is exchanged—in the form of wages and budgets—this is fraud. The resource shell game hides the real problem, which is that the company is trying to do too much with too few people. The ScrumMaster's job is to make the gross imbalance between demand and supply visible, and put an end to the thimblerigging. One place to begin is by helping the business identify its strategy and prioritize its initiatives...

Small Scrum

The first Scrum team was at a Boston company called Easel Corporation in 1993. Under the advice of Jeff Sutherland, this team created a modern development framework that included a dynamic object-oriented programming language, among many other cutting-edge components. The team was cross-functional, collocated, and never exceeded eight people in size.

This is small Scrum. By now you probably have a good grip on how to do small Scrum. When it's one team to one backlog, that's a pretty easy existence, one called simple, or small. As long as the product backlog is kept in a ready state, teams can pull the next item. Small Scrum can also be described as the basic Scrum framework applied in its pure form with no modifications. However, I bet that even Easel made modifications, because, as we'll explore later in this chapter, they simply were Agile, not just doing Agile. Modifications come easily, naturally, and sensibly to those who live the mantra of inspect and adapt.

The smallest...

When Scrum gets big—dysfunction or constraint?

While I still prefer an Agile method such as Scrum over a traditional methodology for large projects/programs, the fact of the matter is that any effort that has 20 or more people poses a significant communications challenge. In a program with 35 Scrum teams, all of which will use Scrum the same way, a program of this size of, say, 300 people, takes a tremendous amount of coordination, communication, and organization among teams and stakeholders.

As I mentioned in a previous chapter, I once worked with a company that was creating a new gadget. The program plan called for roughly 35 teams whose focus ran the gamut from firmware, software and tablet apps, integration with conferencing systems, and so on. It was a huge initiative and unfortunately ended up not being very successful in the consumer market.

I was one of the Agile mentors for the program and was limited to 10-15 hours per week to help guide the program. I worked with the ScrumMasters...

A real need for a project Grand Poobah

Yes, I'll say it, in a book for the whole world to see: in a large program, with matrix organization, there may be a need for skills that we might dub project coordination. Imagine a program of 300 plus people. replace with "Who is responsible to facilitate the creation of teams?" For organizing teams cross-functionally? Who is responsible for communicating with vendors to plan and track deliverables? Who works with HR and finance to budget for and procure resources? Who facilitates the Scrum of Scrums meeting? In other words, when the group is larger than three teams, someone should be in charge of keeping all the dogs pulling the sled in the same direction. Not responsible for the product's success in the market (I believe that responsibility lies with the product owner no matter the size of the program) but responsible for coordination, for getting the whole thing rolling to some cadence, some sort of schedule, and promoting and allowing for change...

Agile DNA

I believe that the biggest issue with many traditional organizations seeking to use Scrum on programs big or small is that they want to do Scrum or transition to Scrum—the emphasis mistakenly on doing Agile instead of being Agile. Big difference. While Toyota invites its competitors to learn the Toyota Production System (TPS), TPS is not really in the other car manufacturers' DNA. That is, they can learn the practices, how to do Kanban, kaizen, and so on, but if continuous improvement and human first/product second mind-sets are not in the mix, they won't be as successful. The same for agile. Two companies can do exactly the same Agile practices, but the one that gets the mind-set and the values will be more successful.

Likewise, if we look at the most successful tech companies as of the writing of this book—Apple, Google, Adobe, and others—they are regularly cited by employees as having collaborative environments, small teams, work-life balance, open environments, and the like...

Summary

Scrum has been used in implementations small and large, in just about every corner of the earth with just about every technology! It is simple enough to start today, yet humans can greatly complicate things. Sometimes teams can be too small; look at ways of grouping people so that five different projects aren't competing for the same resources, causing people to multitask and to lose precious productive hours as a result.

When scaling Scrum, start small if you can, and grow teams as needed. Regardless of the number of teams, focus on creating an environment in which people thrive and get things done. The resulting team motivation will help people outperform any other way of management. Recruit an Agile project coordinator in the largest of programs to help keep everything moving and everyone on the same page. In Chapter 11, Scrum and the Future, we will discuss how Scrum will change the organization and operation modes of businesses in the future.

Recommended reading

• Jeffries, Ron. Anderson, Ann and Hendrickson, Chet. Extreme Programming Installed. 2000, Addison Wesley.

• Vodde, Bas and Larman, Craig. Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. 2009, Pearson Education.