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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
And like my past experience described in my previous report: It was easy. It worked. And best of all – people were extremely happy.<\/p>\n\n\n\n
2.\u00a0Background<\/h2>\n\n\n\n
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.”<\/p>\n\n\n\n
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).<\/p>\n\n\n\n
3.\u00a0The First challenge: Figuring Out Who We Are and How We Want to Work<\/h2>\n\n\n\n
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\u2019ve landed, what is working well, and what kind of challenges we as an organisational unit are facing.<\/p>\n\n\n\n
My questions for the 30 mins interview are:<\/p>\n\n\n\n
In relation to your work:<\/p>\n\n\n\n
- \n
- What rocks?<\/li>\n\n\n\n
- What should we stop doing?<\/li>\n\n\n\n
- What should we start doing?<\/li>\n\n\n\n
- If you had one wish – like a genie in a lamp – what would that be?<\/li>\n\n\n\n
- How good are we at delivering what we promise on a 5-step scale<\/li>\n<\/ol>\n\n\n\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0 = we deliver nothing
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1 = we deliver something with no predictability
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2 = it’s sustainable the way we deliver. With some predictability
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 3 = it’s good\/agile what we deliver – and close to what we promise
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 4 = it’s ideal – always what we promise and perhaps a bit more<\/p>\n\n\n\nI 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.<\/p>\n\n\n\n
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.”<\/p>\n\n\n\n
As part of the half-day workshop, I shared important elements of working Agile and 3 well known Agile models with the team:<\/p>\n\n\n\n
- \n
- Scrum<\/li>\n\n\n\n
- Kanban<\/li>\n\n\n\n
- FAST<\/li>\n<\/ul>\n\n\n\n
I explained the similarities and differences.<\/p>\n\n\n\n
![\"\"](\"https:\/\/agilealliance.org\/wp-content\/uploads\/2025\/08\/fig1-ratings.jpg\")
<\/figure>\n\n\n\nFrom a systemic perspective, I wanted to \u2018reveal the system to the system itself\u2019 by having team members share their thoughts about work characteristics, collaboration preferences, and perceived organizational limitations.<\/p>\n\n\n\n
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].<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
3.1\u00a0Key Questions and Process<\/h3>\n\n\n\n
First Question: When to have the check-in meeting with the team<\/em><\/strong><\/p>\n\n\n\n
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.<\/p>\n\n\n\n
The first question I asked, was \u201cWhen to have the check-in meeting with the team?<\/em>\u201d. 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 \u2013 and mostly me keeping silent \u2013 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 \u2013 helping them to clarity after the discussion was dying out \u2013 I asked: \u201cSo what is the conclusion in regard to when we will have our check-in?\u201d<\/p>\n\n\n\n
\u201c9 o\u2019clock!\u201d was answered by one of the team members. \u201cIs everyone agreeing on this \u2013 please show with a thumb up or thumb down\u201d, I asked. Everyone showed a thumb on \u2013 either as a physically thumb up or as a digital version. \u201c9 o\u2019clock it is!\u201d, I concluded.<\/p>\n\n\n\n
Decision Protocols<\/em><\/strong><\/p>\n\n\n\n
For a group of people, it\u2019s important to know how to make decisions and how to solve disagreements.<\/p>\n\n\n\n
When deciding on the elements of a Collective Agreement \u2013 either explicitly or implicitly \u2013 these two should be considered.<\/p>\n\n\n\n
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 \u201c9 o\u2019clock\u201d, I briefly explained that they as a Collective now had experienced making their first decision and used their first decision protocol.<\/p>\n\n\n\n
Some observations and learnings from this exercise:<\/p>\n\n\n\n
- \n
- 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.<\/li>\n\n\n\n
- 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?”<\/li>\n\n\n\n
- 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.<\/li>\n<\/ul>\n\n\n\n
Next Question: Working timeboxed or flow-based?<\/em><\/strong><\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Protocols for solving disagreements<\/em><\/strong><\/p>\n\n\n\n
And not every answer was as simple and as clear as the first one.<\/p>\n\n\n\n
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 \u2013 with the addition of a third thumb to the roman voting protocol: Horizontal thumb, meaning: I need more information to decide.<\/p>\n\n\n\n
I also introduced the Sociocracy principle ‘Good enough for now \u2013 safe enough to try’ to prevent perfectionism and encourage micro-experiments.<\/p>\n\n\n\n
3.2\u00a0Team Preferences<\/h3>\n\n\n\n
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:<\/p>\n\n\n\n
- \n
- We primarily want to workflow-based (“We work until work is finished and focus on how much time is remaining”)<\/li>\n\n\n\n
- We prefer to synchronize every 2nd day around the work we as a team are doing.<\/li>\n<\/ul>\n\n\n\n
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.<\/p>\n\n\n\n
I shared my thoughts with the Collective, with voicing clearly my preference for FAST, and asked them for their thoughts, followed by a \u201c\u2026could it be good enough for now \u2013 and safe enough to try?\u201d<\/p>\n\n\n\n
They responded with a unanimous \u201cThumbs up!\u201d. And we had as a Collective decided to work FAST.<\/p>\n\n\n\n
3. Implementation \u2013 getting started with FAST<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
Additional notes and learnings:<\/p>\n\n\n\n
- \n
- 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.<\/li>\n\n\n\n
- 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.<\/li>\n<\/ul>\n\n\n\n
4.\u00a0The Second Challenge; Working Together Using a Visual Online Marketplace<\/h2>\n\n\n\n
Being a distributed team, all our collaborative artifacts and activities needed to be online: meetings, work overview, self-organization for work distribution, etc.<\/p>\n\n\n\n
Notice the small numbers (e.g. \u2460 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.<\/p>\n\n\n\n
![\"\"](\"https:\/\/agilealliance.org\/wp-content\/uploads\/2025\/08\/fig2-marketplace-board-1024x632.jpg\")
<\/figure>\n\n\n\n4.1\u00a0Marketplace v1 \u2013 Initial Version<\/h3>\n\n\n\n
I created an online Marketplace \u2460 in Miro, like those used in Open Space Unconferences. I included space for the product manager’s direction \u2461, a specific area for the service portal system (3rd line support) \u2462 and set a WIP limit of 4 for other work \u2463. I created small avatars for each team member to show who was volunteering as Team Steward for work \u2464. 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.<\/p>\n\n\n\n
4.2\u00a0Marketplace v2 \u2013 Agenda and Big Picture<\/h3>\n\n\n\n
![\"\"](\"https:\/\/agilealliance.org\/wp-content\/uploads\/2025\/08\/fig3-agenda-team-backlog-1024x479.jpg\")
<\/figure>\n\n\n\nAfter introducing FAST, we held our first Marketplace session with many learnings. The initial WIP limit of 4, proved to be unrealistic.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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 \u2460. 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 \u2461, showing the teams their existing backlog on feature level.<\/p>\n\n\n\n
4.3 Marketplace v3 \u2013 FAST meeting parts, unfished work and clearing of the Marketplace<\/h3>\n\n\n\n
After the first week of FAST meetings (every Tuesday and Thursday), I noticed a couple of elements that cried out for improving.<\/p>\n\n\n\n
FAST meeting consists of 3 parts<\/em><\/p>\n\n\n\n
![\"\"](\"https:\/\/agilealliance.org\/wp-content\/uploads\/2025\/08\/fig4-marketplace-v3-1024x748.jpg\")
<\/figure>\n\n\n\nFirstly, 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 \u2460 to reflect the logical segments of the FAST meeting with dividers between different parts.<\/p>\n\n\n\n
Unfinished work<\/em><\/p>\n\n\n\n
I noticed a pattern where Collective members were showing that some work on the board wasn’t touched during the Value Cycle.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Clearing the Marketplace \u2013 actively moving all active work into the next Value Cycle<\/em><\/p>\n\n\n\n
I introduced a blank board below, the existing one \u2461\u2013 keeping a blank space for avatars above \u2462. Then I guided the Collective members, after sharing progress and learnings, to move their avatars into that blank space.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
That also made \u2013 visually \u2013 clear what kind of work we had started to work on and wasn\u2019t expected to be continued for the next Value Cycle (to be totally clear: This was the work tasks that weren\u2019t moved to the bottom board.) Of course, this is not optimal (\u201cstop starting and start finishing\u201d). 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.<\/p>\n\n\n\n
We moved those \u201cpostponed work items\u201d to the right and created \u201cStarted Stories \u2013 not in Current Value Cycle\u201d area\u2463.<\/p>\n\n\n\n
4.4\u00a0Marketplace v4 \u2013 self facilitation of the FAST meeting<\/h3>\n\n\n\n
![\"\"](\"https:\/\/agilealliance.org\/wp-content\/uploads\/2025\/08\/fig5-self-facilitation-of-the-FAST-meeting.jpg\")
<\/figure>\n\n\n\nAfter 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.<\/p>\n\n\n\n
To address this, I added a movable orange arrow \u2460 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?” \u2013 and having the team self-select, who was screen-sharing the Marketplace and guiding the rest in regard to progress.<\/p>\n\n\n\n
This volunteer also reminded people to move their own avatars away from work after sharing progress and learnings.<\/p>\n\n\n\n
4.5\u00a0Marketplace v5 \u2013 finished work, and becoming better at splitting and right-sizing work<\/h3>\n\n\n\n
![\"\"](\"https:\/\/agilealliance.org\/wp-content\/uploads\/2025\/08\/fig6-finished-work-and-becoming-better-at-splitting-1024x651.jpg\")
<\/figure>\n\n\n\nAs teams began finishing work, we marked completed items with green colour and moved them to the left side of the board \u2460. This helped us to remember to celebrate all the progress we were making.<\/p>\n\n\n\n
Becoming better at rightsizing work chunks<\/em><\/p>\n\n\n\n
We also added another area next to the area for work started \u2461, that contained work started that wouldn’t be continued in the upcoming Value Cycles.<\/p>\n\n\n\n
This highlighted important information and opened the question for \u201cWhy aren’t we finishing work we started?\u201d The reasons we came up with included too much was going on, chunks were too large, external delays, and changing priorities.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Learn from mistakes not from upfront teaching<\/em><\/p>\n\n\n\n
Instead of me telling them from a parenting stance, they self-discovered this learning, and made the changes needed.<\/p>\n\n\n\n
I noticed a so much better effect, compared to any teaching I\u2019ve ever done, when it comes to guiding teams in splitting work into manageable chunks.<\/p>\n\n\n\n
Keeping track of work in an external system (like Azure DevOps (ADO) or Jira)<\/em><\/p>\n\n\n\n
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 \u2462.<\/p>\n\n\n\n
Other Things to Share<\/em><\/p>\n\n\n\n
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 \u2463. Along with a description of what the self-organising teams could focus on in self-managing their work, for the next Value Cycle.<\/p>\n\n\n\n
4.6\u00a0Marketplace v6 \u2013 Improve the system<\/h3>\n\n\n\n
![\"\"](\"https:\/\/agilealliance.org\/wp-content\/uploads\/2025\/08\/fig7-Improve-the-system-1024x656.jpg\")
<\/figure>\n\n\n\nAfter 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 \u201creflect and adjust\u201d meeting or a \u201cretrospective\u201d known from Agile).<\/p>\n\n\n\n
We identified four focus areas and added a column to the Marketplace Board \u2460 as a reminder during FAST meetings.<\/p>\n\n\n\n
And in most FAST meetings \u2013 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 \u201cImprove the system\u201d get-together\/meeting \u2013 was needed.<\/p>\n\n\n\n
4.7 Marketplace Board – Conclusion: Start simple and evolve with emergent needs<\/h3>\n\n\n\n
Over the weeks and months that followed, minor changes were made to the board. Nothing worth noticing here.<\/p>\n\n\n\n
Start as simple as possible \u2013 and not simpler than that<\/em><\/p>\n\n\n\n
The above sections described how things happened over time. We adapted the board to the needs of what emerged. I\u2019ve 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.<\/p>\n\n\n\n
My main recommendation, that I suggest, is to experiment with: be inspired by the above, choose what you think is a good \u2013 and simple \u2013 starting point for your Collective (or \u201cteam\u201d should you be working in another way than FAST). And pay attention to ways of optimizing it. And just do it!<\/p>\n\n\n\n
5. The Third Challenge: Fitting FAST into the Existing Structure<\/h2>\n\n\n\n
As a Collective we followed the same 2-week Scrum Sprint cadence as the rest of the department.<\/p>\n\n\n\n
As mentioned above, there was a governance requirement for using Azure DevOps to hold all Product Backlog Items (PBIs).<\/p>\n\n\n\n
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 \u201cthis is what we do as a Collective to help each other\u201d<\/p>\n\n\n\n
Fluid and emergent maturing of requirements<\/em><\/p>\n\n\n\n
Working in a flow system means that it is natural, that work can\u2019t fit neatly into 2-week timeboxes.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Working with SAFe<\/em><\/p>\n\n\n\n
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.<\/p>\n\n\n\n
My starting point in any organisation is always: Choose your battles wisely \u2013 and only when it matters.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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 \u201cinterface\u201d to the SAFe governance was and what was expected from us, before, during, and after the PI Planning.<\/p>\n\n\n\n
When you treat everything as work, it\u2019s quite simple to deliver on it. If in doubt: investigate. Share the learnings and progress like any other work item. And remember it\u2019s OK to ask specific people if they can contribute to specific pieces of work, during the Marketplace, most times they will say yes.<\/p>\n\n\n\n
Looking into the future<\/em><\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
6. Challenge Four: Elimination of Waste, Queues and frustrations<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
I’m equally amazed by how these problems nearly disappear when doing collaborative work \u2013 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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
In the above-mentioned FAST experiment, we eliminated so much un-needed work \u2013 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.<\/p>\n\n\n\n
7. Conclusion<\/h2>\n\n\n\n
Summarising the above into a few of my key learnings, from implementing FAST with this infrastructure team, include:<\/p>\n\n\n\n
- \n
- Emergent Work Benefits from Fluid Approaches<\/em><\/strong>:<\/strong> 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.<\/li>\n\n\n\n
- Self-Organization Requires Minimal Structure<\/em><\/strong>:<\/strong> It was clear to me, that providing just enough minimal structures, e.g. the Marketplace and it\u2019s Board, simple decision protocols, and visual cues for meeting progress, enabled genuine self-organization. Too much structure stifles autonomy, while too little creates confusion.<\/li>\n\n\n\n
- Integration Over Isolation:<\/em><\/strong> 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.<\/li>\n\n\n\n
- Visualization Drives Improvement:<\/em><\/strong> 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.<\/li>\n\n\n\n
- Trust Through Transparency:<\/em><\/strong> 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.<\/li>\n\n\n\n
- Collective Learning Over Directive Teaching:<\/em><\/strong> 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.<\/li>\n\n\n\n
- Experimentation Over Perfection:<\/em><\/strong> 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.<\/li>\n<\/ul>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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!<\/p>\n\n\n\n
8. Acknowledgements<\/h2>\n\n\n\n
Thanks to all the great people who participated in this experience working with the FAST method and framework.<\/p>\n\n\n\n
And a special thanks to Jutta Eckstein for shepherding me with fantastic insights – I couldn’t have done it without you!<\/p>\n\n\n\n
REFERENCES<\/p>\n\n\n\n
- \n
- To learn more about FAST Agile – take a look The FAST Guide: <\/em>https:\/\/www.fastagile.io\/fast-guide<\/a><\/li>\n\n\n\n
- My previous <\/em>Experience Report, from XP2023: <\/em>https:\/\/www.agilealliance.org\/resources\/experience-reports\/going-fast-when-scrum-is-slowing-you-down\/<\/a><\/li>\n\n\n\n
- Quinton Quartel’s ER, from Agile2020: <\/em>https:\/\/www.agilealliance.org\/resources\/experience-reports\/self-organization-eats-agile-at-scale-for-breakfast\/<\/a><\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":8033092,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","categories":[],"tags":[],"experience_report_cat":[],"content_source":[2201],"class_list":["post-8097467","aa_experience_report","type-aa_experience_report","status-publish","hentry","content_source-xp-2025"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_experience_report\/8097467","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_experience_report"}],"about":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/types\/aa_experience_report"}],"author":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/users\/8033092"}],"replies":[{"embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/comments?post=8097467"}],"version-history":[{"count":3,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_experience_report\/8097467\/revisions"}],"predecessor-version":[{"id":8097479,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/aa_experience_report\/8097467\/revisions\/8097479"}],"wp:attachment":[{"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/media?parent=8097467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/categories?post=8097467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/tags?post=8097467"},{"taxonomy":"experience_report_cat","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/experience_report_cat?post=8097467"},{"taxonomy":"content_source","embeddable":true,"href":"https:\/\/agilealliance.org\/wp-json\/wp\/v2\/content_source?post=8097467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- My previous <\/em>Experience Report, from XP2023: <\/em>https:\/\/www.agilealliance.org\/resources\/experience-reports\/going-fast-when-scrum-is-slowing-you-down\/<\/a><\/li>\n\n\n\n
- Self-Organization Requires Minimal Structure<\/em><\/strong>:<\/strong> It was clear to me, that providing just enough minimal structures, e.g. the Marketplace and it\u2019s Board, simple decision protocols, and visual cues for meeting progress, enabled genuine self-organization. Too much structure stifles autonomy, while too little creates confusion.<\/li>\n\n\n\n
- Emergent Work Benefits from Fluid Approaches<\/em><\/strong>:<\/strong> 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.<\/li>\n\n\n\n