A Software Team's Journey to Agile

[article]
Summary:

Did you ever wonder if a team needs some prerequisites before transitioning to agile? In this true story, John Lynch shows us the story of a team who teetered on the brink of dysfunction and then was able to create its foundation so team members could begin their agile transition.

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.

User Comments

1 comment
stephen donovan's picture

To manage the risk successfully one should have scum in their projects .With high competition, companies have to develop products fast and innovatively always adding value and greater customer satisfaction. In Scrum, it is important to learn and practice its basic principles which collectively and naturally help in effective management of risk. As a project manager i follow SBOK guide of http://www.scrumstudy.com

April 24, 2014 - 5:11am

About the author

John Lynch's picture John Lynch

Since his entry into the world of commercial software in 1989, John has been involved with solving interesting software problems. Whether moving mainframe print jobs to servers, or getting software teams to deliver their very best, he has provided creative solutions. John led the team responsible for inventing the very first mainframe to Unix print server system in the early 1990s. He holds 5 U.S. patents for innovations created during his as Director of Software Development. For John it is all about teamwork! 

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Oct 12
Oct 15
Nov 09
Nov 09