limitations of agile software development

Limitations of Agile Software Development

Bruno Collet, MBA, Independent Project Manager & Auditor 1 www.brunocollet.com


January 14, 2009 Bruno Collet, MBA Independent Project Manager & Auditor [email protected] www.brunocollet.com

Owner, Synapsys Canada www.synapsys.ca

Check the free Agile audit tool Agile Benchmark at www.agilebenchmark.com

______________________

This document is a compilation of posts from my blog Execution in the Information Age (www.brunocollet.com/blog).

Agile has become so popular among software professionals that we sometime refrain from criticizing it for fear of being tagged as "behind", "old school" or downright stupid. Fortunately, experienced IT professionals know better and acknowledge that Agile has limitations.

Allow me to play the devil's advocate.

Agile was created in large part in reaction to the predominant – and now infamous – waterfall model, and to a lesser extent to all "traditional" methodologies. But did we question the assumption that Agile was indeed superior to traditional methodologies? Although many projects using traditional methodologies failed, many others were successful. Do we have reliable evidence to back the assumption that Agile methodologies are more successful than traditional methodologies such as IBM RUP, CMMI, Prince2, or RAD? The truth is we don't.

Better questions would be:

− When does Agile make sense compared to traditional methodologies?

− How can we combine Agile with traditional processes to better address a specific situation?

In order to try answering these questions, we have to look at the limitations of Agile.



1. A team of stars

Agile has been designed by experienced, smart, and high-achieving people. A friend wisely pointed out to me recently that they naturally designed agile for people just like them: stars. Not everybody's a Martin Fowler, a Ron Jeffries, or a Jeff Sutherland. You could have given them any project, with waterfall method or even no method at all, and they would probably have succeeded. Indeed, not every group can be motivated, experienced, and skilled enough to self-organize into an efficient team, come up with lightweight processes, and collaborate seamlessly to achieve that great agile teamwork.

Take average individuals in you workplace and imagine what would be the outcome if you trusted them to self-organize and to choose the best way (at micro-level) to reach the desired result, without any close supervision. You might be quite disappointed. I'm not saying that individuals are not qualified, I simply emphasize that it takes more than the average Joe to achieve agility.

Does your team have the agile potential?

Do you have the agile potential?

Do you have the raw individuals to form an agile team in your organization?

Be honest.

If you answered "no" to some of these questions, it doesn't mean that you cannot become agile. It means that there might be some intermediate steps to take before getting there. In my opinion, these steps typically involve adapting the work culture by progressively empowering teams and individuals, training, and hiring the right people.

2. Fit with organizational culture

I have worked with several different organizations. In one of them, directors can be 30 years old with blue hair, job definitions were broad, and processes were defined independently by each team. In another one, respecting the chain of command and job responsibility were keys to survival, and it took me a couple of days to go though the company's policy manual. This illustrates two diametrically opposed cultures. Which one do you think is more suitable to implement an agile team?

Enabling agile behavior requires a great dose of individual and team freedom. It translates into cross-functional, constantly adapting work, and switching roles as needed. It also entails adjusting processes continuously to reflect the current situation. More than anything, it means that processes are secondary to people.

As you can imagine, companies that traditionally emphasize narrow responsibilities, policies, processes, and one-size-fits-all methodologies, are particularly at odds with agility. These characteristics form the organizational culture, which pervasively influences all work and behavior throughout the organization. Unfortunately many companies still apply these industrial-era principles. To make things worse, changing the culture might be the one most difficult thing to do for an organization (after all, the culture is the people who are part of the organization).



Nonetheless, some rigid organizations can still benefit from agile. They succeed by "spinning off" groups of people who are in theory working within the organization but who can work in relative independence. This is also how large, rigid companies enable innovation. Indeed innovation and agility are deeply intertwined. Successful organizations are ambidextrous.

What can you do if agile doesn't suit your organization culture? The easiest solution would be to set up a team that can work independently from the rest, and is not subject to the same rules. People in this team should be fresh hires or should not fit well within the traditional organizational culture. But on the long term, changing the culture implies changing leadership. Assuming that people can change only to some extent, you know what it means...

3. Small team

Agile teams are restricted in size for several reasons:

− The team has to self-organize, implying an efficient order emerging from temporary chaos. Obviously this process would be too long for larger teams.

− Team members have to be able to communicate spontaneously with each other and with other stakeholders (i.e. without setting up meetings, sending emails, etc.).

− All team members participate in the day-to-day management (tasks, changes, impediments, etc.).

− Team members need to understand what others are doing (cross-functional perspective, team ownership), help each other with ease, and collaborate without centralized control.

− The team has to be co-located (this limitation will be examined later).

As you can see, agile is a highly participative style of software development. Therefore, the number of participants significantly affects the efficiency of the process.

The daily scrum of the Scrum agile methodology perfectly illustrates this limitation. The daily scrum is a 15 minutes meeting involving the whole team. The ScrumMaster (Scrum word for team leader) goes around the table and each team member mentions the status of tasks and other issues such as impediments or changes. I managed Scrum teams of sizes varying from 3 to 8, and I must admit that in my opinion 8 is about the upper limit. Beyond this size, communication becomes inefficient.

Assuming that large projects tend to require large teams, this restriction naturally extends to project size.

Fortunately, there are solutions to somewhat alleviate this limitation. If a large project can be divided into a number of relatively independent smaller subprojects then each part can be implemented by an agile team. However, this solution is not without its own quirks:



− There has to be a "higher-level" project management to coordinate the teams. This higher-level can be managed with a more "traditional" methodology. Note that we see here a situation where combining agile and traditional methodologies makes sense.

− When dividing the project into agile-manageable subprojects, we minimize dependencies through architecture. However, agile measures progress based on working software, i.e. delivering features. Dividing a complex project based on architecture yields a very different result than dividing it according to features. Therefore, the agile definition of "progress" – one of the agile cornerstones – has to be adjusted.

4. Collocated team

Agile emphasizes that face-to-face, spontaneous conversation is the best form of communication. While we can certainly agree on the benefits of this form of communication, it severely limits agile applicability. Moreover, this agile principle extends beyond the development team since other stakeholders such as business analysts are required to be collocated.

What does it mean in practice? Imagine that a team member has a question concerning a use case. She should be able to get up, walk 10 meters, ask the business analyst or key user for clarification, and get back to work. Consequently, office space has to be physically arranged according to agile projects so that all stakeholders involved in daily activities are located at the same place (let's say within a minute of walking distance).

We can easily think of a number of situations where this limitation prevents using agile:

− Office space organized by departments: In most organizations, offices are organized by departments such as IT, marketing, accounting, sales, and so on. Moving people around according to agile projects is unrealistic. Even if it was possible, it would negatively affects other parts of the business.

− Distributed environment: Developers are often distributed throughout the organization, whether in the same branch or in different branches (or working from home). Just like for the previous point, moving these people is unrealistic.

− Subcontracting: Many organizations partly or completely outsource software development. Assuming that some roles such as business analysts or key users would be located at the company, this situation doesn't comply with the agile collocation principle.

We have to acknowledge that there is no substitute for face-to-face, spontaneous communication. Consequently, the best solution is to restrict the agile team to people working at the same location, knowing that even if it were possible it would constitute a less-than-ideal team.

Alternatively, we can try to make the better of it by managing a "virtual" agile team:

− Collocate as many team members and stakeholders as possible.



− Set up an "open phone line / video chat / IM" policy to make sure that spontaneous communication is still possible between distant stakeholders.

− Leverage collaborative software (although in my opinion it has little effect).

− Schedule frequent in-person meetings with distant stakeholders.

− Start the project with everyone at the same location for a few days in order to build team spirit.

5. Where's my methodology?

Software development methodologies include several processes, such as analysis, architecture, implementation, project management, configuration management, and so on. However, most agile methodologies, such as Scrum for example, do not define processes. In particular, most agile methodologies do not define any project management processes. Whether we're agile or not, we need to manage changes, risks, budget, and so on. As far as I know, lightweight processes doesn't mean no processes at all! And not everything can be stuffed in short daily meetings without written records.

As a consequence, most agile software development processes are not methodologies, they are no more (and no less) than sound principles and practices to manage the day-to-day operations of small projects (I would call that "team management"). This is great, but hardly enough to manage projects. Similarly, the person managing agile teams is more a team leader than a project manager, the main differences being that a team leader doesn't manage budget, scope, planning, and reporting for example.

Fortunately, complete agile methodologies are emerging. I personally like OpenUP, because it is minimal, complete, and configurable through the Eclipse Process Framework. It is to my knowledge the only agile software development process that is a methodology (call me picky).

Unless you choose an agile methodology that encompasses all needed processes, you should combine it with a methodology that define these processes and rely on agile for day-to-day team management. Moreover, keep in mind that you need to remain credible with upper management and other stakeholders, who are likely to judge your competence based on processes such as scope, risk management, planning and reporting.

6. Team ownership vs. individual accountability

Agile development stresses the importance of team ownership in order to improve teamwork and therefore overall results. Team ownership is a very appealing concept, but how can we implement it since an organization's performance-reward system assesses individual performance and rewards individuals, not teams?



If we rely exclusively on individual accountability, we tend to generate selfish behavior that can affect teamwork. If we rely exclusively on team assessment, we overlook that individuals perform differently in a given team, creating opportunities for underperforming team members to get away with it and lessening incentives to perform in a superior way. Obviously we have to find a way to take both these perspectives into account.

Actually this problem can be solved elegantly by defining two levels of performance-reward:

− Team level: The team is perceived as a single entity from management's point of view. Management assesses teams' performance and allocates rewards to teams in the form of points.

− Individual level: Team leaders (or whatever the title is) evaluate teams members rewarding them with points.

In order to have a short feedback loop, assessment should be done frequently (every month for example) using a lightweight system incurring very little administrative overhead.

The final performance of an individual is calculated using both team and individual scores. For example, team A has been given a score of 7 out of 10 by management. John, who is a member of team A, has received an evaluation of 8 out of 10 from his team leader. John's final score might be an addition (15 out of 20) or a multiplication (56%) of these two scores, for example. In the end, the manager is responsible to reward John based on his final score.

Thanks to this kind of system, we encourage teamwork but we still take individual contribution into account, effectively reaching a balance between team ownership and individual accountability.

limitations of agile software development

Documents