The Agile Architect

An Agile Holiday Open House

In the spirit of the holiday season, our Agile Architect welcomes you into his workspace and shares the ambiance of the agile experience.

• By Mark J. Balbes, Ph.D.
• December 21, 2012

One of my great joys of working in an agile environment is being able to show off how we operate. I've been in the software industry for many years (don't ask!) and have worked in just about every environment imaginable, from the utterly stifling to the wonderfully open and innovative. I can say without a doubt that the open, collaborative nature of a truly agile environment is the most enjoyable and most productive workplace I've known.

As much as I'd love to give each of you a personal, guided tour of our offices, showing off the magic that is agile, it's probably not practical. Instead, I thought I'd try to replicate the experience as best I can here.

So put on your imagination caps, close your eyes, take a deep breath and join me for this virtual tour of the Asynchrony offices. Hmm, maybe you better open your eyes so you can keep reading.

Welcome to Asynchony!
As we enter through the front doors of the historic Cupples 9 building in downtown St. Louis, we are immersed in the 120 years of history embodied by this newly renovated warehouse. The high ceilings and wooden support beams remind us of those bygone days when St. Louis was a manufacturing hub of the country. Eschewing the elevators for a brisk walk up the stairs to the 7th floor Asynchrony space, we realize just how high the ceilings are and just how many stairs we have to climb. Vowing never to make that mistake again, we arrive on the 7th floor, breathless with anticipation.

We are immediately struck with the sense of whimsy about the offices as we are greeted by bobblehead figures of the founding members of the company. (See Figure 1.)

[Click on image for larger view.]

Figure 1. Bobblehead Asynchrony founders.

As we move out onto the main floor (See Figure 2), we are struck by the lack of cubicles, offices, or even fixed walls. The space is designed for maximum flexibility, allowing new projects to claim space, self-organize, and self-decorate. Old project work areas are torn down as easily as they were originally created.

[Click on image for larger view.]

Figure 2. Open work areas.

While every work area looks different, there are similarities. The teams like to surround themselves with multiple whiteboards for collaboration, groups of pair programming workstations, and an innate sense of joy and adventure as we build our software.

From a higher vantage point (See Figure 3), we see that, while the teams themselves prefer to work in close quarters to facilitate collaboration, the floor contains a lot of open space. In addition, open collaboration pits (See Figure 4) litter the area, to allow for impromptu conversations and a bit of relaxation.

[Click on image for larger view.]

Figure 3. Open spaces

[Click on image for larger view.]

Figure 4. Conversation pit.

Ionic Mobile
Let's look at a single project space in more detail.  As we approach the Ionic Mobile project space, we can see that they've taken some creative license to shout out to the world who they are. (See Figure 5)

[Click on image for larger view.]

Figure 5. Entry into the Ionic Mobile workspace.

We enter their area but no one looks up. The teams are used to working in a busy environment. What could be a distraction to them is instead a non-event. The pairs of developers are deep into their own conversations about how to implement the stories they are developing. Unless or until we ask for their attention, they stay focused on their work. The team lead, Joe, however, does come over to us with a friendly smile. After introductions are made, he takes great pride in describing his project, building an open, reusable and scalable architecture and framework for enterprise mobile apps for iOS and Android. With a sweep around the area, he explains their Kanban process to us and the complexities involved in keeping the back-end Ruby-on-Rails server development coordinated with the front end iOS and Android development. He explains that their team is challenged by an increasingly common issue for modern development, the proliferation of multiple technologies necessary for the success of a single project. In the case of Ionic Mobile, they must support a Ruby on Rails server, 3 iOS device form factors, and a myriad of Android OS versions and form factors.

Joe goes on to explain that the team chose to break up into sub-teams, each addressing a specific technology. Currently, the Ionic Mobile project is comprised of two teams: the Ruby on Rails server team and the iOS team. The Android team is in the process of being kicked off, which we'll talk more about in a minute. Each team has its own electronic Kanban (Huboard, an open source kanban viewer for Github issues), but both are displayed on the same monitor. In addition, both teams are collocated and participate in the same standup meeting.

As Joe is talking, we look around the work area and see many familiar things. In addition to the pairing workstations, we see a lot of sticky notes and drawings on whiteboards, screen mockups pasted to every vertical surface, and a Jenkins continuous integration server building the system and running every automated unit, integration and user acceptance test.

[Click on image for larger view.]

Figure 6. The Ionic Mobile war room.

User Experience
Thanking Joe, we move next door to the User Experience (UX) team. (See Figure 7). This team acts as a shared resource for every development project and is comprised of graphic designers and user experience specialists. Since different projects have different UX needs, having a single UX team allows them to scale efforts appropriately for each project throughout the project lifecycle. While some teams have one or more dedicated designers, others only need part-time help.

[Click on image for larger view.]

Figure 7. The user experience team.

Keenly observing the design team, you turn to me and ask, "Why aren't they pairing?" Great question! Our designers do pair some of the time, finding that tight collaboration is extremely beneficial. However, they also want time to themselves just to think through different ideas. Design is different from development in that they are not producing a final product. That will be done later when developers implement the ideas generated from the design team. From a pairing perspective, think about the designers doing their work as a series of spikes, testing out different ideas with wireframes and prototypes, followed by usability tests to validate or invalidate their assumptions.

One interesting phenomenon we are experiencing with this team is their evolution from a graphic design team, to increased focus on usability, to the ultimate role of full front-end development, realizing their designs in the final product's technology. This is especially true in applications where the front end user interface is created declaratively, e.g. with HTML, and not by actual programming.

Shared Spaces
As we continue to explore the 7th floor, we pass one of our videoconference rooms, colloquially called a Halo room. I'll leave it to you to guess what some of our developers do during their lunch period. In this room (See Figure 8), we see one of our teams conducting their regularly scheduled demos with their customer. Because Asynchrony customers are located all over the country, we often do not have the luxury of having them sit with the team every day. Instead, one or more members of our teams act as a customer proxy. Often this is either the team lead or the Quality Assurance lead.

[Click on image for larger view.]

Figure 8. Weekly product demo.

Heading toward the stairwell to visit our 6th floor secure area, we see the Ionic Mobile Hackathon in progress in our large conference room (See Figure 9). This is a company-wide initiative to boost progress for the Ionic Mobile Android SDK and mobile apps. Since Ionic Mobile is envisioned to be a framework for building apps across multiple platforms, we issued a company-wide challenge to leverage the existing capabilities and extend them to Android. This Hackathon challenge creates an energy and excitement not possible in an ordinary project and represents the kind of experimental approach to our work that Agile fosters. It's plain to see that the developers are taking great joy in showing off their work, much of it different from their everyday projects (See Figure 10).

[Click on image for larger view.]

Figure 9. Ionic Mobile Hackathon.

[Click on image for larger view.]

Figure 10. Ionic Mobile Hackathon results.

A quick trip down a flight of stairs takes us to our secure floor where we work on our military projects. Of course, I can't show you anything sensitive but we can talk about the similarities and differences between our work on these projects and our commercial projects.

We make a quick stop by my office so I can tell a humorous story.  (See Figure 11) You see, when I first started at the company, I was given an office. As our company CEO was showing me my office for the first time, he was simultaneously saying "But you aren't going to be in it, right?" We've learned from experience that project leads, customers and the like all need to be in the war room at all times. I use my office so infrequently that it has turned into a secondary conference room. (The backpack behind me is actually an extremely sensitive radiation detector!)

[Click on image for larger view.]

Figure 11. Mark's office.

The Mobile Field Kit
Walking over to the Mobile Field Kit (MFK) project (see http://www.asynchrony.com/capabilities/tactical-collaboration-tools/), I smile with pride and explain that this has been my primary focus for the last five years. (See Figure  11) Scanning the war room, we see familiar elements including the open spaces, prodigious use of white boards, the Kanban board, pair programming and the continuous integration server. I explain, a little embarrassed, that some of our automated builds are red because some of our user acceptance tests aren't passing at the moment.

[Click on image for larger view.]

Figure 12. The MFK war room.

One difference we see between the MFK project and the Ionic Mobile project is that, while the teams are roughly the same size, the MFK team acts as a single, cohesive unit without breaking up into multiple sub-teams. (See Figure 13) At first blush, this seems unintuitive since the MFK project has even more technical variety given the number of external devices and sensors that need to be integrated with the software. There are two primary reasons for this. First, the MFK software technology is relatively cohesive, with most development work done in Java on Windows computers, Linux computers and Android devices. Second and perhaps more important, is that the MFK is a fielded military system that requires 24/7 on-call support as well as on-site support during end-user training and exercises. This means that every member of our team must be able to troubleshoot not only our software but also the many different devices and configurations that make up the entire physical kit.

[Click on image for larger view.]

Figure 13. MFK team collaboration.

Another difference between the two projects is that the MFK is a long-lived project (over eight years) while Ionic Mobile is only two years old. As such, the MFK has a much more sophisticated Kanban process, reflecting not only our software development process but also the process of scoping releases and creating stories from high-level features. You can see on the left side of Figure 12 our three corkboards used for our Kanban. We've resisted moving to an electronic Kanban since the entire team is collocated and an electronic tool can't possibly show the level of fidelity that 96 square feet of corkboard can provide.

Final Thoughts
As we leave our offices and say our goodbyes, I hope that this virtual tour has given you a flavor for how we do Agile at Asynchrony and maybe seeded some ideas for your own work.  Every project is different, every company is different, so experimentation is important to find what works for you. In that light, don't let anyone dictate to you how you achieve agility, not even me. Take the good ideas, jettison the bad, and keep improving. How we do agile now is very different from five years ago when I started at the company. In five more years, I'm sure it will be different again and we'll laugh when we read this article and reminisce about how naïve we were back in the good ol' days of 2012.

Happy Holidays from your Agile Architect!