The agile process (or “scrum”) is very successful in the software world, but little known outside. My team has been doing scrums at a transit agency for 3-4 years, and I get asked about it regularly. I’ve assembled a few links that are useful for explaining it without being too jargony or software-specific.
I’ll talk more about:

1. Visual Management
2. Agile Product Development
3. Scrum Process

Visual Management

The most visible component of the scrum process is the “scrum board”, which is a type of visual management. In short, it’s a visual “to do” list, showing what all members of a team are working on, and putting the team priorities and productivity up in a very visible place.
Good reading items:

1. Introduction: Visual Management for Agile Teams
2. Building a Board: Elements of Taskboard Design
3. Physical Board, Not Online: Physical Wall Boards are King for Agile, Keep it Simple including the discussion thread at the bottom

Agile Product Development

Scrum and Agile come from the software world, and are oriented toward teams that work together to deliver incremental updates to a product (e.g., monthly releases). It’s useful to look at the philosophical reasoning behind the Scrum process to understand which aspects are relevant to your own team and workplace. I find this to be a good starting point:

1. Overview: Agile Methodology from Refractions Research
2. More detail: Scrum on Wikipedia

In my own team, some of the basic tenets make sense and others do not.

• Uncertain product definition delivering incrementally and allowing client to react to an interim product and change course is helpful
• Short-term stability: allowing staff to push items off (to the backlog) and complete current work (sprint) without interruption is very valuable
• Regular and achievable goals
• Regular practice in work planning for staff: both breaking down a story into tasks, and estimating the time required to deliver a small, ~1 week deliverable

Less relevant for my team:

• Not a single product: unlike software, our team members are often working on different products for different clients
• Harder to deliver increments: our product is often a number (benefit-cost ratio, ridership estimate, etc.) rather than a software program. If I interpret agile philosophy for this product type, it would mean: deliver a rough number quickly, and then see if the customer really needs a more refined, carefully estimated number. This values speed over perfection, and loops the customer in early to let them react to a partially complete product. However, this rarely works for us in practice. Many of our clients are unable to work with this; they don’t really understand that there is not “one single answer” but that the answer is really either a “rough estimate” and a “more careful estimate”. In particular, many cannot tolerate a number that changes; they will cling to the initial rough estimate.
• Mix of in-house staff and consultants: we often work closely with consultants. We could work in an “agile” manner with them, making them effectively part of the in-house team; but at present, we usually given them individual larger tasks (~1-2 months of effort) and let them work independently from the main team. This violates some agile principles (“collaboration, not negotiation”) but meets our primary need of expanded capacity without more management overhead.

Scrum Process

I haven’t found a good reference for actually running the scrum process that’s clear and not too software-centric. At the moment, this is the source I recommend for understanding how the mechanics of scrum meetings and the roles of different participants work:

1. Reference: Scrum Reference Card [pdf]
2. Advanced Backlog Management: The Product Backlog Board

In practice, there are several normal elements of scrum that we have not yet adopted, although I’d like to get there:

• User stories: we rarely use the conventional format, “As a user, I want X so that I can do Y”
• Burndown charts: more spreadsheet-heavy than we do today
• Sprint retrospectives