This chapter is from the book
This chapter is from the book
This chapter is from the book
Breakthrough
Early in my experience with agile, a development team that I was managing was lucky enough to make a breakthrough with bullpens that transformed its behavior almost immediately. In fact, this breakthrough was so profound for the team that it changed my reflexive, waterfall-oriented thinking permanently. The team I was managing was having communication problems. A project consultant, Stan Rifkin, suggested we try bullpens to fix these challenges.
But let me back up and describe how we got to this recommendation. The first development team I managed that adopted agile got all the basics down quickly. Our daily standups became essential; we defined the work we planned to complete each iteration; and we demonstrated new functionality to our customers almost weekly. Despite our early success with many of the typical agile techniques, we were not working well as a whole team. Several developers would talk to each other in the hall, decide on a new development strategy, and then forget to tell the testers. An email discussing changes to how the product could be customized would go out to a part of the team, but the writers would be left off the email thread. Testers complained among themselves about the usability problems but did not bring them to the rest of the team. Tempers were mounting and disgruntled team members visited me saying, “He said this; she said that.”
I took a piece of advice Mary Poppendieck gave me during a conversation about “stop the line” thinking and identified just one problem to fix during each iteration. If we failed to find a solution to the problem, then we worked on the same problem the next iteration, and the next, and so on, until it was fixed. The team agreed that it was not a whole team. We tried everything we could think of but nothing worked. Over time the team was feeling demoralized, members were banding together to place blame, and the whole agile effort was losing ground.
Luckily we got consulting help from Stan Rifkin, a consultant with 40 years’ experience in data processing, management consulting, software engineering, and computer science. We reviewed our practices and issues with him. He suggested that we try bullpens. He explained that bullpens were multihour working meetings with the emphasis on working. Instead of meeting to discuss status, or to do planning, teams do real work together. Here are the rules for bullpens:
- Everyone on the agile team MUST attend and pay attention.
- Do real work together.
At first we struggled with what this actually meant. Do we write code together, do we test together, do we review documents together? In the end, it did not matter as long as we worked together and solved problems.
Interestingly enough, the majority of the team had a similar response to the suggestion, “No way!” (although a few people said, “Sounds great, let’s try it”). After listening to all the reasons we should not do it for more time than I can stand to remember, I pulled management rank and said, “We will try it beginning tomorrow.” The team grumbled off and planned for their first 2-hour bullpen.
The team floundered a bit, wondering how to start, but a tester broke the silence by talking about a set of tests that were failing. That quickly led to discussions on how the tests were run, disagreements about the expected behavior, and candid feedback about how the functionality could be more usable. With that, the team was off and running.
The first bullpen worked well. Problems were solved in real time, and the entire team learned what was going on at the same time. The team proceeded to schedule multiple bullpens weekly. Because the entire team was not in the same room, let alone the same country, we had to do this over the phone and with an emeeting—sort of “virtually sitting next to each other.” Adopting bullpens had the added benefit that when the team was not in a bullpen, it could get more focused time to work because most of the issues requiring cross-team communication had already been addressed.
Bullpens became so successful that the team started to use them for a variety of purposes. They had bullpens to jointly review code, discuss and solve difficult technology problems, code bash as a team, and more. We observed these positive outcomes: First, the team became a whole team. Accusations ceased and productivity increased. Second, the amount of email in my inbox dropped in size significantly. The team solved problems in real time with the whole team involved, so no additional communication was required.
Small agile teams that work in the same room usually develop a bullpen behavior simply based on their proximity. These may be called team rooms. Teams not residing in the same location can get similar value from bullpens. One advantage of bullpens over team rooms is that with bullpens, the rule is that everyone must attend, and it also leaves nonbullpen time to get focused work done that is less likely to be interrupted.
The story at the beginning of this chapter about the user interface design point that the tester disliked resulted from one of the first bullpens that I attended. The success of the meeting was stunning to everyone in the meeting. It forever changed our team dynamics and we were hooked.
When a team becomes a whole team, the team starts to think in a more agile way. When teams share the ownership of problems and their resolution, they can move faster together, leveraging everyone’s collective strengths. Most whole teams have more fun working this way and certainly experience higher productivity.