During the past decade, the word "agile" got a lot of buzz in the software development community. Tons of articles, podcasts, conferences, and books were produced to push software development to its peak and get higher levels of productivity and to cope with the dynamic and the nonstop changes in software development and information technology.
Agile development promises companies, executives, and project managers that by adopting agile methods, teams' productivity will scale dramatically, more frequent code will be delivered, and companies will get higher customer satisfaction and better revenues. Yet through working with agile teams, there were both successes and failures, no matter how good the team was in sticking to agile principles and practices. Failure was not related to the discipline of following agile practices as much as it was coupled with the convenience and team members believing in these practices. Managers and team leaders should not expect team members to generate superior results while aimlessly following a set of practices shown to be successful with other teams.
From my observations, to get agile methods (or any other team process) to succeed is basically coupled with successfully getting team buy-in and igniting team members' motivation. Without team buy-in, no one will let any process really work and show its fruits.
It requires a paradigm shift for managers, team leaders, and executives to leave the industrial era management practices and the old managerial folklore. That folklore focused on machines (or treating people as machines), high throughput, productivity, and efficiency, rather than being people-oriented. That dogma lets managers believe that if two workers cannot finish a task on time, four can.
Let's visualize software process improvement as a three-tier pyramid, with Tools at the top. These tools help the team embrace the process in faster, easier to use ways.
The second layer of the pyramid is Processes, which are the steps, policies, constraints, and business rules. They are intended for a group of people to follow to achieve some institutional objectives.
The base of the pyramid is People, because people are responsible for implementing the process and using the tools.
Three-tier pyramid of priorities
Now, let's consider two scenarios: One that applies the pyramid categories from the top, down, and the other that applies them from the bottom, up.
Applying the pyramid from the top, down is very common in our corporations and organizations. Any manager or team leader comes through one of the attractive application lifecycle management tools , which has a portfolio of very successful companies using it and a bunch of cutting-edge features. This tool requires the team members (think People) to spend time learning how to use it and integrate it with their daily tasks. The manager convinces the company to purchase such tool and shows the upper management team how the work pace and team productivity will be improved by having this tool. The company then assigns a number of employees to learn how to use the tool and to create a process for the rest of the team members to follow in using the tool. The assigned team presents a set of training sessions to employees, presents the glossy interface, charts, and reports, and persuades them to use the cool features implemented in the tool. When all team members start to use the tool to apply the company's business process, the tendency to efficiently and effectively use the tool and follow the process correlates with the team's buy-in and the convenience of using the tool.
But if the tool or process is too complex or it is of no significant benefit to the team members (requires more effort and time), the adherence of the team to this process and acceptance of the new tool won't be as charted in the beginning. In that case, either the process initiative fails or other enforcement processes are applied to force the team to abide by the set of processes that the company has issued.
The expected failure would happen because People, who are the main focus and the key factor for beginning any new process improvement initiative, were not included in the decision. Without people, nothing will be done. In other words, without them, it's nearly impossible to achieve a sustainable and successful process that flows naturally through a self-organized team, where follow-up becomes an accessory or secondary action, but the work is done by highly qualified and motivated team members who work in harmony.
However, if this scenario were followed from bottom up (considering people first, then processes that they follow, and the tools they will use last), the possibility of successful adoption and buy-in would be much higher. This is because managers will be addressing the major problems and issues that hinder the team productivity and efficiency from the beginning and before putting anything into action.
It's important to talk with people and know their problems and to involve them in designing the suitable processes that they are going to follow. By allowing the team to search for relevant tools or invent one of their own, the adoption rate and success probability will be much higher than following the traditional way, as described in the first scenario.
We need to focus on the fact that software development is intrinsically a human activity. People are the most important factor for the success of your project. Team morale and motivation is crucial in the working environment.
People are messy, aren't perfect, and don't follow a Gantt chart. The book titled Peopleware by Tom Demarco and Timothy Lister (cited in Resources) sheds the light on this issue with a very obvious resolution. As summarized in their book, the most frequently noticed cause of failure was "office politics." Included in these office politics are the public relations issues and staffing problems, disagreement with bosses or clients, lack of motivation, and high turnover. It's obvious that the major problems of our work are not technical ones, but social in nature. However, being people-oriented and putting people first usually takes the lowest priority.
Demarco and Lister also talked about "The High-Tech Illusion: most people apply high-tech, using the latest technologies, best tools, and powerful hardware components to develop products or organize affairs. Having to work in teams, projects, and other close working groups, we are in the midst of the human collaboration business.
Some managers unintentionally act like someone who loses keys on a dark street and looks for them on the adjacent street because "The light is better there." Most managers put more effort and concern on the technical rather than the human side of work because that's easier to do.
The baseline of this discussion is to grab the attention of agile adopters in leadership and managerial positions to this prudent fact: Focusing on people is crucial and a primary pillar in the success of businesses, as it was stated in the Agile Manifesto
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The Agile Manifesto clearly puts more value on the side of human collaboration and embracing change over updating tools or alignment with plans and contracts. However, teams tend to focus on the tools and processes and discard the major, essential enabling factor behind these tools and processes, which are the humans who will be using them.
We need to stop adopting the attitude that people are gears in a machine: If one wears out, it can be replaced easily by another one. It is critical for leaders to show more respect and appreciation to their employees, to include them in making decisions about what might affect them greatly, to take their opinions and feedback seriously, and to show that respect through appropriate displays of warmth, compassion, humor, concern, interest, and understanding. Some call this "the human factor." But too many managers are threatened by anything that their workers do to assert their individuality.
There is not a people store from which the software team can be rebuilt. When focusing on the dynamics of development, we assess people's value based on steady-state characteristics like lines of code or number of documentation produced. However, a catalyst person or senior team member can be critical to the overall team success. Some team members are productivity agents and team motivators. The effort of one of them is much worthy than the efforts of one or more team members who merely get their tasks done.
- Tom Demarco and Timothy Lister. Peopleware: Productive Projects and Teams (Second Edition). Dorset House (1999).
- Explore the Rational software area on developerWorks for technical resources, best practices, and information about Rational collaborative and integrated solutions for software and systems delivery.
- Subscribe to the developerWorks weekly email newsletter, and choose the topics to follow.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools, as well as IT industry trends.
- Watch developerWorks on-demand demos, ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
Get products and technologies
- Download a free trial version of Rational software.
- Evaluate other IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
- Join the Rational software forums to ask questions and participate in discussions.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Join the Rational community to share your Rational software expertise and get connected with your peers.
- Rate or review Rational software. It's quick and easy.
Aya Elgebeely is currently working in application development in the ACGC department at IBM in Egypt. Previously, Aya worked as a software engineer within agile teams for two years at Symbyo Technologies LLC, headquartered in Tampa, Florida. During these two years, she played different roles, including agile development and testing, process development and monitoring, working with different clients, and doing requirements analysis and project planning. Aya also worked as a teacher assistant in the department of computer science in the faculty of computers and information at Cairo University for two years, where she taught software engineering methodologies, programming, and other computer science-related topics.