Video Spotlight
Agile Sponsors
Upcoming and Recent WebCasts
|
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
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.
Sharon. 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.
Set as favorite
Bookmark
Email this
Hits: 8174 Comments (0)
|
| < Prev | Next > |
|---|
Agile Marketplace - Announcements and Special Offers
Webcast: Moving Build and Code Quality Upstream
This interactive panel discussion moderated by Bob Aiello, Editor-in-Chief fo the CM Journal brings industry experts Anders Wallgren, CTO of Electric Cloud and Gwyn Fisher, CTO of Klocwork together for a candid discussion of the cost savings, productivity and quality benefits that can be achieved by stabilizing builds and code quality as early in the development cycle as possible.
Register Now!
Collabnet -TeamForge 5.3
CollabNet TeamForge 5.3 includes Dynamic Planning—providing flexibility to model release scope and timeline in a single view. Now, you can easily manipulate/adjust release data.
Download Your Free Trial
Requirements-based testing (RBT) can help to ensure comprehensive test coverage, reducing the risk of failure and improving software quality. This white paper details how application lifecycle management can be used to more effectively implement RBT processes, offering greater collaboration, traceability and control.can help you increase efficiency, reduce project risk, and improve overall software quality. Learn how MKS Integrity for application lifecycle management enables RBT, delivering full lifecycle traceability to help ensure that project requirements have complete test planning and execution coverage.
Download the Requirements-Based Testing whitepaper
PureCM –SCM for Agile Teams
PureCM helps you to manage development in short iterations: keeping track of changes, supporting automated builds and preserving frequent snapshots of your projects.
Get the free trial now


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.
