The FAST Meeting

In FAST there is only one meeting. It's called - the FAST meeting. It has phases/parts to it. But it is one meeting and marks the start and end of an iteration.

Part I - Show and Tell (Close the iteration)

Location - Forum

Facilitator - Product Director

Attendees - Product Director, Stakeholders, tribe

Goal - Synchronization

During this phase, each swarm (team) that has completed work from the previous iteration will come up on the stage and show their work to the forum. The Product Director, stakeholders and anyone in the forum meeting may ask questions. The Product Director and Stakeholders may give critique and feedback.

On observing the completed work items and listening to the feedback from the stakeholders present, the Product Director may create follow on work items as refinements, add new features or even drop some features. The Release Map will be updated accordingly. The Product Director may declare work items as "done" at this point also.

The goal of this phase is really to get the tribe in synch with the current state of the system. What is the delta that your swarm added since the last FAST meeting? That is what needs sharing - in highlight and not in detail. Only give a demonstration if it will help communicate this. Try to avoid drawing this meeting out.

FAST in a Continuous Delivery Environment with DevOps

A work item might be deemed as "Deploy Ready" by the Product Director at this point. DevOps will take note of this and deploy it. (Feature flags will be in use in order for rapid deploy of selected work items.) The work item will be marked complete on the Release Map (or perhaps removed from the map).

Part II - Marketplace (Open the next iteration)

Location - Forum

Facilitator - Product Director

Attendees - Stakeholders, tribe

Goal - Tribe to self-select work for the coming iteration and self-organize into teams (swarms)

On completion of Show and Tell, we move into the marketplace phase. This term is of course borrowed from Open Space Technology (OST) from where the inspiration came from.

The Product Director will give some rousing comments and may highlight areas she feels are of higher priority. The floor is opened for swarm stewards to declare intent on what they would like to lead on.

Natural leadership kicks in and members from the Development Tribe will approach the podium/stage and announce to the forum what feature or problem they would like to steward in the upcoming iteration (typically two days) and a brief description of how they intend to achieve this (and perhaps why they are passionate about it). They put some placeholder to indicate this work (index card / post it note etc.) into a marketplace slot which is indicative of reserving one of the development rooms. (Your facilities will constrain how many of these rooms are available.)

Once all of the rooms are accounted for (or there are no more volunteers for Swarm Stweard), then the Product Director inspects the marketplace and may ask some questions. The Product Director has some veto ability but uses this as a last resort. From this, there might be a shuffling and change in market slots to more accurately reflect the priorities of the Product Director, but it is hoped that this shuffling would be an exception to the rule of the tribe choosing the right work to move the product forward in an incremental fashion.

A swarm steward will decide on something they feel is important for the product / release :-

  • Work item from the release map

  • Refactoring

  • Component work (instead of feature work)

  • Bug fixes (the highest priority)

  • Spikes / research

The tribe is trusted to do what is right for the product.

Part III - Announcements and Alignment of Vision

Location - Forum

Facilitator - Product Director

Attendees - Stakeholders, tribe

Goal - Alignment of vision and inspiration

While the entire tribe is gathered, any public announcements are made and the enigmatic Product Director should not miss this opportunity to rally the troops around the vision with words of encouragement and reiterate the vision for the product.

Part IV - Swarm huddle, dependency management and planning

Location - Development room(s)

Facilitator - Swarm Steward

Attendees - Swarm

Goal - Identify, discuss and resolve dependencies with other swarms and decide on an architectural plan for the work

To conclude Iteration Kickoff, the swarm shepherds review the marketplace in a quick huddle to identify if there are any dependencies that they need to be aware of. They then go to their respective rooms and wait to see who from the tribe has chosen to work with them that iteration. Once the swarm has arrived, they go into a mini planning session. If there are any dependencies with other swarms, it is suggested you have a larger meeting with the other swarm(s) to discuss strategy.

A myriad of outcomes might come from this phase. A swarm might decide that their work item might be better to be delayed due to complexities of dependencies and go pick up another work item. A major change in architecture might be decided and a feature story dropped by a swarm and instead works on a component or infrastructure. A major refactoring might start instead of feature work. Work items might be broken down to match a smaller swarm. (Or not. Perhaps the work will spill over instead.) A very small swarm might decide not to start, disband and the individuals join other swarms. (This is called the law of two feet or mobility in Open Space Technology.)

The goal is to come up with a development plan for the remaining time in the iteration. These would likely be tasks on sticky notes or index cards for each swarm.

Part V - Get crafting!

Code Craftsmanship! XP (Extreme Programming) is not mandated - but strongly suggested.

You can choose from mob programming, extreme programming, other - as long as you are practicing technical excellence and being a code craftsman.

In particular, if there is a newer tribe member in the swarm, you really should be pair programming with that person. It's by far the most efficient and friendly way to get someone up to speed and part of the tribe culture.

The Product Director needs to be on hand at all times to answer questions and get clarification.