Unlearn

Most important value on which the decoupling mindset is based upon. In product development especially when transitioning from traditional to agile approaches, past experiences and practices are always a barrier. Unlearning is a key achievement which needs a good amount of courage and sentimental discussion in front of the mirror. In fact, we may never unlearn a practice which we were heavily relied on until now. That’s why we need to at least “pretend” to change the way of working, so we can keep calling ourselves the legend who adapts in a heartbeat. Give yourself some credit if you managed to completely unlearn a key skill to become more agile.

Focus

Stating the obvious it might seem but focus in Flux refers to the One Rule (1R). One work at a time, where the “Bubble” only work on one backlog item strictly based on priority assigned by the Product Expert.

No “I had time so I did it”, no “this is second on the list” and no promise to expedite a “business critical change” on the side. If a work is “business critical” then be agile, block the current item and make the business critical change the top priority. Avoid multitasking. This keeps the focus straight by removing any risk of interruption, even if it’s a small job. Keeping the focus in one track leaves us no choice but to get it ‘Done’ quickly as a cross functional (not necessarily cross skilled) team.

Futuristic

The more we decouple a system the more futuristic it becomes. If we don’t need an unused modular feature anymore, we shouldn’t spend much effort in removing it or create a risk for other parts of the parent system. It should be as simple as deleting a repository from your account and be extremely confident about the decision with the least side effect we can imagine. We all know it can’t be that simple (ever) but you get the picture.

Independent

Flux supports decoupling of anything which can be a potential blocker for a development team, hence advocating for independent –

Products/Systems/Features (e.g. microservices or a MVP)
Independent processes (decoupled processes like planning, reviewing or deploying to production)
Independent specialised skill based teams (1R team, Product team and Bubble)

Trust

We are talking about including DevOps in our DoD which can only be possible if we have a high level of trust and distributed decision making responsibility. Trust as we know is more focused on individuals and their ability to explore, experiment and improve their skills. e.g. This decides which 1R or Product team the individual will be a part of. It also indirectly helps the Product expert in choosing a specialised 1R team for a specific item in the backlog, hence creating an extremely productive, short and creative bubble.

Transparency

Flux promotes rotation of 1R teams, once a bubble is dissolved by the Product team. This rotation is disruptive hence enforces the act of keeping things transparent about every work the 1R team has done, while they were in the bubble. Previous 1R team is responsible for the handover to the new 1R team, in helping them get accustomed with the product area and it’s backlog for the next MVP or specific product development.

Another aspect of keeping the processes transparent is, to warn higher management and stakeholders about an extended bubble and their pain points which highlights a potential risk. This makes it easier to predict the Roadmap along with valuable decoupled feedback received during each delivery.​​