We partner with forward thinking enterprise organisations supporting them in transforming their ways of working to deliver better customer experiences through software.
Accelerate digital transformation by harnessing the power of DevOps & Cloud
Build cloud native software, refactoring legacy apps and lift & shift to start your journey
Become a data driven enterprise and unlock actionable insights from your data
When Agile first launched in the early 2000’s as a product management framework, it took the IT world by storm. It rose so rapidly in part because enterprises learned the value of gathering input from multiple stakeholders. Agile’s emphasis on getting input from developers and feedback from customers, along with its pragmatic approach to development, helped cement its role in the modern project management toolbox.
But like all management philosophies, with time we’ve gained the perspective to see what works and what doesn’t. A new methodology, the Flow methodology, is taking the lessons learned from Agile and putting them towards a more refined process. In this article, we’ll take a look at the philosophy behind Flow and what differentiates it from an Agile approach.
What Is Flow?
Flow enthusiasts are usually quick to note that the methodology is not a revolution from Agile, especially not in the same way that Agile was a revolution from the older Waterfall approach. Instead, Flow is a refinement on what Agile offers, placing additional emphasis on the ultimate endpoints of any IT project, delivering value to customers.
First, Flow emphasizes a particular set of values. It is a minimalist philosophy that requires that every step in the development process be oriented towards delivering value for customers. Even the name Flow underscores the overall idea: development moves in the directions of customers, and anything that impedes that overall movement towards that goal needs to be overcome.
Second, Flow is a set of tools. With its minimalist and forward-oriented approach, Flow emphasizes development approaches that respond quickly to change and aren’t entrenched in rigid, easily-siloed structures. For example, the new DevOps approach to infrastructure management where generalist DevOps Programmers and cloud tools replace overspecialized roles like Database Manager or Network Engineer.
Flow also emphasizes visualization for understanding organisational status quo (reflecting a trend in data science and analytics as well). In practical terms, that means using Kanban and visual tools instead of Scrum and verbal management. That way anyone from high-level executives to programmers can see at a glance where resources are being devoted.
Of course, given the values Flow espouses, it’s important to add that Flow has no allegiance to any particular set of tools. While an average Flow-based project may use Kanban and DevOps, you should be ready to jettison any one aspect if it doesn’t fit your organizational needs.
Flow vs. Agile
Now that we’ve laid out the overall Flow philosophy we can draw some distinctions to the Agile approach. Agile emphasizes many of the same ideas as Flow, incorporating customer preferences into the design process and emphasizing the importance of delivering working products and iteration. There are two main points of divergence.
The first is that Agile recommends a fixed set of best practices that may not fit every organization or team, and Flow has no strong allegiance to any one set of tools. The Agile playbook of short sprints, scrum masters, and feature owners may work well (and often does!) in some cases, but Flow was born out of a frustration for using these techniques when they weren’t appropriate for the context.
The Flow approach is very quick to say if some aspect of the project management process is not delivering value for customers, it can be tossed.
Which brings us to the second key divergence. As is often the case with entrenched methodologies, Agile has spawned a cottage industry of certified practitioners and training sessions, with all the accompanying binders full of guidelines and flowcharts. Flow evangelists are quick to jab that Agile has become the thing it sought to replace, the very opposite of what its name implies. While that perhaps goes too far, it is often the case that Agile institutions rely a bit too heavily on form over function.
In contrast, Flow has no certifications and no flowcharts, at least not yet. To many, this is a key selling point as it means you don’t need to pay for expensive retraining to start deploying Flow, or at least incorporating some of its ideas and seeing how they pan out. On the other hand, Agile practitioners point out that this means anyone can claim to be a Flow expert, so extra diligence is required when hiring.
Choosing a project management strategy is always a complex decision, balancing organizational needs against customer requirements. On the one hand, it’s clear that the IT industry has made leaps and bounds since the world of waterfall development. At the same time, it’s clear that there are problems with the existing Agile regime that dominates the scene today.
While there’s no silver bullet, Flow does point to some crucial flaws in Agile and makes a convincing case for how to fix them. At eSynergy, we prioritize delivering value for our customers, including in our development process. While we don’t have any certified Flow experts, we do align our development processes with our values and try to improve continually. To find out more, check out our page on development