In less than 24 hours at work, I completely changed the direction of my scrum team and had most of us co-located into an office.

After a laborious release to add some functionality to a tightly-coupled area of the application, I wrote a proposal, which was accepted. Our team was working on a re-imagining of a piece of our product as a module guided by domain-driven design. Management trusted our judgment and supported the project, but some of the senior staff didn’t get it. There were a lot of questions: “Why are you re-writing the … ‘module’?; it works fine” and “What is it you’re working on again?” We’ve been talking about our plans in detail in our developer’s book club and “lunch and learn” sessions, but only a third of the development staff showed up regularly. There were other barriers. For example, our requests to co-locate were met with the assessment that our team wasn’t the best size fit for the recently-vacated office we were vying for.

Tuesday afternoon, the whole product team had a meeting about our goals for 2009. I said our scrum team was worried about communicating the architectural changes we’re planning, because, in many ways we’d been preaching to the choir and wanted to expand our audience.

Then, a quiet-spoken, well-trusted senior architect went on a rant. I don’t know how else to describe it. He was upset about the project’s bug count, which had increased noticeably last year. He was worried that the division’s hellbent focus on new customer functionality sacrificed product stability, and would not concede the point. The product owner got upset, because she felt her resource constraints were clear and pointed out no team would sign up for just squashing bugs. The COO, quietly listening in the back, pitched the idea of farming out some of the work to resources outside our office, but the idea was met with skepticism. (For the record, I supported the idea. A few bugs we don’t fix is better than zero, yielding dividends in the long run.)

Afterward, I talked with my cohort and shared the idea that was forming in my head. Our team would take that bug-slaying assignment. We have several projects with client commitments for the next few months, and we’re having trouble getting people on-board with the domain-driven design approach. This combination seems like a wonderful opportunity to do some education and get more people involved in the up-front modeling that’s required. In return, my only stipulation was a firm commitment to resuming the project once the client went live.

My manager wasn’t overjoyed with the news, but saw the wisdom in it after I explained the rationale. He made my development partner in crime and I swear we would stay until the end of the year. And, he tasked us not to do the bug-slaying in a piecemeal fashion, but to take the time to also fix design flaws as we encountered them. I added that we’d be laying some foundation for the new architecture – putting interfaces in place, adding dependency injection, and the like.

We also got another concession: sanctioned work time for us to develop training materials and a couple hours a week each for people to practice these new skills.

And, miraculously, when management embraced the bug-slayer idea wholeheartedly, the room fell into our laps!

I went home Tuesday worried about what I’d signed myself up for.

Yesterday morning, we moved in. The room had already been set up for a team, but I didn’t like the arrangement of the furniture, so I changed it. The room had been ringed with 4-foot tables along the walls. Instead, I wanted to replicate the feeling of having cubes partially separated with half-height walls. It allowed my mate and I to talk freely, and offered just enough sound buffering.

I lost square footage and my whiteboard (temporarily), but I gained a window seat in a semi-quiet space. I set two of the tables facing each other, relying on our monitors to mimic the cube walls. Having my cohort sitting across from me has made conversations much easier. Instead of IM or walking through the maze, we just look at each other. Already, we’ve been able to plan how we’re going to teach DDD to the rest of the group while working on getting the “Bob Zombie” project out the door at the same time.

“Bob” is a play on the project number (“808” => BOB), and “Zombie” is a commentary on the former state of the project. Bob Zombie is definitely a cautionary tale about calling a project “done” before it’s “done done”. After it was declared done, the team was disbanded, only later to discover an emergent requirement. Without resources, it languished for months. Until now.