The Agile philosophy is not only applicable to IT projects. It makes sense in any collaboration context, because it is just a better way of working. My recent experience of Agile with primary school teachers has shown me that the approach truly can be used everywhere and that it will quickly be of benefit to the team that uses it. 

In this post, I would like to share 3 lessons learned from a recent project management experience. Working first-hand with a newly-formed team and experimenting with different approaches, I was able to see once again the power of the Agile philosophy and its relevance in today’s work environment.

The context

In September 2016, Squla^[1] launched its educative gamified platform on the French market and I helped coordinate the production of content. Because the platform is curriculum-based, a lot of content had to be written from scratch to meet the needs of French pupils. The goal was that kids would be able to use the platform as soon as the school year started.

We had to be ready for the launch in September, so it was an intense summer to produce as much content as possible. We also knew that French parents would be particularly attentive to quality and we wanted to build solid foundations for the brand, so compromising accuracy and rigour of the content was not an option.

As a coordinator, my first task was to assemble a team of writers and experts. Squla is based in Amsterdam and the content was produced remotely, with most people living in France and some in other countries. Most of the team consisted of primary school teachers and education professionals.

For the context of this article, it is important to keep in mind the background of the team members. Imagine your typical primary school teacher: someone who loves to teach, who is passionate about the content and who is used to standing in front of a classroom full of lively children. They didn’t possess advanced technical skills, they had rarely been in a remote team and had never worked in a start-up context. Nobody had ever heard of Agile or Scrum.

Bad reflex: Regressing to top-down spreadsheets

My first impulse was to try and minimise the oddness of the project and to make it seem as “normal” as possible for them. There were already a lot of new things to take in for the teachers:

• • New form of collaboration – remote environment;
  • New tasks and responsibilities – writing content for games and quizzes, as opposed to teaching directly;
  • New team – we had a fast ramp-up before the summer;
  • New content – the platform was not yet launched in France;
  • New tools – from the internal CMS (content-management system) to collaborative tools like Google Docs;
  • New curriculum and spelling reform in France – coincidentally deployed to schools also in September (which meant that a lot of knowledge-updating was necessary).

Working on curriculum-based content was also new to me. With all this in mind, I didn’t want to add more inconvenience and impose my vision about how project management should be done.

Usually, when I work with remote teams as a game producer, I just set up a Trello board, schedule the first team meetings and everybody gets started. But on that project, I assumed it would require too much training and explanation. To avoid the risk of creating a half-agile monster, I decided to resort to a more traditional top-down approach.

I have to admit that my thought-process was also rooted in prejudice. I know that the work culture in France values more hierarchy and procedures than in the Netherlands. I had preconceived ideas about how teachers would want to work. So I decided to do it the old-school way: assigning tasks to people, controlling their progression and checking if they were performing well.

I made a spreadsheet that I was communicating to the team. It was a list of about 160 subjects to be treated, a status for the production on that subject and the various people assigned to it:

With more than a dozen people working simultaneously at the peak of production, it soon became a nightmare to maintain the “Status” column.

The flexibility of the spreadsheet was quite limited. In this aspect, the sentence that you can see in red at the top of the sheet is quite significant. It says: “Document shared for your information. Please do not modify.”

If someone meddles with the centralised system, it breaks.

I was only working part-time on this project and was busy with other things, so for me the workload soon started to become a problem. I could not produce guidelines fast enough to be able to delegate tasks. People were coming to me for every little problem. Their autonomy was very limited. Because I was the central point in all decisions, this also led to some absurd situations where teachers started asking me to validate pedagogical matters.

I simply could not keep track of everything.

In the end, this bottleneck problem is the main reason why I decided to shift for a more Agile approach. I simply couldn’t afford to spend so much time looking over everybody’s shoulder. So I silenced the prejudiced voices in my head and did what my intuition told me to do.

I created a Trello board and made a Kanban.

And a lot of wonderful things happened.

Lesson #1: Agile is a fast-forward to a high-trust culture

This is what the Kanban board looked like. Each column corresponds roughly to the “Status” column from the original spreadsheet:

With a top-down method, the boss pushes tasks to employees: “You go do this, you go do that”. In an Agile environment, the person holding the vision for the product defines tasks and orders them by priority, so that everybody can pull a task from the top of the list whenever they are finished with the previous one.

Switching from a push to a pull approach is a pivotal moment. It’s the point where you let go of control and start trusting people. The benefits of starting with trust are well known in management. As Covey put it^[2]:

“Trust is the highest form of human motivation. It brings out the very best in people.”

If you demand from people to first prove that they are trustworthy, it is never going to end. They will be constantly walking on eggshells, afraid to make a faux-pas. It is a crude control-mechanism based on fear. Starting with trust creates a much healthier dynamic. It reverts the burden of proof. Everybody is potentially a good performer and a team-player, until proven otherwise.

A pull approach requires discipline, result-driven expectations, and clear quality standards. But once the rules are made clear, it is not that hard to maintain the discipline. I was surprised how quickly the teachers took on the habit of moving the cards on the Trello board when they were done with a task. Before long, the most senior ones started inquiring about cards that were going too slow, and how they could help. Swarming comes naturally in the Agile culture.

Lesson #2: You don’t need to be tech-savvy to be Agile

Quite a few people in our remote team of teachers were not very comfortable with computers. It is not a tool that they were using often, and some of them had obviously been traumatised by previous encounters with these inflexible machines. For the most complicated procedures, we had to invest some time in training team members to improve their computer literacy.

Yet they had zero problem using Trello, which is a very simple and intuitive tool. I quickly received feedback like: “It’s so much fun to move the cards from one column to the next”. They also loved the comments functionality of the board. Not only is it easier to discuss directly on the card than by email, it is also useful for the overall production as it keeps a trace of previous discussions.

This made me realise how much of my previous decisions were based on preconceived ideas about what people could or could not do. But this realisation puzzled me, because such ideas go against my own beliefs. I strongly believe in people’s ability to learn. So were did these prejudices come from?

We shared this mental shortcut that some people were not tech-savvy enough to collaborate online.

They were actually self-imposed limitations coming from the teachers themselves, who had internalised the idea that they didn’t have sufficient computer literacy. By playing along and accepting their inadequacy, I was joining in and sustaining this narrative.

Even more importantly, we shared this mental shortcut that people who are “not good with computers” would be unable to engage in decentralised online collaboration, as if there was a permanent state of affairs where some people had missed a step and would be forever excluded from the digital age.

Surely, there had been bad experiences with computers, but a lot of them stemmed from using the tools that we had 20 or even 10 years ago. Back then, there was hardly any tutorial. The learning curve was steep.

The tools that exist now are very different. Their design is user-centric and efficient. It is the usage that we make of the tools that make them more or less difficult to handle.

There is no excuse not to use these tools. You don’t need to work in IT to be Agile, and you don’t need to have any knowledge of computer science either.

Lesson #3: Agile is a better way to treat other humans

After the switch from the push to a pull approach, my role became less and less about chasing people for information, and more and more about solving problems that were slowing down the production. This was a better use of my time, as I could focus on monitoring the status of the cards, give a hand when a subject was getting stalled, assign extra resources to urgent tasks or complex topics, and overall refine guidelines for the production of content.

A very pleasant consequence was also that the team spirit grew much stronger. People started trusting and helping each other, instead of coming to me for arbitration all the time.

But I had not realised how far the ramifications went. This became obvious only on hindsight.

After the crunch period, I did a round of feedback interviews with all the teachers. While I knew that they were overall happy with the experience, some of the comments really surprised me.

Sadly, this reflects the bad managerial culture that so many organisations are still tolerating. Schools are no exception, and the world of education is yet another example of an environment where people are passionate about what they do, but are hindered in their creativity and sometimes even mistreated.

A lot of the teachers mentioned the pride that they felt at contributing. One of them told me:

“I am so proud about the quality of the work that we are doing. I feel that for once my skills are really valued.”

I emphasise here the use of the phrase “for once”. Several teachers recounted previous experiences where they had been put down, under-challenged, undervalued.

When I hear this kind of comment I always wonder: How much untapped potential is there, in our companies, in our organisations, in our society? How many times did we limit others and ourselves, just because we were afraid of what might happen once we loosen the knot of control?

There is another comment that stayed with me:

“It’s so nice to feel trusted. It’s very different from my previous experiences. Last time I contributed to writing a book, my boss was looking over my shoulder all the time, like they were afraid I was gonna do it wrong.”

Most of us have had a similar experience, where working under scrutiny makes us feel that we are not deemed trustworthy.

Micro-management is deeply ingrained in processes that have been designed for control and compliance.

Micro-management is known issue, but it is taking a long time to die. There is a reason behind it: It is deeply ingrained in processes that have been designed for control and compliance. While this may make sense in some specific contexts (I’m thinking: junior colleagues being trained on dangerous machines), in most cases it is not justified and highly counterproductive.

My experience with the teachers has convinced me more than ever that redesigning these processes is the first step in building a healthy environment for human cooperation. It is hard work to get rid of old habits, but we have a unique chance at this point in time to bring our organisations to the next level. Why not embrace it?

—-

Notes:
1. ^ Founded in 2008 in the Netherlands, Squla is an educational platform with an original approach that offers quizzes and games based on the school curriculum. The platform is gamified with a system of rewards where kids can earn points, coins, avatars, and other elements that positively reinforce their progression. For more information, you can visit: https://www.squla.com

2. ^ Covey, S. R. (1990), The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change, Free Press

—