Collaboration, Team driven Adaptation and Happiness: Single Team FAST in a Scrum Cadence under SAFe
This experience report explores how a distributed infrastructure team successfully implemented FAST (Fluid Adaptive Scaling Technology) while operating within a SAFe framework (iterating 2 weeks Scrum sprints under a 3 month PI Planning cadence). The implementation addressed common questions about FAST’s compatibility with single teams, infrastructure work, mixed workloads, and SAFe environments. Key outcomes included increased team happiness, improved collaboration, better handling of emergent work, reduced waste, and seamless integration with organizational requirements. The report provides practical insights on implementing FAST through visual online collaboration tools and demonstrates how self-organization principles can thrive within structured enterprise frameworks.
1. Introduction
When I first encountered FAST in 2018, my first thought was: “This is Science Fiction! It will never work!”
That was also the starting sentence of my XP2023 Experience Report: “Going FAST – When Scrum is slowing you down.”
Seven years later, with a highly upgraded mindset, my stance is now to “Just do it. You can NOT – NOT get it to work!” Mindsets change. Mine definitely have. Along with the world around us. When Agile practitioners declare that “Agile is dead,” I remind them of Diana Larsen’s insight, from XP2024: “Agile isn’t dead… Agile won!”. True agility means continuous evolution, not resting on past achievements.
Teams considering FAST often ask me:
- Would it work with just one team?
- How does it replace Scrum?
- Can infrastructure teams use it?
- How does it handle mixed workloads?
- Is it compatible with SAFe?
I’ve consistently answered “Yes! And it’s easy…” but I lacked firsthand implementation experience implementing FAST in the context of a single infrastructure team, working in a Scrum cadence under SAFe.
In 2024, I finally got that opportunity with a client. This experience report shares what happened when theory meets practice, answering the common questions from teams wanting evidence that FAST can work in such an environment.
And like my past experience described in my previous report: It was easy. It worked. And best of all – people were extremely happy.
2. Background
In 2024, I was brought in as an interim Scrum Master to an organization running SAFe with Scrum as the primary framework. I was tasked with introducing Agile to a team and helping them work in an Agile way. During the hiring interview, it became clear that the department manager and the person responsible for Agile implementation weren’t method dictators: “Do what works best with the team, their competencies, and the characteristics of their work.”
The team I worked with was a distributed infrastructure team (with members spread across different locations but still in the same time zone). Their primary responsibility was identity management for all users, applications, servers, and other infrastructure components. They were tasked with “keeping the lights on”, providing 3rd level support to selected experts in 2nd line support). They were supporting other teams’ change requests, along with merging three identity domains into one (in an environment labelled as a highly complex project).
3. The First challenge: Figuring Out Who We Are and How We Want to Work
As an experienced Agile Coach, my initial step working with teams is almost always to have a 1-on-1 interview with the team members, stakeholders, and other important people in the organisation. This helps me to get an idea of where I’ve landed, what is working well, and what kind of challenges we as an organisational unit are facing.
My questions for the 30 mins interview are:
In relation to your work:
- What rocks?
- What should we stop doing?
- What should we start doing?
- If you had one wish – like a genie in a lamp – what would that be?
- How good are we at delivering what we promise on a 5-step scale
0 = we deliver nothing
1 = we deliver something with no predictability
2 = it’s sustainable the way we deliver. With some predictability
3 = it’s good/agile what we deliver – and close to what we promise
4 = it’s ideal – always what we promise and perhaps a bit more
I did the same with this team, and I learned that there was some knowledge around Agile ways of working and a high enthusiasm around working together in a collaborative manner.
To get the team ready for working in an Agile way, my initial approach was to facilitate a half-day introduction workshop to Agile ways of working. My first thought was to utilize the FAST method and framework, as it had proven very strong in working with the type of emergence in work, that I discovered from the interviews. But I quickly followed with me questioning myself whether FAST was the right choice, recognizing it shouldn’t be my unilateral decision. As always, I followed Lyssa Adkins’ guidance: “Take it to the team.”
As part of the half-day workshop, I shared important elements of working Agile and 3 well known Agile models with the team:
- Scrum
- Kanban
- FAST
I explained the similarities and differences.
From a systemic perspective, I wanted to ‘reveal the system to the system itself’ by having team members share their thoughts about work characteristics, collaboration preferences, and perceived organizational limitations.
As a preparation for the workshop, I had created a board in our visual collaboration tool (Miro) with small avatars for each team member and 15 questions [link at end of document for pdf].
The first step in setting up a FAST Collective is to create a Collective Agreement. In my experience, agreeing on essential rules of engagement is a cornerstone of creating and maintaining healthy team dynamics. I do this with all teams I coach, regardless of working methods.
3.1 Key Questions and Process
First Question: When to have the check-in meeting with the team
For all the questions, I instructed team members to read the questions (one at a time), to ask for clarification if needed, and move their avatars to their preferred answers.
The first question I asked, was “When to have the check-in meeting with the team?”. Then they moved their avatars to their preferred spots. After everyone moved, my follow-up question was: “What do we as a team collectively think? What do you notice?” And by magic – and mostly me keeping silent – they self-managed around what we as a Collective were thinking, showing, and sharing as well as what to conclude. In my stance as the facilitator – helping them to clarity after the discussion was dying out – I asked: “So what is the conclusion in regard to when we will have our check-in?”
“9 o’clock!” was answered by one of the team members. “Is everyone agreeing on this – please show with a thumb up or thumb down”, I asked. Everyone showed a thumb on – either as a physically thumb up or as a digital version. “9 o’clock it is!”, I concluded.
Decision Protocols
For a group of people, it’s important to know how to make decisions and how to solve disagreements.
When deciding on the elements of a Collective Agreement – either explicitly or implicitly – these two should be considered.
Using roman voting (thumbs up or thumbs down) for the first question, introduced the team to a simple decision protocol. After the unanimous decision with thumbs up for “9 o’clock”, I briefly explained that they as a Collective now had experienced making their first decision and used their first decision protocol.
Some observations and learnings from this exercise:
- Starting with a simple and “safe” question is important as it teaches the group how to interact for subsequent questions where more is at stake. Moreover, it is a golden opportunity to introduce a simple decision protocol as well.
- This team was skilled at self-distributing speaking time. In teams where this isn’t the case, I might intervene: “Has any of the more silent voices anything to add?”
- This informs me as the facilitator to understand what to pay attention to during more heated discussions to ensure every voice is heard and valued.
Next Question: Working timeboxed or flow-based?
The team wanted an explanation of the differences between these approaches, which created a learning opportunity to share distinctions between Scrum teams and the approach seen in Kanban and FAST. After each question and avatar movement, I asked the team to reflect on the results for building collective awareness.
Protocols for solving disagreements
And not every answer was as simple and as clear as the first one.
At the first occurrence of a question, where there was some disagreement, I introduced them to protocols for solving disagreements. We decided on majority wins – with the addition of a third thumb to the roman voting protocol: Horizontal thumb, meaning: I need more information to decide.
I also introduced the Sociocracy principle ‘Good enough for now – safe enough to try’ to prevent perfectionism and encourage micro-experiments.
3.2 Team Preferences
After going through all 15 questions, it was time to decide on ways of working. Based on my 25 years of experience with different Agile methods, I considered their responses, particularly:
- We primarily want to workflow-based (“We work until work is finished and focus on how much time is remaining”)
- We prefer to synchronize every 2nd day around the work we as a team are doing.
Combined with the insights I got from the interviews, particularly that their daily work had a high degree of emergence (evolving with every minute and hour invested in solving work), I had a strong feeling that FAST would be a good choice. Although Kanban was another candidate. I also thought that FAST could better support both product discovery and product delivery compared to Kanban.
I shared my thoughts with the Collective, with voicing clearly my preference for FAST, and asked them for their thoughts, followed by a “…could it be good enough for now – and safe enough to try?”
They responded with a unanimous “Thumbs up!”. And we had as a Collective decided to work FAST.
3. Implementation – getting started with FAST
Training the team in FAST was straightforward – we just started doing it. The model is intuitive. Everyone received a copy of the rich picture explaining FAST, and we dedicated an hour for the first meetings. We moved at a slower learning pace initially, with me explaining each step as we followed the FAST rich picture.
Additional notes and learnings:
- Two team members were absent during the assessment (moving the avatars). We recorded the session for them, and I facilitated a walk-through the assessment afterward.
- At our first “Improve the system” (retrospective/reflect & adapt) session, we revisited the board and updated avatar positions based on our new knowledge and learnings.
4. The Second Challenge; Working Together Using a Visual Online Marketplace
Being a distributed team, all our collaborative artifacts and activities needed to be online: meetings, work overview, self-organization for work distribution, etc.
Notice the small numbers (e.g. ① and ) in the text and figures in this section. They have been added to to make a clear connection between what is described and what is illustrated.
4.1 Marketplace v1 – Initial Version
I created an online Marketplace ① in Miro, like those used in Open Space Unconferences. I included space for the product manager’s direction ②, a specific area for the service portal system (3rd line support) ③ and set a WIP limit of 4 for other work ④. I created small avatars for each team member to show who was volunteering as Team Steward for work ⑤. With a small team, there are often heavy dependencies on knowledge and skills. A second reason was also to create transparency for who was working on what, in the case someone needed help from a specific member of the Collective, and then knowing where to find that person.
4.2 Marketplace v2 – Agenda and Big Picture
After introducing FAST, we held our first Marketplace session with many learnings. The initial WIP limit of 4, proved to be unrealistic.
I realized that the work of an infrastructure team was very different from software development: discovering the core problem could take 40-99% of the solution time. This was emergent work to the extreme.
One of my learnings from the first Marketplace was that there was some confusion around the sequence of activities during the event. So, in the name of creating transparency for the team, towards the process, I added an agenda to the board ①. The agenda was highlighting our steps through the FAST meeting – essentially a textual version of the rich picture. I also added a “Big Picture” area ②, showing the teams their existing backlog on feature level.
4.3 Marketplace v3 – FAST meeting parts, unfished work and clearing of the Marketplace
After the first week of FAST meetings (every Tuesday and Thursday), I noticed a couple of elements that cried out for improving.
FAST meeting consists of 3 parts
Firstly, I noticed that the logical 3 parts of the FAST meeting was not clear to everyone. My solution to this was to update the agenda-section ① to reflect the logical segments of the FAST meeting with dividers between different parts.
Unfinished work
I noticed a pattern where Collective members were showing that some work on the board wasn’t touched during the Value Cycle.
In traditional Open Space, the board is cleared between each Marketplace. We hadn’t been doing that, so work that was no longer important remained visible, making people feel obligated to continue with it.
Clearing the Marketplace – actively moving all active work into the next Value Cycle
I introduced a blank board below, the existing one ②– keeping a blank space for avatars above ③. Then I guided the Collective members, after sharing progress and learnings, to move their avatars into that blank space.
This created a clear visual indicator, when no avatars were left on the top Marketplace, that part 1 of the FAST meeting was over. This was elegantly leading us to part 2 (the product manager reiterating the direction for the upcoming Value Cycle). For part 3 (populating the Marketplace), members volunteered to steward work by moving work items, where work was continuing, from the Marketplace Board at the top into the Marketplace Board below. Furthermore, they were adding their avatars to the work, indicating their role as Team Steward for the upcoming Value Cycle.
That also made – visually – clear what kind of work we had started to work on and wasn’t expected to be continued for the next Value Cycle (to be totally clear: This was the work tasks that weren’t moved to the bottom board.) Of course, this is not optimal (“stop starting and start finishing”). But having transparency into this anti-pattern is so much better than hiding it. This provided an opportunity for the Collective to self-reflect on it.
We moved those “postponed work items” to the right and created “Started Stories – not in Current Value Cycle” area④.
4.4 Marketplace v4 – self facilitation of the FAST meeting
After a couple of weeks, I noticed that I was the only one moving avatars and directing the meeting. This dependency on one specific person, is again an anti-pattern in working within a self-organising team.
To address this, I added a movable orange arrow ① to indicate our position in the FAST meeting. For the following 2-3 FAST meetings – I moved it, according to the meeting progressing. Then I asked, “Who will be moving the arrow today?” – and having the team self-select, who was screen-sharing the Marketplace and guiding the rest in regard to progress.
This volunteer also reminded people to move their own avatars away from work after sharing progress and learnings.
4.5 Marketplace v5 – finished work, and becoming better at splitting and right-sizing work
As teams began finishing work, we marked completed items with green colour and moved them to the left side of the board ①. This helped us to remember to celebrate all the progress we were making.
Becoming better at rightsizing work chunks
We also added another area next to the area for work started ②, that contained work started that wouldn’t be continued in the upcoming Value Cycles.
This highlighted important information and opened the question for “Why aren’t we finishing work we started?” The reasons we came up with included too much was going on, chunks were too large, external delays, and changing priorities.
In most cases, the best solution was to close these items and create new “stories” for remaining work. This was a big learning point for the team, also guided us in regard to become better at splitting work into smaller pieces, and creating better sized chunks of work.
Learn from mistakes not from upfront teaching
Instead of me telling them from a parenting stance, they self-discovered this learning, and made the changes needed.
I noticed a so much better effect, compared to any teaching I’ve ever done, when it comes to guiding teams in splitting work into manageable chunks.
Keeping track of work in an external system (like Azure DevOps (ADO) or Jira)
We had a governance requirement to keep all work updated in ADO. The Collective agreed that the self-organized teams, who were self-selected during the Marketplace, would keep their work reflected in ADO as part of their self-management ③.
Other Things to Share
The agenda described the 3 parts of the FAST meeting at this point. At the end of most FAST meetings, the Collective finished off, with sharing some general information, of interest to the Collective. To make the agenda complete I added this to the agenda ④. Along with a description of what the self-organising teams could focus on in self-managing their work, for the next Value Cycle.
4.6 Marketplace v6 – Improve the system
After about a month, I noticed recurring comments about things not working great. During a Marketplace, I suggested a meeting to improve the system (similar to a “reflect and adjust” meeting or a “retrospective” known from Agile).
We identified four focus areas and added a column to the Marketplace Board ① as a reminder during FAST meetings.
And in most FAST meetings – we took a look at the wish for improving the system. This reminder helped us constantly improving. It also guided us in when the next “Improve the system” get-together/meeting – was needed.
4.7 Marketplace Board – Conclusion: Start simple and evolve with emergent needs
Over the weeks and months that followed, minor changes were made to the board. Nothing worth noticing here.
Start as simple as possible – and not simpler than that
The above sections described how things happened over time. We adapted the board to the needs of what emerged. I’ve tried with later FAST Collectives to start out with the latest version. And my learning is that this is not the best way. There is some magic in the Collective guiding what their needs are, when it comes to our online board.
My main recommendation, that I suggest, is to experiment with: be inspired by the above, choose what you think is a good – and simple – starting point for your Collective (or “team” should you be working in another way than FAST). And pay attention to ways of optimizing it. And just do it!
5. The Third Challenge: Fitting FAST into the Existing Structure
As a Collective we followed the same 2-week Scrum Sprint cadence as the rest of the department.
As mentioned above, there was a governance requirement for using Azure DevOps to hold all Product Backlog Items (PBIs).
For every four Value Cycles, all lasting two weeks, we moved unfinished PBIs (User Stories in ADO) between Sprints. The self-organised teams (from the Marketplace) made sure that this happened as it was part of the Collective Agreement, that “this is what we do as a Collective to help each other”
Fluid and emergent maturing of requirements
Working in a flow system means that it is natural, that work can’t fit neatly into 2-week timeboxes.
What I noticed was that the members of the Collective started to create small just-in-time meetings for maturing current and upcoming work, inviting all interested and needed participants. Product Backlog refinement happened naturally – when facing unknowns, team members would investigate at appropriate moments.
Working with SAFe
The organization, where this FAST experiment was happening, was running SAFe in a 3-month cadence, requiring our participation in PI planning for cross-team synchronization.
My starting point in any organisation is always: Choose your battles wisely – and only when it matters.
A key learning from my part, was that working with – not against – the existing organisational structures, gave us all the peace and quiet we needed inside the FAST Collective, to create and deliver the work needed for us to succeed.
Everything in FAST, including planning, estimating, and coordinating (to mention a few), is just work. So, we just took it to the Marketplace. The product manager, as part of setting direction and re-iterating what the focus should be (FAST meeting part2), stated that becoming ready for the upcoming PI Planning, should be part of our focus. He, I, and a few others volunteered to do the work in the Value Cycles leading up to it. The starting point was to quickly figure out, what the “interface” to the SAFe governance was and what was expected from us, before, during, and after the PI Planning.
When you treat everything as work, it’s quite simple to deliver on it. If in doubt: investigate. Share the learnings and progress like any other work item. And remember it’s OK to ask specific people if they can contribute to specific pieces of work, during the Marketplace, most times they will say yes.
Looking into the future
For our 3-months forecast, we started with the Big Picture and visualized work at the feature level. Over several Value Cycles, as part of their Marketplaces, we planned activities to look forward and forecast what we could foresee would happen in the upcoming months. We arranged meetings with dependent teams to clarify details about our interconnected work.
A great learning for me, is focus on guiding the product manager and the Collective to be ready to look ahead, and planning this as you would any other work the Collective delivers.
6. Challenge Four: Elimination of Waste, Queues and frustrations
Working with and within teams for close to 4 decades, I’m constantly amazed by the amount of waste we unconsciously create through queuing work, delayed responses, unmet dependencies, and bubbling frustrations.
I’m equally amazed by how these problems nearly disappear when doing collaborative work – as is the case in running FAST. This isn’t magic – it’s people taking responsibility for work and their situation while utilizing the collective intelligence of everyone involved.
We constantly conduct micro-experiments (as Einstein said, “Nothing happens until something moves”), with both individual and shared learnings during the FAST meeting’s Collective synchronization.
Drawing from Transactional Analysis, everyone treats each other as adults. The minimal structures of FAST support this and minimize the risk of people feeling victimized.
In the above-mentioned FAST experiment, we eliminated so much un-needed work – by working with the emergence of what was most important right now. Still having the product manager help us keep the long light on, when in doubt. Many work items I heard mentioned at the start, we never spent time on. And some of the work items that by others than the team were declared as being easy and simple to do: we ended up spending 5 to 10 times more time on than their initial guess. With the fluidity in distributing the work, and everyone stepping up, helping perform the most important work at all times, we managed to deliver to the deadlines.
7. Conclusion
Summarising the above into a few of my key learnings, from implementing FAST with this infrastructure team, include:
- Emergent Work Benefits from Fluid Approaches: Traditional timeboxed frameworks often struggle with the highly emergent nature of infrastructure work. A learning on my side was that FAST’s fluid approach allowed the team to adapt to changing priorities and discoveries without the artificial constraints of sprint boundaries.
- Self-Organization Requires Minimal Structure: It was clear to me, that providing just enough minimal structures, e.g. the Marketplace and it’s Board, simple decision protocols, and visual cues for meeting progress, enabled genuine self-organization. Too much structure stifles autonomy, while too little creates confusion.
- Integration Over Isolation: Rather than positioning FAST as a replacement for existing frameworks (which it also is capable of) I learned that treating organizational requirements (like SAFe participation) as “just work” at the Marketplace, we avoided unnecessary conflict and allowed the team to focus on delivery.
- Visualization Drives Improvement: The evolution of our Marketplace board taught me that making work visible naturally exposes inefficiencies. The team self-discovered the need to right-size work items when they could visually see incomplete work accumulating.
- Trust Through Transparency: I observed that transparent visualization of both progress and challenges, built credibility faster than assertions of expertise. When stakeholders could see the continued delivery and the collective delivering what they promised, their trust in the team’s approach increased.
- Collective Learning Over Directive Teaching: Perhaps my most significant learning was seeing how the team internalized principles more deeply when they discovered them through experience rather than being taught. Their self-discovery about work sizing had more impact than any training I could have provided.
- Experimentation Over Perfection: Starting with simple structures and evolving them based on team needs proved more effective than trying to implement a “perfect” system from the beginning. This reinforced the “good enough for now, safe enough to try” principle.
The team’s continued use of FAST after my departure, with their own adaptations such as moving from Miro to Azure DevOps, confirms (at least in my mind) the sustainability of these learnings. The approach was internalized rather than imposed, allowing it to evolve with the team’s needs.
This experience demonstrates that FAST principles can thrive within more prescriptive frameworks (Like SAFe and Scrum) when implemented with attention to team context and organizational realities. The approach to introducing change matters as much as the change itself, starting with simple structures, involving collective intelligence, and allowing natural evolution through micro-experiments proved key to sustainable adoption.
I encourage you to apply these learnings to your own context, remembering that true agility comes not from rigid adherence to frameworks but from continuous adaptation based on what works for your specific team and environment. As I’ve learned repeatedly: Just do it!
8. Acknowledgements
Thanks to all the great people who participated in this experience working with the FAST method and framework.
And a special thanks to Jutta Eckstein for shepherding me with fantastic insights – I couldn’t have done it without you!
REFERENCES
- To learn more about FAST Agile – take a look The FAST Guide: https://www.fastagile.io/fast-guide
- My previous Experience Report, from XP2023: https://www.agilealliance.org/resources/experience-reports/going-fast-when-scrum-is-slowing-you-down/
- Quinton Quartel’s ER, from Agile2020: https://www.agilealliance.org/resources/experience-reports/self-organization-eats-agile-at-scale-for-breakfast/
