Introverts: finding comfort in Agile

Agile transformations seem to require everyone to be an extrovert: isolated cubicle dwellings are quickly converted into open spaces, there are so many meetings to attend, with many opportunities and plenty of encouragement to speak up. The introverts, a large share of professionals in IT and software development, become increasingly uncomfortable as we learn how much working together, sharing space, and group discussion appears to be required by the new system.

Introverts need not worry. Agile way of doing business brings many changes, but it is not about making everyone suddenly become extremely outgoing. The Agile transformation itself, a relatively short time period of intensive education, organizational restructuring, and, perhaps, moving furniture, can be stressful and tiring for all. It can be especially tough on introverts, who prefer stable environment and few interruptions. However, once the dust settles, and the organization is firmly on a path to agility, both introverts and extraverts are able to find a comfortable spot within new frameworks.

Agile frameworks are built around working in small teams toward a common goal, building trust over time, and developing skills to help each other. The team members are encouraged to get to know each other, and teams are expected to stay together for a long time. An agile team is a perfect environment for introverts – a small group of colleagues, with common interests and motivation, in a stable environment.

A big part of Agile philosophy is about having a lot of communication between all people involved in a project. Communication in the corporate environment is often understood as large, long-running and highly ceremonial meetings, delivering official reports, addressing large groups of people – all the activities that make introverts want to run and hide. But most communication required by an Agile framework happens in small groups (as small as 2-3 people), and is built of casual conversations. It is also concentrated within the small team working together for a significant amount of time, where people had had an ample chance to build relationships, get to know each other well, and build trust. This is the kind of communication that introverts handle well, and often enjoy.

The toughest part of Agile setup for introverts is the office environment. Open space destroys any chance of privacy and time alone, while encouraging social chatter and frequent interruptions. However, one of the more important tenets of Agile philosophy is the concept of self-organizing team, that is, a team that it is in charge of its work and environment. Teams are allowed and encouraged to take control of their office furniture, in addition to everything else. Mature Agile teams with introverts get to re-arrange the office environment the way it works best for all the people on the team, and create opportunities for working alone or in pairs. Quiet spaces, no-interruptions-allowed zones, those traditional introvert heavens, reduce stress and boost productivity for both introverts and extraverts, as long as there is also a space for collaboration and communication.

Rolls Royce or Ford Model T?

This question applies to every successful idea.  Some ideas only make sense for a limited audience of Olympic-level talent, and others scale beautifully for a large population.  For example, the upscale resort at pristine Musha Cay, a tiny tropical island near Bahamas, accommodates no more than 24 guests, while Disney World hosts an average of over 52,000,000 visitors per year.

The philosophy of Agile Software Development started as a bright idea of a few very talented, very engaged developers who wanted to deliver highest-quality software while providing better value to their customers.  And so they did, with very powerful results.  They also shared their idea of Agile with others.

But is Agile a Musha Cay kind of idea, or is it more like a Disney World?  Will Agile Software Development benefit just the brightest, the most talented, hard-working and engaged, or will it help every average Mort and Elvis and their clients to enjoy better success?

In its early days, Agile was invented and embraced primarily by a small group of developers, the best and the brightest, and the most engaged. Through their painstaking work, Agile slowly found (or not) its way through the traditional organizations and processes, one conversation at a time. 

Now Agile arrives from the top, carefully tailored for the management approval, and is swiftly installed in IT departments, whether the entire cadre of employees want it or not, in one big organizational shake-up.  Is it the same Agile that worked so beautifully for the most talented few who embraced it, fought for it, and followed it with their whole hearts? Probably not.  But is it better than the alternative, that is, no Agile? 

Agile Manifesto: working software over other things

Manifesto for Agile Software Development second statement is about valuing working software over documentation and over things.

This is so simple and logical, it may even seem obvious: software development should be about software that works.   However, this is a new idea offered by Agile movement, and not the default choice in the contract-driven Waterfall environment.

The business of software development involves many different tasks, many of which are not as complex and unpredictable than building working software. Creating documentation is a common example of such a task.  It is tempting to deliver on those tasks and to declare victory based on easier-to-achieve results. It takes a lot more discipline to execute on the more complicated, core portion of the work required to create software - and deliver no less than the working software.

Delivering working software is raison d'être for the industry.  It is fundamental that working software is created and delivered, and it should be the focus of the industry - not documentation, nor other more or less significant artifacts.