What Does My Agile Project Look Like?

When catching up with people many questions tend to revolve around my working situation. Curiosities including

• Do you have an office?
• Do you have a cubicle?
• How many people do you work with?

Ideal Workspaces

Pioneers of Agile software development tend to not believe in partitioning people off into different sections of a workspace. The big change from traditional techniques is that development needs to be more of a social, collaborative effort throughout the entire development lifecycle.

When we put people into different rooms, or even put up walls between them, they're less likely to talk to each other and know what is going on between them. This leads to a pain point much later on when we need to integrate the code of several developers. The solution is to have people in an open area and constantly talking as questions and ideas emerge. We all sit at a table with our computers, where it's very easy to yell out a massive design change or ask a question.

"We've just implemented flashscope, so no one should be attaching error messages to models anymore. Take a look at the HomeController for how to use it."

Realistic Workspaces

Part of the project in Los Angeles is Agile Coaching. This of course implies that the workspaces aren't currently set up ideally. We have a team room that fits about half the developers and the other half utilize cubicles in the adjacent room. It unsurprisingly presents some challenges, most problematic of which is easily the higher barriers to conversation.

We combat this in various ways, such as having a second 5-minute meeting (or stand-up meeting) midway through the day. Fortunately for us, we have just another week until we move into a team room large enough for us all.

Team Size

The development team I'm on is comrpised of four TWers and four client developers. Team sizes vary based on the scope of the project and finding that sweetspot isn't always an easy task. This probably goes without saying for every field, but there isn't a direct, linear relationship between people on a project and the amount of work that gets done. With software development, a team that is too large will have people stepping all over each others toes and will subsequently spend more time merging code than writing code.

The grads of my TWU class in Chicago are all on, or headed to, projects with two members to 54 members.