Agile Case Study (1/5): Project kick-off

The following case study is originally published as the chapter 23 of the Mike Cohn’s book entitled Agile Estimating and Planning. In this chapter, the author, in order to summarize and put into practice many key points explained in the book, develops a case on the experience about the first agile project in a fictitious firm called Bomb Shelter Studios, participating the following characters:

• Frank: Product Manager.
• Allan: Programmer.
• Sasha: Architect.
• Carlos: Agile Coach.
• Prasad: Tester.
• Rose: Art Designer.
• Delaney: Business Analyst.
• Laura: CFO.
• Phil: CEO.

This chapter starts with the convenience of going agile to manage a new software project.

[…]
The flight was a long one but the conference had been a success. Flights back from the east coast were always the hardest; but on this flight Frank had upgraded to first class, exchanging some of his frequent flyer miles for a bit more room and comfort. Reflecting back on the week’s events, Frank settled into his seat.

As a product manager for Bomb Shelter Studios, Frank knew that the company’s latest game, Deep Black & White, would do well. It played a game called Go that was extremely popular in Japan, China, and Korea but had only a moderate following in Europe, North America, and the rest of the world. The programmers on his team had come up with artificial intelligence breakthroughs that allowed Deep Black & White to play at a level known as 5-dan. This was still far from the 9-dan level of the best professional players but it was far ahead of where any of Bomb Shelter’s competitors were.

Frank was ecstatic that Deep Black & White would be released and marketed in Asia through the distribution deal he’d negotiated with a publisher at the conference. The revenue from sales in those markets would really help Bomb Shelter. Frank knew that the additional six months it took to complete Deep Black & White had almost been the end of the small, privately-held game development company he had cofounded.

From its inauspicious beginnings three years ago, Bomb Shelter Studios had become recognized as a high-end developer of thinking and strategy games. In addition to the newly finished Deep Black & White, Bomb Shelter had developed games that played chess, backgammon, reversi, bridge, checkers, mancala, and other similar games. Once a game was developed, distribution rights were sold to a publisher who would take care of all production and distribution, allowing Bomb Shelter to focus entirely on developing new games.

While Frank had been at the conference, his analyst and small team back in Santa Barbara had been thinking about the new game, Havannah, that they were nearly ready to start. Because of the problems with Deep Black & White—not just the six-month delay but also finding too many bugs and uncovering some usability issues late—Frank knew that they had to find a different way of planning and developing projects.

Sasha, the company’s lead architect, researched some ideas the team had. She suggested using what they were calling an “agile process” for the next project. Frank wasn’t exactly sure what that meant, but he was sure they needed to do something different. Being six months late on the next game wasn’t going to work. Everyone on the team was excited to give an agile process a try and they all knew what was at stake.

Day 1: Monday Morning

“Good morning, everyone,” Frank said as he entered the conference room. It was still a minute before nine and almost the entire team was already waiting for him. That was a good sign. Even though the team was tired from the final push on Deep Black & White, it looked like they were ready to get right back in it for Havannah.

“Good morning, Frank. I saw your email about Deep Black & White. That’s great news on the distribution deal,” said Allan, the C++ programmer who had coded the artificial intelligence engine that let Deep Black & White play such a strong game.

“Have a donut, Frank,” Sasha said as she pushed the nearly empty box across the table.”

“Thanks,” Frank said, taking a maple bar from the box.

“Frank, this is Carlos,” Sasha said. “Carlos is an experienced agile coach. We’ve brought him in to help us as we learn to work in this new, agile way.”

Frank and Carlos shook hands and exchanged greetings.

“It looks like everyone is here except Rose,” Frank said. “Let’s go ahead and get started. We can fill her in later. We probably won’t talk about the artwork much in this meeting anyway.”

“We can’t start, Frank,” Carlos said. “This is important. We need the whole team here. A big part of the benefit we’re after from trying an agile process requires everyone to participate. Rose may not have much to say about the artificial intelligence in the move engine. But, even so, we need her perspective if we want to plan the best possible game we can.”

“She always gets here about five minutes after nine on Monday. She drops Brooke at school on Monday, Wednesday, and Friday. She’ll be here,” Prasad said, finishing almost exactly as Rose opened the door to the conference room.

“Sorry. Traffic,” Rose said, quickly sliding into a chair.

“So, Delaney, you’ve been doing the product research on Havannah,” Frank said to the analyst. “It’s been awhile since I’ve thought about that game. I’m sorry to ask, but can you tell me how to play it again?”

“Sure, Frank. First, the board looks like this,” Delaney said as she pulled a wooden board from her bag and placed it on the table.

“There are two players who take turns placing a piece on the board. Each player has different colored pieces. Once a piece is played on the board it can’t move.”

“Just like in Deep Black & White,” Frank said.

“Right, but unlike in Go, pieces cannot be captured. The goal in Havannah is to be the first player to make a ring, a bridge, or a fork. Whoever does that wins the game.”

“And what are rings, bridges, and forks?” Frank asked as Delaney grabbed a handful of pieces and began to arrange them on the board.

“A ring is the simplest. It looks like this,” Delaney said. “A ring is set of connecting pieces that enclose one or more points.”

“OK, that sounds easy enough. What makes this game hard?” said Allan, who was already thinking ahead to the work of writing the artificial intelligence engine that would select moves.

“Remember, a ring is just one of the ways to win. You can also win with a fork or a bridge,” Delaney continued as she arranged the stones as shown below. “A bridge connects any two corners. The bridge could run in a straight line along an edge from one corner to an adjacent corner. More likely though, a bridge will look more like this.” She pointed to the bridge on the right of the board.

“Does a player have to say which shape he’ll be trying to make before the
game starts?” Allan asked.

“No, that’s part of the fun and part of the challenge. You can start out trying
to make a bridge, realize that’s not going to work, and maybe try a fork.”

“So what’s a fork?”

“It’s like this, Frank,” Delaney said as she added some more stones to the board. “A fork connects three edges, not corners. Corners aren’t edges so they can’t be used in a fork, just in a bridge.”

“Programming the move engine is going to be a challenge. With so many possible ways to win and so many spaces on the board, the options are tremendous.”

“You’re right, Allan,” Delaney said. “Many people think this game is harder than chess because there are more options and because we can’t use a huge endgame book like we can in chess. In chess, once we get down to a few pieces left it’s possible to use a book of the best moves to play. At that point we don’t need to rely on just the move engine to select a move. With Havannah, there are too many pieces and too many positions.”

“You didn’t want an easy game to program, did you, Allan?” Sasha teased the other programmer.

Allan looked like maybe he did want an easy game to program this time.

“Don’t worry. The good news is that since so few people play Havannah right now, we don’t need as strong of an engine as we did with Deep Black & White.” Delaney said, noting the slight look of relief on Allan’s face. “We’ll want to get there eventually but we won’t need it in version one. A decent engine that beats most humans most of the time will be fine.”

“OK, Delaney. Are there any other rules we need to be aware of?” Frank said.

“No, that’s it. The rules are simple but this game really makes you think. That’s why we think it will do well with customers who’ve bought our other games.”

“So. Do you have a requirements document written?”

“Not yet, Frank. From what Carlos has taught us about agile software development, we want the whole team together to figure the requirements out collaboratively.”

“Right,” Carlos added. “We’re going to start today’s meeting by writing user stories. They’re brief statements of functionality but told from the user’s perspective. For example, As a user, I want to save a game I’m in the middle of. Stuff like that.”

“That sounds easy enough. What do we do with those once we’re done with them?”

“We’ll estimate each one, prioritize them, and then figure out the best tradeoff between features and schedule,” Carlos said.

read this article in Spanish

next