Return to site

FLOW: The Missing Ingredient in DevOps and Microservices

Fin Goulding and Haydn Shaughnessy

· FLOW processes

The benefits that Microservices bring to large enterprises have yet to be fully fleshed out. But one of them is profound. If we put together Microservices with migration to the Cloud there’s no reason why large companies should not be able to operate with the agility of startups. Because software architecture becomes suddenly very adaptive. a new idea can very easily be slotted into an existing service package or can, indeed, by rolled out as a separate product of business line.

To realise that opportunity IT and the Business have to communicate more. Our hope with FLOW is that we can help accelerate that dialogue. Software is your competitive advantage. Your brand might be what anchors you with customers but in an age of hyper-competition, companies need to change and pivot quickly. They need experimental environments where decisions are delegated down to people who can make the tiny or sometimes large adjustments that keep your products and services relevant and responsive to customers and allow you to capture new markets.

For those that don’t follow software debates, it’s important to at least grasp the opportunities that Microservices and continuous integration provide.

Microservices and the migration to flow

Microservices, and microapps, are terms that refer to small software packages. Their development means that we have swapped monolithic software architectures for small software packages that communicate with each other. We are no longer trying to build to a grand plan that has been architected by someone else. We are not developing software that we hand over to folks in operations.

One consequence is that a new business culture becomes possible.

Culture is one of the big blockers of change. But culture is often defined at some point in the value chain by the software platforms that place rules around what we can and cannot do or that inhibit or promote innovation.

Over the past two decades we have been trying to move away from what is usually called Waterfall development. This was a method for creating large software platforms and architectures that took a lot of planning and control and that often led to scope creep, integration conflicts, delays and overspend. Those factors made work a pretty rigid place. A lot of work would go on hold, for example, when a Sharepoint update was due for implementation. But they also defined a culture. The software was monolithic but so too were the organisations that depended on old software systems.

Agile was developed in place of this old work method. However, agile, in the end, is a faster way of doing the big plan rather than a replacement for it. In other words Agile was a faster way to develop big projects. It made it possible to contain feature and scope creep as well as to reduce overruns and overspends. But in the end it is a method designed for an old era of software.

FLOW is a replacement because in flow we hold the grand plan at bay and focus instead on very fast cycle times, very granular work breakdown, very adaptive decision making, removing friction from the work process and something else: co-creating and co-deciding the processes that get us from A to B in a project. FLOW is a philosophy for small, independent, communicative and interactive cultures, cultures that fit the bill when it comes to new software and real agility.

Flow philosophy and visualisation

Flow is a work philosophy. The backdrop is a set of techniques to improve communications and interaction at work. Most adaptation problems arise because of poor communications. Good decisions, on the other hand, can only flow from good social interaction.

Add a heading here.

As workpackages becomes smaller (this should not just apply to software) we see more tools emerging for managing granularity. One of these is the free-flowing Wall visualisations of Flow. In In Flow we break work down into those Woody Allen sized camera angles we have referred to elsewhere. We visualise these. We visualise everything in fact. Communications is supported by extreme visualisation. Everybody can see what is going on and contribute a viewpoint.

So far in this post have just talked about four new aspects to how we work in the flow:

  • Smaller workpackages to go with microservices

  • Work visualisation to create the venue for process design

  • Improved social interaction around visualisations

  • Process co-creation

But there is another aspect of this.

Flow’s unique adaptability

Flow is an end to end system set within a philosophy of extreme adaptability. It’s a philosophy for thinking on your feet, literally.

The concept of Flow can also be compared with a pipeline or assembly line, continuously pushing new code into the product base. The operational side of house will be working in teams with developers so that they know exactly what is headed towards them. They can see, like everybody else, every component of the developer organisation’s work.

This is the concept behind continuous deployment to live or indeed continuous integration at every point in the development life cycle. It is facilitated by the trend towards microservices and microapps. It lends itself to working in cross disciplinary teams and it is better for customers. It overcomes many of the problems that still exist within Agile settings.

To get it right involves visualising work pretty much as a great film maker would visualise his or her movie. That means more time is spent on imagining value-added tasks, even

though there is less of a plan.

Detailed work breakdown gives teams a strange kind of liberty. It is creative work, you know what you’re doing and why. You know what your contribution is. Better still, the CTO and her team have a valuable metric. By monitoring a cycle time of a day or so instead of 80 days, you know precisely what’s going right and what could be going wrong.

And whilst Agile is a great step forward for most businesses struggling with Waterfall methodologies, Flow demands that everything moves at pace. But Flow is not a methodology. It craves continual improvement, a focus on efficiency and is constantly evolving in order to deliver customer value.

If a method is flawed, then every project using it suffers. In Flow, during every project, the team challenges the Flow, makes adjustments, even maybe adds new steps or modifies existing steps in order to speed up the Flow. Every project can benefit from the resulting improvements rather than being forced to follow a method or process which is out of date by the time everyone is trained in it.

Best of all flow is a method for learning, interaction and communications. There’s no better definition of a culture than that. Flow

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly