FAST Process‎ > ‎


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 of an iteration.

Of course the teams are likely to hold huddles as and when needed. The teams are self-organizing so will decide if/when and how many they need. One each morning is always a good idea.

Part I - Show and Tell

Location - Forum
Facilitator - Product Director
Attendees - PM, Stakeholders, tribe
Goal - Tribe to see all "Done" stories from the last iteration

During this phase, each 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 will give critique and feedback.

On observing the completed stories and listening to the feedback from the stakeholders present, the Product Director may create follow on stories as refinements, add new features or even drop some features. The Project Map will be updated accordingly. The Product Director will declare stories as "done" at this point also - something like a sign off.

FAST in a Continuous Delivery Environment with DevOps 

A story 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 stories/features.) The story will be marked complete on the Product Map (or perhaps removed from the map).

Part II - Marketplace

Location - Forum
Facilitator - Product Director
Attendees - Stakeholders, tribe
Goal - Tribe to self-select work for the coming iteration and self-organize into teams

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

Volunteer Developers from the Development Tribe will approach the podium/stage and announce to the forum what story or problem they would like to work on in the next 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 Story Shepherd), then the PM inspects the marketplace and may ask some questions. (PM 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 PM 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 story shepherd can choose anything that is of use to the project :-
  • Story from the project map
  • Refactoring
  • Component work (instead of feature work)
  • Bug fixes (the highest priority)
  • Spikes / research

The tribe is expected and indeed 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 product team are present (tribe + Product Director + stakeholders), any public announcements are made and the enigmatic PM 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 - Team huddle, dependency management and planning

Location - Development room(s)
Facilitator - Story Shepherd
Attendees - Story Team
Goal - Identify, discuss and resolve dependencies with other teams and decide on architectural plan for the story or stories

To conclude Iteration Kickoff, the story shepherds review the iteration wall / 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 their team have arrived they go into a mini planning session and if any dependencies with other teams, have a larger meeting with the other teams to discuss strategy.

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

The goal is to come up with a development plan for the remaining time in the iteration. I'd imagine these would be tasks on sticky notes or index cards.

Part V - Get coding!

Code Craftsmanship! I am not going to mandate XP (Extreme Programming) - but I sure hope that it will be practiced.

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 you have a newer tribe member in your team, 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.

Before you say that the FAST meeting is going to be long and cumbersome, realize that phases I and II are the real "meat and potatoes" of the meeting. The following phases would typically go very quickly and are the "relish".

There are all the basic concepts? So how do you get started?