Share it

Announcement: Improving Boot Camp!

Learn to program, to be a consultant, and join Improving Enterprises, while getting paid for your studies.

Sunday, April 6, 2014

No fighting in the war room


“I will stand up against development to fight for software quality!” – said a perspective QA manager. She was smiling, but in way that left no doubt – she meant every word, and she was good at fighting and winning against bad things and bad people.

As a developer, I liked the candidate’s strong stand on quality, but was not sure why we should be fighting. The QA was a part of Dev organization, and a new QA manager was going to report to Dev manager. After the interview, we discussed how our Dev team works with our QA organization, cooperating and helping each other. We all had a common goal of producing high-quality product, and fighting was nobody’s idea of fun, nor was it helpful in achieving this goal.  

As it turned out, our team was both lucky and smart, creating and maintaining a helping and cooperative spirit in the office. As we learnt through talking to this and other QA manager candidates, there were plenty of companies where testers fought against developers. QA groups won by finding enough quality issues with the product to prevent delivery.  Developers won by getting the product delivered, despite known problems.  A strong development group put a QA team at a disadvantage, while a thorough testing created problems for the developers. Which makes no sense, because having great people and organizations in both Dev and QA should make everyone's lives better, not worse.

As satisfying as winning is, it is important to keep in mind the overall goals of the organization. In IT and software development, it is usually creating and delivering a quality product for the customer.  Nobody wins if the product is not tested properly, is of poor quality, nor if the product is not released to the user. Everybody wins if QA and Development (and the rest of the organization) work together.


Friday, March 28, 2014

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.


Thursday, March 13, 2014

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?