Organizations are nothing without structure.

Structures give people avenues for interacting with one another, and when there is a desire to accomplish work collectively they give us tools with which to share that work. There are many ways that organization an organization can choose to structure itself ranging from the very hierarchical structure in the armed forces to collaborative consensus models.

Agile development methodologies are applied in the context of developing software. They enable small teams to manage a lot of moving parts very effectively and efficiently. Can Agile principles and methods be applied to support organizations or collaborations with people who are not developing software?

A few key components of Agile principles are:

• Cross functional, self organizing teams.
• Client/Customer Collaboration.
• Individuals and interactions over processes and tools.
• Working Software over comprehensive documentation.
• Adaptive and Responsive to Change.
• Short Stand-alone Iterations over comprehensive, unfinished releases.
• Pair Programing.

Overview of Agile Methods

Agile Development Methods were created for the purpose of software development, which is very different from the day to day administration and coordination of an organization. Or is it?

Break large things down into little parts.

The projected length of many technology projects falls within the range of 6 months to 3 years. Software projects require an almost obsessive attention to detail as they can have hundreds (if not tens of thousands) of moving parts. Agile methods are founded on the notion that it's much easier (and effective/efficient) to work on many smaller projects, than it is to manage one larger one. When software is developed using Agile methods, instead of having one long term project that unfolds increment by increment, projects are broken down into 'iterations' and 'releases' that house complete working software units. These units aggregate with others as the development progresses, and when those gain a critical mass, the software is 'released'. Instead of having one big sense of accomplishment at the completion of a project, using Agile development methods, we feel accomplishment often.

Distribute knowledge broadly in the system and dissuade the idea of specialists.

Agile teams are cross functional and self organizing. This means that while they are responsible and accountable for a specific roll within their team and within a specific iteration of the project, their particular roll might change from iteration to iteration or release to release. One team member might take the 'managing' role for one iteration, and then pass that roll along to someone else for the next iteration. This is done so that the team capacity is developed as a whole, and team members have the ability to move from project team to project team, developing their skills on a variety of projects as needed. If one person has to drop out during a project, the other team members know how to perform that roll, and can step in easily. In addition to fostering a more stable development process, it also enables developers to build different kinds of skills, and to develop deeper relationships with other stakeholders who they might not interface with otherwise.

Create healthy redundancies.

To help further stabilize the development process, developers often work in pairs (Pair Programming). This enables the team to learn from and work with a variety of members, and gives each working unit of development two sets of eyes. It makes for a stronger design, prevents the bottlenecking of work, and stabilizes the project in the unfortunate case that someone has to leave.

Create feedback loops, and engage your stakeholders in the process.

In Agile development, clients are considered an essential member of the development team. They are seen as partners, and are brought into the lions share of development discussions. In this way, they develop a sense of ownership for the tools being developed. They understand the dynamics of the development process well enough to be able to set expectations and communicate with their stakeholders.

Consciously build rapport on teams.

Agile development methods call for regular 'face to face' meetings (this includes phone conversations) instead of email updates, instant messaging or the use of project management tools. This does not mean that they only rely on conversations exclusively. In fact, project management tools provide an essential structure for software development projects that use Agile. Scheduling 'Face to face' meetings with the team prevents developers from going into silos and enables the wisdom of the collective group to oversee issues as they arise. It also develops team rapport.

Map the project with clear outcomes and deadlines before the work begins.

There are different types of meetings that Agile teams have. A schedule of meetings, landmarks, and completion points are mapped before the development of the iteration and release cycles. Iterations require specific kinds of meetings in order to facilitate consistent and detailed movement through a project. They work together to understand each part of the project, and they all participate in breaking the working units into tasks. Each team member participates in estimating what kinds of resources (time, money, people, etc) each task will take. Once development (coding) begins, meetings become much shorter, and more regular.

Daily 'stand-up' meetings (coined that way because they should only last as long as people are willing to stand) frame the day in the context of the work completed yesterday, and setting up teams to help move any tricky parts of the process. If the client can participate in those meetings, it can be ideal so that potential bottlenecks can be addressed as they arise.

The idea is to make the system, and all the players, self and mutually aware and to make the project more responsive to unexpected limitations. It gives 'agility' to the development process. If better solutions are found in the process of development, or if there are changes in priority for meeting specific client needs, the project can respond. These shifts are not seen as aberrations or failures, but are expected and considered an essential part of the process.

Bridging Agile Development methods with Non-Profit Structures and Teams

Non-profit organizations, in contrast, typically organize themselves around static job descriptions and roles. Organizations would argue that this is because the work of administering an organization requires a diverse set of skills and knowledge, but the exact same thing could be said about software development. There are also similarities when you consider typical project life spans for organizational project development (6 months to several years).

Cross functional, self organizing teams, and pair programming.

In Agile development recognizes that there is a need for rolls and structures in a project: they reinforce accountability and give a project traction. There is a benefit to having a person serve as the 'bottom line'. What makes Agile different than typical organizations is the distribution and sharing of work widely within the team. I might be the project manager in one iteration, and a junior developer in the next. Most organizations are looking for a person to fill job description. Agile looks for a member of the team who is competent, and who is eager to learn.

Even when there is a small team of core staff, encouraging staff to share strategy meetings and develop ideas together creates a collaborative space, and encourages people to bring their full knowledge and skills to the work. Collaboration, on any level, fosters a system that is self aware, and able to work well together.

Short stand-alone iterations/releases over comprehensive launches.

Educational institutions are good at building large projects out of incremental and complete units. A year is broken down into semesters. The semesters each have a series of regular breaks. The syllabus outlines chronologically what is going to be taught each day. There are specific assignments that are graded and regular tests. In a similar way, when the life-cycle of a project is mapped from the start, it creates an environment that enables clear planning and collaboration within and across teams.

Client/Customer Collaboration.

Whether your organization is teaching something, selling something, doing something or creating something, if you are not getting input from the people you serve, it's a recipe for disaster. Regardless of what you are doing, if the people you are doing it for are not able to give you feedback, there is a likelihood that you are not being effective in your mission. Even if on a very slight scale, when you loose sight of where you are going, you are probably going to tend off course.

Individuals and interactions over processes and tools.

Exclusively or primarily using technology that in which communications are written dissociates us from one another. Building in 'face to face' communications and meetings, and making the objects of those meetings very clear, solidifies cohesion in a team, especially if there is a need to complete a lot of work in a short amount of time, and to activate a large body of people.

Working Software over comprehensive documentation

If long term projects are broken down into parts that perform functions independently of one another, the smaller successes can continue to serve the system even if the larger project changes course or for some reason stops.

Adaptive and Responsive to Change

When an organization anticipates changes in scope, and inoculates their stakeholders with the expectation of these changes (and the tools to steer these changes productively), it gives the project an agility that will invite success.

Long story...well, long.

The moral of the story? There are two versions:

1. If you are doing a lot with very little, Agile methods are designed to do just that, and will likely perform a great service to your organization if implemented well.
2. If you are doing a lot with very little, model yourself on an industry that has had no choice but to refine it's ability to motivate and organize an entire generation of geeks with an innate tendency for 'productive' procrastination and an attention span of 23.7 seconds.