Are we really Agile?
“Working agile is nothing new to us”
In early 2018 we began to facilitating an innovation project for a multinational technology company. Our job was to coach a team of engineers, marketing, and sales people to design a new interface for one of their machine solutions. In our kickoff-event, we did a quick run-through from understanding the project-brief all the way to building and testing a first mockup. We like these run-throughs as they provide quick energy release in teams that have never worked in agile sprints.
We began to introduce a selection of tools, such as user stories, that would help us transform insights from observations into formalized sentences. Later on, the team would build a series of digital mockups. During this run-through we received all too familiar feedback:
It is an interesting experience. I mean, creating user stories, writing them down on post-its and building mockups. But I feel like this is not new to us, as we have done things like this in the past, too.
I heard this feedback in several other projects as well. Especially teams in technology companies seem familiar with user stories. And prototypes. They are familiar with post-its sticking them on brown paper and whiteboards. They do not immediately figure out how our approach is any different than “business as usual.”
“Aren’t we agile already?”
There are several ways for a project coach to figure out whether or not teams actually work agile. They might say they do so but in reality they only cover up their traditional project approach with symbols of agility. One helpful way is to ask for handovers. Most teams that run traditional projects usually predefine and work towards handovers from one person or team to another. It is not uncommon to have a situation in which user researchers define user stories that are handed over to developers who then build prototypes. The ultimate goal here is to complete a number of user stories as fast and efficient as possible. These user stories are handed over without any further conversations. The handover is clean and efficient. It is anything but agile.
Agility in teamwork is not only about speed and efficiency. It is equally important to allow for effective conversations between team members and teams. The point is to find common ground between people who may have different perspectives on the same topic. In our example this would mean that developers are either involved in the overall user research activities or involved in the creation of user stories. They might not be part of the user research but they can tell whether these user stories seem coherent and meaningful to them. If only done by an individual user researcher, user stories can easily feel shallow or even confusing. Conversations are needed to carve out excellent user stories that are to the point. These conversations are relevant in many other situations, e.g. in evaluating ideas, or in interpreting feedback.
Agile teamwork triggers effective conversations
Conversations in agile teams are at times exhausting and may feel redundant but are nevertheless necessary for alignment. As Nonaka pointed out in his research about Japanese manufacturing companies, redundancy needs to be seen as a necessity rather than a burden in project management:
The fundamental principle of organizational design at the Japanese companies I have studied is redundancy — the conscious overlapping of company information, business activities, and managerial responsibilities.
Later on in our project, team members mentioned that -although they applied the very same artefacts that they have known from previous projects- the teamwork felt different now. This time, user stories were not regarded as final outcomes anymore but as triggers for a meaningful conversation betweens team members. And all team members would vividly remember until the end of the project why each user story had been written down the way it was. That, by the way, is a great indicator for an agile teamwork approach.
Based on my observations, I would argue that agile teamwork manifests itself in few but very powerful moments in which
- tools -such as user stories or mockups- are not regarded as final results but as frameworks to enforce conversations about meaning
- team members can collaborate constructively even though they bring in different perspectives into the conversation
- no one is mentioning timeboxing anymore because the conversation is too important to be cut-off.
