A Software Team's Journey to Agile

This is a true story about the journey of a software development product team that moved to agile. Of course the company name, software product name, and team member names have been changed to protect the innocent, the guilty, and to spare anyone from embarrassment. For story’s sake we’ll call the company “Portabella” and the software product “Swizzle.” Swizzle is a special purpose, high-level programming language providing industry specific functionality for its customers. The Portabella Company acquired Swizzle in the mid-1990s because it was seen as a strategic piece in building a wider set of customer offerings.

The original location of the Swizzle development team was not in the location preferred by the Portabella Company. The distance between the two locations was 400 miles. As software development manager, I was hired to relocate Swizzle to the Portabella office location. My instructions were to inform all team members they would be able to keep their jobs on Swizzle if they were willing to pack up and move the 400 miles to the new location (at their own expense). Four hundred miles can represent quite a culture shift, so it was not surprising that no Swizzle team members were willing to move.

The original Swizzle team size consisted of approximately eight full-time members. This included software developers, testers, technical writers, etc. The year was 1997 and the old Swizzle team could be considered very agile even by today’s standards! The development environment had very high levels of automation and continuous build and testing. The entire team had a sense of ownership. Coming from a small company environment they were naturally very customer oriented (realizing who pays their bills). I needed to figure out how to build a brand new team while keeping the good things that were in place.

The Portabella Company allowed me to open up a few job requisitions to replace the existing Swizzle team. I had managed to have a calm discussion with the old team about the transition period and we came up with a transition plan. Next up: form a new team.

I kept in touch with co-workers from my former company, and I managed to convince three of them to move to Portabella to begin building the new team. The knowledge-transfer period was to be a series of one-week training sessions that were gapped by a one-week code study by the new team. This continued for a period of eight weeks. I, too, was involved in all knowledge-transfer sessions in addition to gaining a complete understanding of the existing hardware, network, and build and test automation systems that were in place. I realized early that if anything were to go awry with this transition I would need to have first-hand knowledge to allow me to quickly bring others on to the new team.

When the new team had been established, its focus in the beginning was survival. The team goal was to learn enough about the Swizzle product to be able to respond to customer technical support calls. This mode of operation continued for two years. The way the team operated could not be considered agile by any means. When the team members focused only on survival, they reverted back to waterfall or worse, chaos!

Portabella decided to put me on other projects for a few years. I handed over the reins to one of my trusted managers and went on my way. Several years later I was asked to return to run Swizzle after a few rounds of staff cuts, etc.  I was shocked at the state of the product on my return. I couldn’t believe how things had degraded in such a short period. This team that had once been the model of agile had sunk to being dysfunctional.

The first thing I noticed was that none of the team members spoke to each other. Remember, this is a co-located team that worked in a space in which the cubicles were right next to each other. First order of business: Get people speaking to each other again as real human beings! This means no more hiding behind email blurts and instant messaging.

I then set myself up in a cubicle next to the team. As a manager, I was “entitled” to an office, but I chose a cube. By being in a cube, I could spark ad-hoc conversations in the cube aisle and ask team members to roll their chairs into the aisle for a discussion.

Next up for me was to assess the state of the automated test and build environment. I discovered that it was limping along and was in need of some tender loving care. To address this, we put a plan in place to implement automated nightly builds on all platforms and integrated system tests on all platforms. The results of the build and test cycles were placed on an intranet web server, and email alerts were set up to notify the “offenders” who broke the build or caused regression test errors.

Once those two foundational problems were solved we went into triage mode on the state of the product; to go into triage means we were doing an assessment of each and every bug in the product. We spent two weeks going over each and every bug in the product. During this time, we learned that technical debt had been steadily on the climb; our team was small and we couldn’t afford to let technical debt get out of control. It was a painstaking process to go through each and every bug. Some bugs were closed and others had priorities adjusted. We included bug fixes and refactoring in everything we did. Now you may be wondering “Hey! Where’s the agile part?” Here it comes!

At this point in the process I met with the product owner (a former power user of Swizzle) and we had an honest discussion about the state of the product. I gave him an agile primer on how things work, and he was all for changing the way software development and product requirements were being done.  We began with some simple product billboard statements and began to internalize them every day. A billboard statement is something you would put on a “highway billboard” that captures the essence of your product. One of our key phrases was “Swizzle Rocks!” I began to use the phrase as often as I could (without being too annoying) to instill a sense of pride and ownership in the team. I believed the team was now ready to start with agile.

I chose to go with agile as a methodology because I had used it with other teams in the past. I had some struggles with the process on one team I worked with, however, so I took what I learned from that experience and adjusted things to work with the Swizzle team.

Do you notice all the things we had to get through just to begin being agile? We had to repair basic human interaction and the respect among team members. Automation and routine processes had to be reestablished, and we had to restore trust, ownership, and accountability— all of which were once missing. Once all these things were in place, we could pursue normal agile practices. We then began release and sprint planning sessions and conducted daily standups, along with demos and retrospectives. The team decided to rotate ScrumMasters at each sprint in order to improve the skills of all team members. Swizzle began to deliver value regularly and consistently. The team and the product had made it back! And of course...Swizzle rocks!