There are companies that view software as serving their operational needs, and then there are organizations that view their software as empowering and enabling their business, and there are yet some organizations that actually create software for living and sell it. The first category of organizations prefers to have traditional development methodologies that reflect Command-and-Control style of development environments. The latter two types of organizations, software as enablers and software as livelihood; have always tried to implement non-traditional methodologies for rapid development, speed-to-market, and consistent quality delivery considerations.

Agile Software Development methodologies provide ways to several of these new-age development challenges. Extreme Programming is one such Agile methodology. Like any other methodology, Agile practices have their share of criticism. I have always tinkered with the methodologies when it comes to implementation. Methodologies are just that, unless you customize it and experiment what works for your organizational setting and what doesn’t, they just remain another set of glorified preachings. Along the way I have found and implemented a methodology that’s agile, influenced by concepts such as Pair Programming and principles of Extreme Programming. Or may be ‘found’ is too big of a word, how about we institutionalized it!

Here is how the methodology works. The central idea of the methodology has influences from concepts such as manufacturing style of software production, buddy system, and Pair Programming. The development team is divided on as needed basis into teams of two programmers. The idea of “two brains put together are usually better than one” is the only similarity between Pair Programming and this methodology that I call as “Teams of Twos”. New development work is divided into sizable work units and a pair is responsible for implementing it. So, each unit has two developers working on it, and each developer can be part of multiple teams (of twos of course). A sizable work unit typically consists of two or more subunits that they show up as typical work unit in a classic work breakdown structure. The idea is the pair of programmers work on these subunits in parallel and put them together when they are ready. The pair spends considerable upfront time on the implementation details, and the integration points are discussed and conceptualized upfront. The pair at any point knows their subunit as well as their partner’s subunit and how they will be implementing it. The synergies, flow of information and the knowledge of detail are incredible.

Let’s look at some of the benefits we achieved with this “Teams of Twos” model while highlighting how the process really works and how it achieves the specific benefits:

1. Unit Synergies
If you are familiar with Project Planning and Gantt Charts, you know the concept of unit dependencies. You can’t start a unit of work unless some other unit is completed as it depends on the implementation of the previous. This sort of work breakdown creates several impediments for sped to market considerations. Organizations that want to be agile and nimble can’t afford to have these dependency scenarios in software development as they hamper the progress of the projects. If you imagine building a car in a manufacturing unit, they don’t wait until a steering wheel is built to build the wheels and axles. They all are built in parallel and assembled at the end, or in stages. That’s the same idea here we try to bring to the table. It’s not a new concept; this process is tried before where individual software components are built in isolation (that’s the key phrase), and when it’s time to assemble or integrate, then the lack of synergies in implementation of the individual components prohibit quick integration, and teams end up spending considerable amount of time in integrating so-called integration ready components. The difference in “Teams of Twos” model is that individual components are built in parallel in a collaborative way. The integration points and implementation details are discussed upfront so there are no surprises. Even during the development of the components, the twosome has a way of adjusting the implementation based on new findings in an iterative fashion.
We have built entity models in parallel to service layers, user interfaces in parallel to page transitions, and achieved in true integration ready components. We often jokingly referred to this as “Leggo Programming” for the ease of assembly and the insignificant time we spent on integration of units.

2. Big picture
In a typical software development department, you will find one or two big-picture guys, couple of architecture level seniors, and handful of programmers who implement it. This “Teams of Twos” model encourages every one to get out of their silos and see the big picture from the beginning, and relate to how it will be implemented. Without denial, this is one opportunity all developers thrive to get to; few get the opportunity in traditional models. As the road map is clearly laid out with this model, developers know what they are working on now, and what’s coming down the pike, and how this fits into the end goal. All the teams are aware of the project technology blue prints that set the direction of the product.

3. Ownership, Collaboration
Ownership and collaboration form the central core of “Teams of Twos” model. There is extremely limited scope for blame game in this model. Excuse such as “I didn’t know you were going to implement it like that” is out of scope in this model. Partners in the teams develop this camaraderie, and seek each other’s advice on how to achieve something. Developers are no longer “the guy sitting in the dark corner” any more. Teams meet with other teams in informal Scrum settings to share any issues that they encountered and how they solved it so others can watch out for those.

4. Contingency for Attrition
This is a severe problem for smaller organizations with less than 25 developers. As the resources are limited, often the same expert developer is responsible for several key projects. And, the thought of what happens if this guys turns in his notice just sends chills down the spine of any IT management. Losing a productive employee is always painful, and with its underlying principle of partnership, “Teams of Twos” is a great help in this regard. Your key processes are no longer buried in the brain cells of one guy. As teams work in pairs, you always have his/her partner that can quickly step up and take over the processes.
As part of experimentation, we even swapped subunits from partners and interestingly we felt as if I was implementing my partner’s subunit from the beginning. Sincere subscribers of “Teams of Twos” model often can tell how their partner would implement a component even before the partner starts working on it! This is a surprising revelation noting how coding styles and programming preferences vary from developer to developer, and how programmers don’t like to maintain someone else’s code.

5. Healthy Competition
“Teams of Twos” with its inherent underpinnings of camaraderie, rapid development, and collaboration encourages healthy competition among partners and among other teams. No single person is blamed for missing deadlines; the team is. And no one wants their partner to get blamed for their lack of progress. The other teams get inspired by the progress and spotlight a specific time is enjoying thus spurring healthy competition.

6. Feedback as integral part of the process
There is no scope for finding out something doesn’t work late in the game. As the development process goes through iterations, and with constant collaboration it’s hard to imagine things slipping out of hand only to be found during delivery times.

7. Skill building
Another important aspect of “Teams of Twos” is that the only limiting factor is the individual itself. In other words, in classical settings, a junior programmer will always be a junior programmer. A senior will always be the only senior. Because of the partnership involved, members can embark on calculated adventures where they get an opportunity to work on something that they have never worked. If your partner is a pro in a technology, you can take his/her guidance and implement that technology in your subunit (of course, only if that technology is relevant to the solution). We have seen the “Teams of Twos” approach help programmers expand their skill set and skill level, and provide a level playing field for programmers. I myself benefited from this aspect partnering with partners that are a level ahead in certain technologies.

8. Productivity
The productivity gains we have measured are incredible. With several parallel activities that are unthinkable in traditional methodologies, the delivery times are cut down to 40% in some cases. The integration effort is a breeze. Quality is noted to be on an up tick or at least consistent. We enjoyed the lowest number of deployment issues compared to other development teams in the organization. Another notable gain is the transparent injection of best practices in software development. Best practices, due to the relative adjective of “best” are always a contending issue. One big stumbling block is the resistance from people to change ways in the name of best practices. “Teams of Twos” model makes implementation of best practices very transparent. You would actually notice developers picking up neat conventions and standards from their partners without being told so.

Limitations:
1. Need of skilled resources
In some smaller organizations, teams are built around one superstar and everyone else is at very junior level. “Teams of Twos” model may not work well in this model. Though, the motivation for such organizations to get on “Teams of Twos” should be high as they can’t bet their farm on one single programmer.
2. Willingness to adapt
There is lot of scope for creativity as well as standardization in terms of best practices in “Teams of Twos” model. Programmers in your team should be willing to put their egos aside and sincerely try to adapt the model. This willingness to adapt is a challenge in the success of implementing any methodology.
3. Command-and-Control environment
In organizations that things work in Command-and-Control model, “Teams of Twos” method doesn’t work. “Teams of Twos” encourages big picture ideology, strategic thinking coupled with tactical excellence. In usual Command-and-Control environments, there is no scope for strategic thinking, and everything has to be in a pre-defined format, and little scope for strategic thinking at the programmer level. In Command-and-Control environment, roles are predefined in terms of what a programmer can do and how to do it.
4. Size of the organization
“Teams of Twos” is well suited for small to mid-size organizations due to its agile and nimble nature. It’s doubtful if it can work for larger organizations in its original form. The levels of hierarchies, the PMO office and other corporate procedures that come into play in larger organizations need to be carefully accounted for in the modifications.

Just like individual contributions play key role for any good process to work successfully, “Teams of Twos” highlights the individual contributions while emphasizing how collaborations and partnerships in pairs at grassroots level can bring greater success to organizations.