Function vs. form: How to kill a team with an agile framework
Posted on Jan 19, 2018
The conceptual difference between function and form is surprisingly often confused and misunderstood in teamwork. The majority of team managers and agile coaches step into this pitfall without understanding the consequences.
Form is how things look like. It can be a process, a meeting or people's roles according to each other. Form defines an outlook of the team and is typically utilized to share the common understanding of how events, processes and artifacts are organized. For example: an agreed daily meeting and a fixed length sprint are typically part of the agile team’s form. Agile framework rulebooks and guides, such as the Scrum Guide, mostly represents the form.
Function on the other hand is what teams are aiming to do within the selected form. Function in the teamwork can be for example the development of software products or the production of business services. Function is made of workflows, team dynamics, experience, knowhow, tacit knowledge and much more. It can exist with or without a form, although typically a team without a well-defined form fails to drive the best-possible function. It is not defined in any generic framework or manual. Every team has its own function.
Now here’s the magic: Form follows function. It's a very famous statement made by architects since 19th century - afterwards adapted by industry managers, product designers and even yoga teachers.
Let's take a look: In yoga the function is to embrace your body’s features and allow it to stretch and strengthen by settling it into various forms: poses that are called "asanas". The body and soul are seen as one, therefore physical yoga exercises are expected to lead into mindfulness. It's the same as saying that if the team is performing more effectively, it is also capable to produce better products and services. Makes sense, doesn't it?
Agile teamwork and yoga have actually a lot in common. Both are easy to learn, but difficult to master. In both the form must follow function.
The most well-known yoga pose is the lotus asana - a cross-legged sitting position, which looks extremely simple but requires a lot of flexibility especially around the hip joints. In western culture we don’t have this type of flexibility anymore because we sit on a chair instead of squatting on the floor. Due the sedentary lifestyle overall we don’t use much our hip joints in daily life and this has shaped our bodies already for centuries.
Typically a beginner western yogi tries to get into a lotus pose by pulling the legs into a cross-legged form by force, thus using the flexibility of knees instead of hips. The problem is that you are not only feeling uncomfortable in that kind of lotus position but you are also seriously causing damage to your knees. It is surprisingly easy to reach the lotus pose by bending your knees, but every minute in that form simply gets you even further away from the aimed function. It’s dangerous because you lose the tension of your knee tendons, which in the worst case, takes you to the doctor and surgery.
Meanwhile, an experienced yoga master simply enjoys the life in the lotus pose and allows the body to fully rest and embrace the asana. He has reached both function and the form. But it’s important to understand that he didn’t get there by bending the knees and forcing the legs to be crossed in a perfect form. Instead he or she practiced or used the hip joint probably already as a child and therefore the form was nothing more than a natural consequence of the function. A perfect example of form following the function.
The same ideology should be applied to the team management. If you force your team into a specific framework through a set of instructions or guidelines, you might seriously damage the team and prevent the function to happen. Especially in agile frameworks your organization might look agile fairly easily, but functioning as an agile team is completely different thing. “Scrum is easy to learn, but difficult to master". This is written even in the Scrum guide - but still I’ve seen Scrum Masters who don’t understand what it actually means. Under the wrong kind of leadership agile becomes a curse word and the team finds its own ways to serve the "agile bureaucracy", such as artificially split sprints, where tasks are divided into phases instead of fully functional small deliverables.
In agile teams the focus should be more on transparency, inspection and adaptation instead of daily meetings, fixed length sprints and strictly defined roles. Transparency does not require a daily meeting, but a daily meeting with purposeful agenda can embrace transparency. A transformation into an agile team starts by defining your enterprise architectures, workflows, organizational behavior and especially people’s knowledge and capabilities. Only after comprehensive understanding and adaptation comes the agile form that is carefully implemented to serve the team’s current way of working. That kind of form is nothing more than a natural consequence of the agile team’s function.