Wouldn't it be nice if we could make an educated guess about the Agile potential of an organisation without doing a full scale assessment? Let's look at signs that any observer can notice when spending a few hours in the workplace.

1. Detailed procedures about everything: They assume that there is a reusable recipe for any situation. They ignore that many situations are unique because needs and context change everyday. Procedures and processes are not bad in themselves, detailed directive procedures are.
2. Client out of sight: In some workplaces the client is a kind of abstraction, an entity we contact by email and the occasional meeting. Collaboration is reduced to a few key events such as capturing requirements, reporting at milestones, and validating tests results, without much else in between.
3. Coworkers out of sight: Individual cubicles with high walls, narrow corridors, and the like. Workplace arrangement significantly influences how people behave and collaborate. If it fosters individual, analytic work, don't expect much collaboration beyond the few formal meetings and emails.
4. Meeting mania: A by-product of the other points, meetings are scheduled for any reason. Most of these reasons would be better served by a brief face-to-face discussion. Unnecessary meetings introduce delays (rooms and people are overbooked) and tend to waste the time of many participants.
5. Detailed timesheets: They epitomize the belief that work can be forecast in detail. People consciously or unconsciously alter their behaviour in order for their daily work to fit in timesheets. Note that timesheets are not bad in themselves, detailed timesheets are.
6. Restricted access to internet and to personal email: Security hazard vs. work/collaboration tool. For me the choice is obvious, but apparently not for everyone.

I don't pretend this short list replaces a professional assessment, but it might provide a few hints.

How can we adopt Agile if the organisation seems at odds with Agile prerequisites?

Note that it is highly uncommon for an organisation to be just ripe for Agile. I have yet to see a workplace where Agile practices can be implemented quickly and on a full scale. In most cases, follow these simple guidelines:

• Choose scale: Identify pilot projects, teams, or organisational units
• Choose practices: Determine which Agile practices make sense and implement agile progressively
• Assess added value: Always keep in mind that Agile is not an end in itself. Assess objectively if and where it can add value.

This is the fourth in the list of agile limitations:

1. A team of stars
2. Fit with organizational culture
3. Small team
4. Collocated team
5. Where's my methodology?
6. Team ownership vs. individual accountability

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 affect 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.

This is the third in the list of agile limitations:

1. A team of stars
2. Fit with organizational culture
3. Small team
4. Collocated team
5. Where's my methodology?
6. Team ownership vs. individual accountability

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 in a separate post).

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.