Agile, the interaction concept

Agile, the interaction concept


These days’ often people confront me with lots of technology in the Agile world. Wherever I am, speaking on conferences, working at the client site or visiting communities, there is a lot of tech talk and perceived as the clue for working Agile.

To be honest, I value technology highly. We can only deliver high quality software solutions every 2 weeks when we automate our own work whenever we can. So tools for testing, build, integration and deployment are essential for the amount of work we deliver at the right quality. When you do this manually, team members spend too much time on work that does not contribute to business value. Plus manual work also embed the risk of errors. Which results in delivering less and less requirements. Indeed, technology facilitates Agile working in the domain of software development. My point is however, that when people don’t have the right mindset, tools don’t make you Agile.

I see people still working in silo’s from analysis to implementation using a fraction of Agile in development. I see people working in controlled environments when they are tasked, pushed and overloaded all the time. I see IT-people speaking pretending to represent the business, delivering requirements that absolutely have no value for the business. I meet so called “Agile” teams that never ever meet a client. I meet teams that only use visualisation for the plan board. And so on, and so on…

True Agile is what you are, not what you do. You have to get above the mechanical level of Agile. And the only things that creates this is: working within the values and principles of the Agile Manifesto. And I meet coaches who did not even read the Manifesto…


The main question is, what is this mindset really? How do you work accordingly to this mindset? Agile itself is not complex. As one of the Manifesto authors said, “It is all common sense, but uncommon discipline”.

Agile is very basic, the shifted paradigms in Agile are the complexity. This is a complexity because people have to accept the shifted paradigms in the way the work as team, the way they are managing teams, the way they interact and in the way they co-work with stakeholders and accept we do not know up front in detail all the requirements. The core of living and working the new paradigms is based in the Agile rituals. They bring the transparancy, feedback, professional quality, commitment, acceptance and adaptability we need. So let’s look into some of the shifted paradigms…



Paradigm Working as a team

For me in the concept itself the self-organization aspect of the team is the starting point at team level. Instead of working in silo’s, where we cross the gaps from, for example, analysis to design and from design to development with time consuming processes, multi interpretable documents (people still mix documentation with MS-Word). We need to create multi discipline teams capable to do the complete end-to-end process. When we bring this in the team we skip the time consuming processes, we skip the redundant work (maximizing the work not done) and we create a shared knowledge base in the team which makes the capable of swift response to changing situations.


In this end-to-end process all team members have to be able to do more then one task, maybe even all. This way they can step in for each other, they can create “stop starting and start finishing” and above all they decide based on the pull system what they will work on “today”. Team members are well educated professionals, have a bachelor, a master or more, so trust them to get the job done. In the interaction they can put things in place as a team during the daily. This is the moment where they converge and decide what is needed today.

Paradigm Pairing

In the team pairing is essential. When people work solo in their silo they might get stuck, don’t share enough and their knowledge gets isolated. Working in pairs, continuously talking about the work and doing it, creates shared knowledge, better insights, swifter response and faster delivery. And this is what we deliver of business value.

Paradigm Servant leadership

When you talk about teams and their interaction, the self-organization gets to another area. The area of transparency. As “manager” of whatever group(s) your role is to enable the team process. You facilitate them in their discipline kin the rituals, maybe help them to overcome impediments and of course create a platform for learning. So when performance in a team drops, don’t step in and tell them what to do. Ask them to identify what’s wrong, what has to be done about it and if they need anything from you to support that improvement. Don’t task, step back and let them do their job…

Paradigm Stakeholder involvement

The sequence is killing every process. The moment we accept a sequence, we bring in redundant work, redundant process, time, time and time…. And we don’t want to bring in more and more time. We have to deliver the requirements ASAP because we cannot and will not allow us to respond (too) late to customer and/or market demand.

The solution is easy to understand but a real tough one to make it happen, a paradigm shift. In the sequence we have people who have a say in the solution/product and they can be from any direction (security, architecture, legal, corporate communication, etc.). Too often we their involvement at the end of the sequence in their own silo. Get them out of there, bring them in to end-to-end process and create in a rhythm (heart beats) short feedback loops. All to make sure that at the end of your time box you don’t have set backs but have acceptance from all stake holders, not just the business. Getting them in a a regular basis, every heart beat 1 or 2 hours, instead of a lot of corrective work at the end of the sequence, what they are used to, is the difficult one.

Paradigm Changing requirements at all times

“But do you change requirements when you are in a sprint? “. Yes, when necessary we do. Discipline and quality in the interaction rituals are key to the Agile success. In general accepting we are not able to identify in detail all requirements up front is already a difficult one to comprehend, on the more detailed level it becomes even more complicated to people to accept.

The answer is simple, when it is really important we adapt. The mis-perception is based on the way we identify the need to adapt. Heart beats and disciplined quantification of value by all stakeholders when someone brings in a new insight, is essential. So yes interaction and yes discipline and quality. Guided by a strong facilitator to make sure the quality of the quantification debate is covered, makes sure we only adapt when the business needs it, not just when they want it.

And when something comes into the workload, most likely something has to go out. Look at a team as a bucket. When the bucket is already full with work (on the plan board visualized) you have to accept something else has to be taken out. This process of (de)selecting is easy to do but not difficult to comprehend…another paradigm…

triple constraint

All in all reading the above, it is not even complete. What it emphasizes is that discipline in the interaction has to go hand in hand with quality of the rituals. This is where the fundament lies for success. When it is there, tolling will enforce it.


Anyone in an Agile environment, especially in the vertical of an organization it is important to work based on this practice together.


The importance of the interaction in Agile. It is the fundament for Agile success. Tooling helps you to improve but when the interaction mind set is not there you will not get the benefits of working Agile.


Header Illustration : Stuart Young

Share this story: