These days, most people associate the word "agile" with "software development." However, people are applying the basic ideas of agile methods outside this type of work. Here are three stories of agile methods used in situations that are not in the context of software development. They illustrate how agile methods can be stretched to serve well in other contexts. From these and other examples, we have come to understand that agile methods consist of seven core practices, regardless of the problem domain: self-organizing team, deliver frequently, plan to learn, communicate powerfully, quality is not negotiable, measure value, and clear the path.
Agile Comic Book
In the training classes and workshops that we deliver, we use an exercise that we developed almost two years ago. We have the class divide into teams of four to six people each. These teams have to create a comic book that tells the story of the three little pigs and the big bad wolf. And they only have fifty working minutes to create it, including planning time.
We provide a Work Queue with more than enough items to occupy the team for the allotted time. The Work Queue is deliberately written
Advertisement
to be of poor quality as this is often the case in real life when starting out. Figure 1 shows the first five items in the work queue.
Figure 1: Sample work queue
We also provide the teams with a very strict schedule for the exercise which is an iteration in miniature. Whoever is instructing acts as the Process Facilitator for the exercise whose primary job is timekeeping, but also gets involved in removing obstacles and facilitating discussions. The schedule involves a progression through a single iteration of work with goal setting, task breakdown, three "work periods" of ten minutes each, and a brief team status meeting between each work period. Separately, we also often include a demo and retrospective as part of an extended version of the exercise.
We have done this exercise approximately one hundred and fifty times. There are some clear patterns. The teams find it very hard to do the iteration goal setting and task breakdown work, the initial planning for the iteration. The first work period of ten minutes is often scattered and includes people tentatively starting to write or draw, people continuing to do task breakdown and other planning, and a few people looking lost or baffled or uncomfortable. Somewhere near the end of that first ten minute work period, something clicks. Everyone on the team realizes they had better get started or they're not going to get finished on time! There is going to be no slippage of the schedule, no extending the deadline.
At the end of the second ten minute work period, the teams are often in a state of mild panic. The deadline is looming. Nevertheless, most members of most teams are working quickly, efficiently and collaboratively. People start moving around and re-arranging their work environment so they can manipulate the paper together. Frequently two people will work on the same page, one writing, one drawing. There is also a strong feeling of enjoyment. People are smiling, joking, and laughing.
The third and final ten minute work period is different again. The team is focused and often knows viscerally if it is going to finish with time to spare or if it is just going to squeak into the deadline. Most teams finish early and choose to take on additional items from the Work Queue, even with only a few minutes left to work. Only one single team out of all of them so far has missed delivering on its original commitment. Most teams over-achieve. And no one ever works any overtime on this project!
Agile Documentary Video
In January 2005, we were able to present the basic ideas and practices behind agile methods in a two hour session to a class of media students at Keyano College in northern Alberta. They used these ideas and practices for their class project.
The class had one group project: to create a student documentary film on some topic. The instructor, one of the authors of this article, and the class used an adaptation of Agile methods to manage the work of creating the documentary. Every two weeks, the students would do enough work to end up with some small amount of completed documentary video. They did interviews, worked with stock footage, did editing, and produced and modified a gradually expanding documentary video. At the end of any of the two week iterations, the video was "done" and could potentially have been shipped. The following is one student's reflections on the project. This student was, during the presentation to the class, acclaimed as the best person to be the Process Facilitator and took on that role.
She wrote:
The whole documentary process has been an enlightening challenge.
First there was the process to find a consensus on a direction. Possibly the first real challenge as a group. As Process Facilitator there were some great personal challenges. I am not a big fan of teamwork. I see its value but I have always worked independently and lived or died by my own efforts. There are huge issues of trust and success when you start with a group dynamic. The trust goes both ways. What if I let the group down because of my health or slower technical skills? When you work independently you can set your own schedule. Will the pressure of letting down the group be enough to motivate the individuals?
So the second big learning process for me was to be part of a team.
As Process Facilitator I needed to keep myself focused and everyone on track without being too pushy. No one has any real obligation to me or anyone else on the team so setting a manageable pace, problem solving as an individual and as a team, was another vital part of the process.
The whole concept of iterations kept things in manageable sections, that was a huge contributor to keeping a manageable goal in sight when we were all feeling overwhelmed by the load of all of our course's work. An interesting observation was that I think there were times when what we were doing in the documentary was relatively minor but the fact that we were accountable for it every day made some people feel overwhelmed. I certainly stand to be corrected but I think because we became such a good team that there was (and still is) a sense of the collective workload.
We all improved our technical skills, me particularly. I still have lots to learn but my confidence level is much higher. There is a lot of respect shown for everyone's work. We joke about things but people are mostly very respectful of the time and effort people put into their pieces of the puzzle. There doesn't seem to be a lot of ego attached individually. We are each willing to recognize each other's strengths and weaknesses without [being] rude or critical.
Overall this has been a positive process that is all about teamwork, individual strengths, and respect. Garry [the instructor], you have been terrific about leading from behind! There were many times (and still will be) when we know we have a direction but don't know how to get on the road exactly. You share your professional experience in such a way that we feel like we went searching for buried treasure and made the map ourselves.
I hope to finish the process and keep the momentum to an exciting finished product.There is a lot of respect shown for everyone's work. We joke about things but people are mostly very respectful of the time and effort people put into their pieces of the puzzle. There doesn't seem to be a lot of ego attached individually. We are each willing to recognize each other's strengths and weaknesses without [being] rude or critical.
There is a lot of respect shown for everyone's work. We joke about things but people are mostly very respectful of the time and effort people put into their pieces of the puzzle. There doesn't seem to be a lot of ego attached individually. We are each willing to recognize each other's strengths and weaknesses without [being] rude or critical.
Sharon.
The project was indeed completed successfully! Other students in the class also provided very positive feedback on the use of agile methods. In fact, this video ended up winning at the college film festival.
Agile Requirements Analysis
The previous two examples are interesting, but could be considered to be "trival" or "educational" but not "serious." One of our clients in the Telecommunications industry started using Agile methods after it had already signed a non-agile contract with one of its customers. The contract was to build a large software system to be used by emergency service organizations. The contract specified that the team would clearly define their requirements up front, in order to do an accurate estimate for the actual software development work. The second phase of the contract would consist of the actual work and would only be approved after the requirements had been established. For unknown reasons, the end customer had agreed to pay for this requirements analysis knowing that no working software would be delivered.
Nevertheless, this client wanted to see how it might apply agile concepts and practices to this first part of the contract. After exploring and rejecting the obvious idea of trying to get a team to build software right away (mostly due to funding concerns), we decided to use Agile methods to run the requirements project. In other words, the client was using this project to prepare the Work Queue (product backlog) that would be used for the actual software development project.
A small team was formed that included business experts from both the client and its customer. This team decided to work using one week iterations. At the end of each iteration it would deliver an estimated and potentially "actionable" Work Queue that, if desired, could be used by the team actually building the software. The team would do successive refinement of the items on the Work Queue and its estimates at the end of each iteration.
The first iteration delivered a very coarse-grained Work Queue with only a small number of large items. These items described broad sets of system features. Each item was also given a rough prioritization and very rough estimate of effort.
Iterations after the first simply worked to refine the items to eventually reach a level of granularity, prioritization, and confidence of estimate that was acceptable to make a commitment for the next part of the project. By using iterations, this effort was able to identify a point in time when the Work Queue was a good enough. This was decided based on the timebox and price that had been agreed to for the first part of the contract.
In this example of Agile methods applied to non-software, the Work Queue for the requirements analysis team was less formal than might normally be the case. The analysis Work Queue consisted of only a small set of goals that were worked on continuously across iterations: build the Work Queue for the software project and assign estimates to the items.
Likewise, for this Agile project, the tasks were also handled informally since it was a constant process of discussion, re-writing, and re-estimating as large requirements were broken down into small requirements.
Seven Core Agile Practices
From these and other experiences in applying agile methods outside of software development, we have observed that the following constitute a broadly applicable set of core agile practices:
Self-Organizing Team
A cross-functional team given the freedom to determine how it will do the work towards a valuable goal is one of the most effective ways to let your staff organize. The teams in the comic book exercise always learn to self-organize very quickly due to the time pressure and the lack of "management."
Deliver Frequently
Whatever the overall goal for your project, take that goal and slice it up into somewhere between five and 20 chunks that can be delivered on a regular schedule, each one of which is valuable independently and cumulatively. The Telecommunications agile requirements project delivered a new complete set of "potentially shippable" requirements at the end of every week.
Plan to Learn
The future is unknown until we get there, so in planning, make sure that you build in a learning and adaptation mechanism that allows you to adjust frequently to the inevitable changes and surprises that come along. In the documentary video project, "we went searching for buried treasure and made the map ourselves" is the result of planning to learn.
Communicate Powerfully
The best communication is face-to-face with assistive technologies such as whiteboards and flipcharts, ideally with the whole team co-located in a well-designed workspace. The comic book teams working around a table can create a real comic book in fifty working minutes and this would never be possible if the team was distributed among cubicles, let alone around the world.
Quality is Not Negotiable
Defects should be addressed immediately upon discovery and effort spent preventing defects in the first place is almost always worth it... as long as you are delivering frequently and learning along the way! In the comic book projects, teams frequently end up making mistakes and having to re-do substantial parts of their work (for example, re-doing all the lettering). By attempting to deliver a finished product at the end of the simulation exercise, defects are driven out exceptionally early.
Measure Value
People will typically produce more of what is measured... so measure what is valuable. In the video documentary project, actual completed footage (titled, edited, with a sound track or narration) was the measurable valuable result. Therefore, getting some footage done cumulatively at the end of each iteration was encouraged by its measurement.
Clear the Path
Everyone needs to be involved in removing obstacles to the work being done effectively and efficiently. In the Telecommunications agile requirements project, the whole project was about removing an obstacle for the client: believing in the estimates and the requirements for the software part of the project.
Conclusion
The three example projects applying agile methods outside of software development all demonstrate the use of the seven core practices mentioned at the start of this article. There are many other examples of people and organizations applying these practices outside of software including everything from organizational development to household management, and from small business growth to global religious community planning.
About the authors
Mishkin Berteig is the co-founder of Berteig Consulting Inc. He leads, mentors, trains and coaches teams and organizations. Mishkin helps organizations become more effective by using methods such as Agile Work, Scrum, and Lean. He believes that these methods present a good balance between chaos and bureaucracy; they allow human creativity to flourish in the service of tangible goals. Mishkin has served as a project manager, a senior consultant, a mentor, a methodology consultant, an instructor, a senior software architect and a team lead on various projects, mostly in the financial services industry, but also including education, healthcare, engineering, high-tech, oil and gas, and others. Mishkin has 15 years of professional experience. He publishes articles and thoughts about agile on Agile Advice - How and Why to Work Agile.
Garry Berteig is the founder of Berteig Art and Industry Inc. Garry helps organizations, corporations, provincial and municipal governments plan environmental developments using methods derived from Agile Work, and Scrum. Garry has found that these methods provide effective conceptual structures to help realize simple to complex projects in a beautiful manner. Garry teaches Media, Art and Design at the university level. His teaching in Canada, Denmark, Switzerland and Greenland has developed over the past twenty two-years.
Comments (1)
jvoris: ...
Your take on Agile Requirements Analysis parallels what we heard last week at our monthly meeting of Agile Philly ( http://wiki.agilephilly.com ) where Primavera is using these planning sprints for their software releases.
Articles 
These days, most people associate the word "agile" with "software development." However, people are applying the basic ideas of agile methods outside this type of work. Here are three stories of agile methods used in situations that are not in the context of software development. They illustrate how agile methods can be stretched to serve well in other contexts. From these and other examples, we have come to understand that agile methods consist of seven core practices, regardless of the problem domain: self-organizing team, deliver frequently, plan to learn, communicate powerfully, quality is not negotiable, measure value, and clear the path.
