What can you do when Scrum isn’t doing what it used to do? I invite you inside my story of how I guided 16 people in 2 Scrum Teams to overcome some of the Scrum limitations by replacing it with the Agile Scaling framework: FAST Agile.
I’ll share how we as a Collective were Self-organising around work in ways most Agile teams dream of, and hope you end up being inspired by how you and your current Scrum Team(s) could take a step up the Agile and Adaptive maturity ladder.
1. INTRODUCTION
“This is Science Fiction! It will never work!”. That was my first thought and reaction towards FAST Agile, back in 2018, when Ron Quartel, the creator of FAST, gave me a quick introduction.
Kind of the same reaction I got from customers, 20 years back, when trying to convince them about the benefits of working Agile.
Since my initial response, I’ve taken FAST Agile for a real test run. And it’s not Science Fiction. It works. And it works really well.
This Experience report will tell my story of learnings, reflections, and mistakes, from guiding two Scrum Teams of 16 people to work within the FAST Agile framework on a project with a tight deadline.
The situation was that the structures and elements of Scrum – that I’ve loved over the years – were becoming what was slowing us down. So, a new approach for working Agile and being adaptive needed to come into play.
Spoiler Alert: we delivered – and it worked. And I, and most people involved, would argue it was due to an even split between the great people involved and the elements of the FAST framework, supporting them.
2. Background
In 2020 I was working in a company as a Scrum Master for two teams. Our main responsibility was to move an ERP system, with a two-figure number of standalone installations, from an in-house hosted solution to one in the Cloud. With every feature and configuration being re-implemented. And educate the end users using it. When I joined, the project had been in the making for more than a year.
We’ve been running Scrum successfully for quite some time. And were quite good at it. Close to complete transparency. A more than decent predictability. Continuously reflecting and improving.
Both teams were in a Performing state (RE: Tuckman’s model). And Psychological safety was also fine.
The Product Owner had a fair amount of experience in the role and was at a place where he was doing an outstanding job. He was Not afraid of making decisions and with a preference for involving, co-creating, and deciding together with the team members.
Everyone was highly competent within their field of expertise (most with two figured years of work experience). The only exception was a small group of 3 developers that had the status of junior developers (recently moved up from trainee status). Towards helping others and being helped, everyone was somewhat open.
We definitely had clarity about what we were going to do: Get the first financial service center on the new cloud-based platform with functionality similar to the old system.
Looking at Lt. David Marquet’s model for Optimal work environment: we were at the sweet spot, balancing control and competence&clarity.
Or looking at Henrik Kniberg’s “Alignment vs. Autonomy”-grid, we were highly aligned and had a high level of distributed authority. In other words: we had the control to make the decisions towards functionality and how we were working within the Scrum framework.
3. The Problem – Why change when it’s not broken…
My story starts six weeks before our first make-or-break deadline. The first of many launches on a new platform. We hadn’t released anything yet. And hadn’t shown the Business and sponsors that the ERP system was able to deliver what was promised.
We were at a meeting, and the Teams and the Product Owner were looking at what work remained before going live. With 2-week sprints, there were three sprints until Launch. Only three sprints to deliver the remaining work and find a way to divide what was left to do between the two teams.
The frustration amongst some of the team members was growing and could be summarised as follows:
- Amount of remaining work compared to time left
Was there too little time or too much work? Or just enough of both? How to split it between the two teams and 16 people was a puzzle. Some of the team members voiced that it was tight but possible, while others almost panicked with “it cannot be done.”
- Too long iterations in combination with new things were learned on a daily basis
Some team members voiced that the current 2-week sprint was too long a planning horizon: especially because new work, unforeseen things, along with better ways of solving problems were emerging daily.
We had a high level of clarity regarding our objective(s) and purpose. But when it came to clarity on the detailed level, this was not shared by the two teams.
- The competence pool was split between two separate teams
The team members were also arguing that dividing the work between the two teams was not possible. Both teams needed the competence of everyone from their own team – and also the expertise from the other team – to succeed in delivering the remaining work.
Some were also voicing that they, for a long time, had missed pairing up to work and learn from people from the other team (FAST principle of “Mentor and Be Mentored”).
The current 2 team structure was feeling too rigid.
The situation was becoming clear to me as the Scrum Master: It was the structures and elements of Scrum – that I’ve loved over the years – that were becoming what was slowing us down. Or even hindering us from delivering on time.
So, a new approach for working Agile and Adaptive needed to come into play.
Who is telling this story?
Ups, I forgot to introduce myself. So, let’s Pause the Story for just a few seconds.
Well, I’m Per Beining. Or PerB, as I and others often refer to me. I’m 53 years old. Danish. As originating from Denmark (not being a piece of pastry ;).
I’ve been working with Agile and Adaptive Mindset and teams since 2000ish, when I first read Kent Beck’s XP book: eXtreme Programming – Explained. And tried that out as part of a small Tel-Co start-up. Working with Scrum since 2005’ish. Present days, my job title or job role as a consultant often rhymes with Scrum Master, Agile Coach, or Team Developer.
If we’ve met at a Conference, a Coach Camp, or a Training session, I’m the tall, almost bald, glass-wearing, energy-filled Dane, jumping around and probably singing a song while people are HUMM’ing along. If that doesn’t ring a bell, we probably haven’t met … yet.
4. The story
Ok, let’s return to the story. The situation was not ideal. Perhaps from a change and learning perspective.
But not from a discovery and delivery perspective (with a tight deadline).
The initial step: Deciding on FAST as a way to better do our work
Since Ron introduced me to FAST, I had tried out bits and pieces of it with the teams I was working with. And most of the experiments had been successful. Perhaps the solution to our challenge was straightforward, and we just needed to move FAST forward (pun intended 😉
I explained FAST Agile to the Product Owner. And after a few minutes of questions from him and answers from my side, he concluded: “Sounds great! I trust you! Let’s do it!”. And so we did.
First, we gave the team a 5-minute ultra-fast inflight to FAST Agile. And declared that everyone was now part of one and only one united Collective of people. And was going to work within the FAST Agile framework.
[Week 1] Saying goodbye – Step 1 – 1 hour FAST Agile Intro
Shortly after the 5-minute ultra-fast intro, we gathered the whole Team for a 1-hour FAST Agile introduction. Explaining a tiny bit more in detail about the elements and mechanics of the Framework:
- Open Space Marketplace
The way we were going to plan our 2-day iterations (called Value Cycles in FAST) was by using Open Space Technology (OST). In short, Open Space is all about gathering people in one big group. Pitch for each other – in a Market Place setup – what we think needs to happen…
- Open Allocation and Self-Management
…and then Self Organise around the work (in a way where no one is telling others what they should do). Let everyone self-manage how work is done for the 2-day Value Cycle.
- Visualise work
A Big Picture of the work that needed to happen was already in place and had been part of our ways of working for the past many months.
- Scrum vs. FAST
We also highlighted the differences between how we used to work in Scrum and how that would be different in a 2-day FAST-powered Value cycle.
[Week 1] Saying goodbye – Step 2 – Farewell Retrospective
We closed our last Scrum Sprint with a Retrospective called: “Farewell to the old ways of Working – and Hello to a new way of doing things.” In small groups, we answered the questions:
- What’s good about the new approach?
- What am I looking forward to?
- What am I concerned about?
- What do I fear a bit?
That way, everyone was aware of where we as a group were thinking (revealing the system to itself). What fears, doubts, and concerns we had? And what possibilities were lying in front of us?
[Week 1] Saying goodbye – Step 3 – Quick intro: Tips on Time (and Focus) Management
We, as individuals and as a Collective, were heading towards a different way of working. Very different timewise.
So, I decided to give the team a few of my best Ninja Trips and tricks on personal Time and Focus Management:
- Daily Highlights – tweet from this afternoon
Start the day by writing Post-It notes with the highlights of my day. One sentence or three prioritized bullet points. Written in language as if it was a postcard to myself sent from this afternoon.
- 60-90 min focus (be aware and plan the day accordingly)
Science shows that our bodies have peaks and valleys when it comes to energy. They are for each of us of a consistent but individual length. By noticing them, you can plan your work optimally and when to replenish energy.
- Rule of Stuckness – ask for help after max 1 hour
As a rule of thumb: if you are stuck for more than one hour, you need somehow to involve a friend.
- Trust your gut
Are you in doubt – trust what your gut tells you – it’s typically right.
- Evaluate continuously
Evaluate how far you have come with the task you are working on. What results did you expect to have after spending 25%, 50%, and 75% – and are the results similar to the progress? Should you reach out to other teammates and ask for help or support? Can you work smarter? Evaluate continuously!
What was already there?
I’ll pause the story once more.
Sharing this story with others, one question that always pops up is: “What are the prerequisites to start working FAST?”. I would say, “None!” But if you rephrase the question to: “What did you have in place beforehand to make the transition from Scrum to FAST easier?”, the answer is probably more useful for you as a reader, should you consider moving into working FAST.
We had the following artifacts:
- Collective Agreement (We called it a “Team Alliance / Team Agreement”)
Our rules for how we self-manage around harmony, psychological safety, and how we want to be together and treat each other. How we make decisions, resolve conflict and change the Agreement.
- Big Picture (We called it an “EPIC Backlog”)
Our “Big Picture” was showing the bigger chinks of work in a prioritized sequence.
We created The Big Picture approx six months before going FAST to help us keep an overview of the work lying ahead of us.
It also showed dependencies to other teams that were not part of our Collective and our FAST experiment (5 other teams were working on elements of the IT platform and infrastructure of the new system).
- A more detailed overview (epics broken down into stories)
Containing guesstimates on effort. Dependencies. All spread out on a calendar view – with quick best guesses towards what value cycle we expected to do the work in.
- Feature Stewards
A feature steward is a Team Member volunteering to steward a feature. Her primary responsibility is to make sure things are discovered and refined enough, ready for the actual work on the Feature.
Some weeks before going FAST, we introduced the concept of Feature Stewards (at the time, we called them EPIC Owners).
- Discovery Work in different formats (but no Discovery Trees)
FAST is offering, in addition to The Big Picture, to work with Discovery Trees to give an overview of Discovery work to help focus on having enough work ready for execution in a timely manner that does not create too much waste.
We managed to work without Discovery Trees – by having Feature Stewards.
The Feature stewards decided autonomously how they wanted to represent the discovery work. They did it in different ways, depending on the feature. The discovery work was pitched at the Marketplace, and the Collective self-organized around it. Making it happen in due time – like all other work.
[Week 1] Start Value Cycle #1 – First FAST Meeting
We kicked off our very first FAST Meeting (the only meeting in FAST) by gathering everyone in the Collective around the Big Picture and having the Product Owner briefly explain what our Vision and Objective were.
We also looked at our more detailed Storyboard. This board visually showed the smaller chunks of functionality that our EPIC was split into.
Next, someone from the Collective (Feature Stewards) pitched from the top, in prioritized order, what they were hoping to achieve within this first 2-day Value Cycle. Some were kindly asking others to join that work. The rest self-organized around what work made sense to them.
[Week 1] End Value Cycle #1 – Reflect & Improve: Different Formats and Approaches
FAST is not prescriptive on how to Reflect and Improve and recommends experimenting and discovering what works best.
We tried out a couple of different approaches, where we ended our Value Cycles with a Reflect & Improve session.
- Quick Retrospectives
In the first couple of weeks, we did a quick 15min version of our previous Scrum Retrospective:
KEEP – TRY – WISH (with dot-voting for the top2/top3 of TRYs and the WISHes)
- KEEPs – what work and should we continue doing
- TRYs – Tangible actions/experiments that we would like to try out
- WISHes – something outside our power – where we need help from someone
- Planned vs. Actuals
We also tried to start the Value Cycle by writing down on the left side of a Post-It note what you intend to get done. End the cycle by writing down on the right side of the same Post-It note what actually happened. And reflect alone and with others on how to have the two sides become closer to each other.
- 4 Week Retrospectives
After four weeks of working together within the FAST frame, we did a more traditional Retrospective. We were getting close to the deadline, and collectively we had confidence that we could deliver on time towards the upcoming deadline.
The first question on the agenda was: “Should we continue doing FAST?”
9 out of 11 voted “YES,” two were blank, and 0 for “NO.” The Collective was getting everything out of FAST that we were dreaming of. We continued with a KEEP, TRY and WISH to flesh out more details. With the addition of an extra element: “What Didn’t work that well.” That spawned a few tweaks to how we in detail, did things. One was to shift the length of our Value Cycles to 2,5 days (every week, same cadence).
[Week 6] Launch – still working within the FAST Agile frame and dealing with Bugs
A couple of weeks later, we launched on time: we had a live system with real users.
The Value cycles leading up to the launch had a few new types of activities like Training of end-user and Launch/Release activities; they all found their way to the pitches of the Market Place and were done like all other work, by people self-organizing around it.
In the days following the Launch, we did value cycles of 0,5 or 1 day – kind of a “Task-force-mode”-like setup. Focus was on stabilizing the launched system. All done in the Marketplace format we’ve grown used to.
We used a Kanban board to visualize what Work-in-Progress was and what was the next most important critical issues or bugs to focus on. We did that for a couple of days, and then the Collective decided to revert to working in 2,5-days Value Cycles.
After a couple of Value Cycles, the system was so stable that the Features for the next phase/release of the Project were introduced one by one by the Feature Stewards as capacity became available. Our ways of working quickly went back to life, as it was before the Launch.
Life continued with FAST over the next couple of months.
There were summer holidays. And I was amazed how well FAST, with our cadence of now 2,5 days Value Cycles, was serving the day-to-day urgent operational needs for the running system, along with working on the next features to be implemented, all while people were switching between being away on vacation.
After three months of Working with FAST, we had a high-level Reflect and Improved session / Retrospective, where it was a close tie between FAST and 1w Scrum. Eight voted for FAST. 7 for Scrum. None voted for KanBan or 2-week Scrum.
After four months of doing FAST, I left the team.
I’ve since heard that the new Scrum Master and the Collective decided to go back to Scrum.
I wasn’t there and didn’t have all the details, so that I won’t speculate on the reasoning behind it (in this report).
5. To sum it all up: What I learned
My experience can, on a high level, be summarised into one sentence (or just two words): “FAST works!”
And as you can read from my story, FAST solved the initial Challenges we were facing with the tight deadline, fluidly allocating team competence where needed, and finding a way through a highly complex problem.
My biggest Learning Points can be listed as
- Let the Collective Intelligence deal with Complex work
Over the years, working with various Agile methods and frameworks, I’ve been consistently impressed by what groups of people can accomplish when given the right environment, structure, and perhaps a bit of well-planned facilitation.
What I’ve seen with FAST beats that. Especially Open Space and the structure of having people self-organize around work and self-manage on how to solve work was nothing but impressive.
- Product Discovery is a natural element of FAST – use it to its full extent!
While working in an agile manner with many teams, I’ve noticed that initially, not many people seem energized by discovery work. So, I was impressed by how discovery work was naturally being taken into the marketplace and how people were doing discovery work to a level of “enough”. Ensuring that there was enough “ready” work to be done in the coming value cycle(s).
Compared to a lot of other Agile frameworks – like Scrum and Kanban – FAST is, by design, built to deal not only with Product Delivery (producing features) but also with Product Discovery. A really big differentiator with the extended focus on Product Management that I see in high-performance companies.
- Feature Stewards to drive Discovery Work / Product Discovery
Discovery work was, as mentioned, happening almost by itself. I also credit this to the accountability of the Feature Stewards. Having a member of the Collective to steward the Discovery work of value-giving Features made things so much smoother compared to my old experience of a Product Owner or a Business Analyst doing or driving the work. This is particularly true in combination with the fluid allocation of skills resulting from people self-selecting their work in the Marketplace. People were naturally volunteering to take part in the Discovery work when the Feature in question resonated with them. And notice: you can implement this concept, within any type of Agile process. Just do it!
- Using FAST to Scale
My experience of successfully scaling within Agile has been limited. Mostly because SAFe and multi-team Scrum has a lot of build limitations. Using FAST for scaling many people has made me believe in Scaling again.
We added one extra person while working FAST. And I have no doubt that if many more people should have been onboarded, that all would have been done in the same rocket-speed onboarding that happened. Let people help people. And pitch it as any other element in the Open Space.
- Rule of Stuckness – ask for help after max 1 hour
I also noticed that the rule made a big difference for everyone on elements like building and strengthening relationships, Psychological safety, and especially on eliminating waste. Members were asking for help like I’ve never seen before. And Pairwork was definitely also more common than I’ve seen previously.
Ok. It all sounds like FAST is Poster Perfect and a “silver bullet” -a solution to whatever is wrong with Scrum and all other Agile and Adaptive approaches that are out there. It probably isn’t. One thing that it is, is highly adaptive, forcing you to not just do what the guide says.
In retrospect: What was difficult? What could and would I have done differently, with my current knowledge?
- Getting Organisational buy-in
As mentioned in the introduction, we had a high degree of control in regard to what we were allowed process-wise to autonomously change. So going from Scrum to FAST was a decision made on the Team. In many organizations, that would be a centralized decision. And convincing people that have only seen or just heard of Scrum that the Open Space marketplace is a fantastic way to plan – sounds like Science Fiction. Does it sound like chaos to set people free and let them autonomously decide for themselves what to do? I’ve had that limitation in my mind. You, as the reader – what are your thoughts?
So before switching too fast – I would, with my newfound knowledge in those types of organizations, probably start by using Open Space Technology (for, e.g. department or company activities). Raising the organizational collective intelligence toward OSTs is a powerful way to help people collaborate, self-organize, and self-manage.
And on a team level, you could split the Sprints into smaller Value Cycles – and then adhere to both Organisational governances (of a specific framework) and go FAST.
- Reflect and Improve. More focus on how and when to reflect and improve
I truly believe that Reflect & Improve is a core element of any high-performing healthy team.
I was highly influenced by how we did retrospectives when running Scrum. Today, I would be more reflective about when we, as a Collective, should have a Reflect & Improve event. And would guide and inspire the Teams in ways they on a daily basis could do the same.
I would try to inspire the self-organizing Teams to use Woody Zuill’s daily habit of “Turn up the good”. It’s when the team daily reflects 5 minutes together on “what went well….and how can we do more of that tomorrow”. Simple and effective.
Having more focus on when we as a Collective need to Reflect and Improve is also one of my learnings. Not just do it by autopilot, like we did every Value Cycle or every four weeks. Use it to deliberately help (or inspire) the Collective to grow, remove waste, and deliver more value.
- Guide and help people to talk with each other – while not stealing their own learnings
The promise is that the collective members self-organize around work. Great! Fantastic! If people, though are used to working in a “Feature factory”-setup, where the Scrum Sprint Planning event is used to hand out work to individuals, it’s hard as an individual to break the antipattern of “I’m-doing-my-work”.
We experienced that the self-organized team forgot to coordinate and hadn’t had anything coherent to show. At the end of the Value Cycle. Great learning opportunity for everyone. Following this, everyone had a high focus on collaborating towards delivering finished work at the end of the Value cycles. And preparing to share their progress in a tangible way.
- Stop controlling: Trust the process – trust the people – trust yourself and have a focus on “holding the space.”
“Will this work?” was initially my biggest doubt. Today I would take a lot more laid-back stance and trust the process. I would Observe more. Listen. Think. Think a bit more. And then ask people – if it’s working or not. And then guide them into change. What I saw, most of the time, was them just doing it themselves.
As a facilitator, remember to be present, observant, and “holding the space.” Don’t jump in too soon. And don’t wait too long. The “knowing when” is the difficult part. I was reminded over this first couple of Marketplaces that people are totally capable of natural self-organization around work …
- Bottlenecks and dependencies surface faster and become clearer much earlier.
There is a big difference between working in 2 days Value and a 2-week Sprint. We quickly discovered that any undetected dependency or bottleneck was hindering us from finishing our planned work.
During one of the first Value Cycles, we had a blocking error in our build and release environment, affecting everyone. Quickly almost half of the Collective re-organized to solve it. With clear reference to the FAST Principle “Law of mobility,” those that could help were involved. Over the four months, this happened several times in more areas: People, Environments, Test Data, and Processes.
- “If you build it – they will come.”
Collective intelligence is impressive. When you give people clarity towards what direction is desired along with a clear, understandable structure to act within, they will fill the “field of dreams” and get things done. All by themselves. So, my only personal regret is that I didn’t try out with FAST as a whole sooner than I did. And happy that I used all possible opportunities to try out different elements of FAST.
So was it Scrum that was slowing us down or the way we were using the Scrum Framework? Arguments can be made for both. A lot of what I’ve described probably COULD be tweaked to work in a Scrum frame. Theoretically, everything is possible. But I don’t see it out there. Only bits and pieces in glimpses. And never to the full extent.
Will I use FAST again? Absolutely! At every possibility that I get. And should you try it out or have questions, feel free to reach out: I would love to hear about what worked for you. What was hard? And your solutions for that.
6. Acknowledgements
Thanks to all the great people that were part of this experience of working within the FAST Agile frame.
Thanks for the constructive review comments; Olivier Gourmet, Luxshan Ratnaravi, and Christian Gram.
Thank you, Mia Kolmodin, for Shepherding me with your fantastic insights: I couldn’t have done it without you!
REFERENCES
- To learn more about Scaling with FAST Agile – take a look at The FAST Guide: https://www.fastagile.io/fast-guide
- Ron Quartel’s ER, from Agile2020: https://www.agilealliance.org/resources/experience-reports/self-organization-eats-agile-at-scale-for-breakfast/
- And see my YouTube video “FAST Agile – an introduction”: [video-link]
