When Agile first launched in the early 2000s 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 emphasises 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.