What is the right development methodology for your organization? That’s a question that the Cynefin framework can help you with. It argues that to choose the right solution to a problem, you first need to understand the nature of the problem.
Waterfall development works well where everything can be planned ahead and where future changes are expensive or impossible. Scrum will be more appropriate in less predictable and rapidly changing environments. If you need to scale, you can deploy LeSS, for example.
When is it appropriate to consider FAST Agile?
However, you may be in a situation where you need to scale your development, and at the same time, the complexity, uncertainty and speed of change is such that it exceeds the capabilities of conventional scaled frameworks. Examples of such situations include finding new, innovative products and services, developing software in environments with high levels of uncertainty or rapid change, managing large-scale change, and many more.
For these problems – increasingly common in today’s fast-paced and unpredictable world – it is appropriate to use methodologies that are suitable for such environments. One such methodology is Fluid Scaling Technology (FaST).
“FaST is ideally suited for environments or challenges that exhibit complexity, rapid change, or where innovation is needed.” – FaST Guide 2.1
Process and roles – simplicity is power
The FaST methodology is based on the Open Space Technology (OST) approach and its main element is self-organisation. The name implies that it is designed primarily for scaling, but it can work well in a single team environment.
The foundation is the Collective – a group of people who work together and self-organize around the work. There are (at least not necessarily) no other structures, such as stable long-standing teams, managers, or other roles. There is one exception – the Product Manager (PM) role, but this is understood differently from other agile methodologies and approaches. The PM is a member of the Collective and typically brings product topics such as product strategy, customer and business knowledge or product discovery to the Collective. However, he or she has no supervisory role, does not set priorities, manage the backlog, or take delivery from teams – he or she is simply an equal member of the Collective, which can include multiple PMs. There is not even a need for any hierarchy between them – as with other Collective roles, they can nominate themselves for a Team Steward role (see below) or join a team. Their work should always be fully transparent on the Marketplace board (see below).
Furthermore, there are only temporary roles in the Collective that are recruited from it. A Team Steward is anyone (e.g. technical role, PM, UX) from the Collective who decides to lead the following value cycle (see below). A Feature Steward is a voluntary role that covers the development of a particular effort of the Collective in the long term, taking care of architecture, technical quality or consistency, for example. In practice, the Feature Steward is often linked to the Team Steward, but in larger developments where people from the Collective rotate frequently, the Feature Steward is very useful.
The Value Cycle has no fixed length (it is subject to experimentation, with a recommended starting length of 2 days), and its length can vary over time (e.g., one week may have a two- or three-day cycle, while the next week may have a different cycle). In terms of delivery, the cycle is similar in principle to the Kanban methodology – it is a progression towards a goal, not a commitment to deliver something specific, so it is not an iteration in the sense of Scrum.
How the Value Cycle works
- The Value Cycle begins with a reiteration of the collective’s goals (typically a task for the PM) and then the key principle of FaST – self-organization. Some members of the collective nominate that they would like to lead the effort in the next cycle (e.g., some piece of current feature development, experiment, technical debt, product discovery, etc.) and other members of the collective prioritize by “assigning” themselves to a steward (reasons may vary – e.g., I have the most knowledge here, it makes the most sense to me relative to the customer, I want to learn something here, we need to build substitutability, etc.). Usually, the collective has it in their agreements that the minimum number of members in the Value Cycle is two (for reasons of substitutability, review, and others).
- This is followed by up to several iterations of self-organization before the collective agrees on what the content of the next cycle will be. It is desirable that there is discussion and challenging to find the best possible arrangement. But the decision is up to each member of the collective.
- This is followed by the actual work on the cycle, including autonomous synchronisation (led by the Value Cycle Steward) with other teams and stakeholders. How the team grasps the synchronisation is entirely up to them.
- The cycle ends with a short “show & tell” synchronization where the dynamically formed teams present the results of their work.
The reiteration of the objectives, self-organisation and show & tell takes place in a single meeting at the beginning of the cycle – the FaST meeting. The FaST meeting is supported by an artifact called the Marketplace board, which displays the work selected for the current cycle and who from the collective has joined it.
The boundaries of the collective are not fixed – anyone from other parts of the organization can come to a FaST meeting and present their idea. Further, it is treated just like any other – to make it happen, a steward must be found to take it on, and members of the collective must be found to join the steward.
Strengths of the methodology
The description of the process shows that the benefits of the methodology will be greater the more challenging the domain in which the collective operates. The methodology has many aspects that make it suitable for such environments:
- short cycles and the possibility to adapt their length
- flexible prioritisation and easy response to change
- dynamic working with teams, allowing them to be easily reshuffled according to circumstances
- full compatibility with product discovery or any of The Lean Startup approaches
For example, at the beginning of a project, the team may work only on product discovery (PMs or UX designers are the stewards and technical people join them) and technical design and architecture. Gradually, the workload may change smoothly towards feature development, and towards the end of development, part of the collective will start working on product discovery of the new theme again. In addition, a dynamic team may deal with e.g. the adoption of a past feature.
Due to its simplicity, the FaST methodology is very versatile and can be deployed not only in a software development environment, but also in virtually any other domain and any team. For example, I have practical experience of using it at the leadership team level of a development department, where the content of value cycles was e.g. implementation of specific changes at the development department level, support of a selected development team or response to feedback from development people in a satisfaction survey.
An interesting perspective is given by looking at FaST agile based on Lean and Lean Software Development principles. Lean in general builds on the importance of the end people in the organization and that they are the ones who should be interacting with customers, making decisions and their empowerment is critical to their motivation.
“Lean harnesses the intelligence of frontline workers and believes that they are the ones who should determine and continuously improve the way they do their jobs.” Lean Software Development
It is clear that FaST agile goes hand in hand with this viewpoint as it delegates full responsibility for priorities, process and outcome to the team members.
Prerequisites for deployment
In particular, FaST agile requires a willingness to delegate responsibility to the collective (and to shift the roles of managers to a position where their role is primarily to support the collective in their endeavors – a servant leadership approach) for effective deployment. On the other hand, it is the maturity of the members of the collective, manifested in particular by a willingness to accept this responsibility and freedom.
These aforementioned factors may represent a major barrier to the adoption of the FaST agile approach. However, it is important to realize how challenging (competition, technological change, uncertainty …) and fast-changing world we are in and whether it is not time to make
changes that will allow your organization to thrive in this century.
“Hire good people and leave them alone. When you put fences around people, you get sheep. Give people the space they need.” William L. McKnight, former CEO of 3M
Recommendations for implementing the methodology
Finally, I’ll mention a few tips that have worked well for me in implementing FaST.
- Changing a methodology tends to be a difficult change and needs to have a dedicated driver who is on the front lines with the team and stakeholders driving the change.
- Visualize the Marketplace board using a tool like Miro or Mural. This is because of the flexibility of these tools and the ease of asynchronous working. In the future, the collective may decide to replace the tool. We have verified that e.g. Atlassian JIRA works well as a FaST support.
- At least for the first few weeks – until the whole process “sits”, until the written and unwritten rules are settled and people get used to their new role in the collective – it is advisable to provide the collective with a capable facilitator.
- Pay due attention to explaining the role of the PM – not only to the people in the role and the collective, but also to all relevant stakeholders. This is very different from how other agile methodologies understand the role.
- Supporting the stewards in their work as much as possible is a useful practice, as is creating guidance on how to be best in the role.
- Ensure that the stakeholders of a given collective understand how you will operate, are aligned and speak as one.
