Agile development experiences - Part 1: The Agile Manifesto and working together

Since the begin of my career in the IT industry I'm working with agile development methodologies. It was around 2013 when Scrum started to get popular in Germany and everyone, especially managers, wanted to be 'agile' (or at least their teams to be). And because germans love rules and everything needs to be structured, Scrum with its (often misunderstood) Scrum guide was THE THING introduced in development teams and even whole companies to improve their time to market. Anyway, in most of the teams I participated there was neither a significant speed gain nor real agility, but the people in those projects were unhappy and the software quality was bad.

At this time I often asked myself "Why is this happening, this works in other teams and companies too". But I didn't realise that especially Scrum works in specific environments that are most of the time not present in 'old' german companies. A great help towards identifying this problem was the work of Alistair Cockburn, the Crystal methods, a kind of scaling framework for working agile in different environments. Based on his toughts I came to the conclusion that being agile isn't hard, but it needs a step back to its roots. During the next weeks I'll share my experience about working agile without cargo culting or blindly following some pre-built framework. Please be aware that the things are a generalized view from different projects and may no work in your specific environment.

In this first post I'll talk about my opinion on the Agile Manifesto and what I recommend when it comes to individuals and interactions, also known as teamwork.

TL;DR

• Understand the Agile Manifesto and its principles. It is a solid foundation for working together.
• Talk to your teammates / stakeholders how they want to work together. What are they expecting from you and what do you expect from them?
• Improve your workflow as much as the company's rules allow it.
• Try to shadow your customers / coworkers work if it is possible. You'll learn a lot, which helps to interact better and improve the product you build.
• Meet your team in person on a regular base. You'll see that the work is going to be more efficient.
• Use only tools you really need and you're effective with, as far as company rules allow it.

The 'Agile Manifesto' as solid base

The root of modern agile methodologies is the Agile Manifesto. It was created 2001 by 17 people whom worked agile before and found some common values and principles for agile development. Most of them are known to a wide range of people in the software industry, like Martin Fowler, Robert C. Martin or the inventors of Scrum, Ken Schwaber and Jeff Sutherland. Unfortunately, the Agile Manifesto and its content, especially the twelve principles, were pushed to the background and concrete 'implementations' like Scrum were followed dogmatically.

In my experience, this dogmatism is one of the greatest problems for everyone who wants to work really agile, since the values and principles of the manifesto give a good guidance about what is important in an agile environment. Also it is a real problem that the four values are often interpreted too radical, for example interpreting "Working software over comprehensive documentation" as "You don't need documentation, the code is your documentation". But more on that in a following post.

During the next posts in this series I mapped the agile principles to the four agile values the way I understand them. In case you see things different, I'd be happy to talk about it. Anyway, before I start I want to cite my personal base principle for all following topics:

Simplicity -- the art of maximizing the amount of work not done -- is essential

"Individuals and interactions over processes and tools"

The first value, also indicated by its position, is the most important and demanding one:

Individuals and interactions over processes and tools

In contrast to old-fashioned waterfall processes, the agile manifesto focuses on the communication instead of following some lines and boxes in a diagram. Anyway, you need some kind of process and tools to get your work done, so here are my experiences how to tackle the challenges that derive from this agile value.

Setup a workflow that motivates your team

Agile development requires a lot of communication and interaction, since it shall elaborate what people really need. But before someone can even start to elaborate anything, it is absolutely necessary to get a bunch of people to think and work the same way. A lot of teams struggle because they and / or their environment aren't able to get into the 'agile thinking' because nobody helped them to do it. They were told that they're 'agile' now, probably visited some kind of 'training' and should do their work probably completely different from now on. Humans are habitual, which means that that they need time to be OK with changes like introducing a new workflow.

To get started in a new agile team, I've noticed that it helps a lot to meet in a relaxed atmosphere and just talk about the individual working experience of the parties involved, especially the business people working with you. Some of them may have worked really agile before, some of them thought they worked agile and some even haven't heard about agile development before. Maybe there are company or govermental rules to follow, too. Get to know each other and as soon as you know how each other works, what are their expectations and what is required by third parties, try to find a compromise that enables you to work efficiently and helps you to solve your upcoming challenges. It is important that everyone in the team realizes that their opinion is important, so they are motivated to work that way. For the start you can use something like Scrum or Kanban to get a solid foundation, but you need to adapt it as soon as you realize that something doesn't work out to keep the motivation on an high level. Unfortunately this is the point where a lot of companies and teams fail: they cling to their foundation workflow and use it like an old-fashioned 'process' that can't be adapted. Some companies even make Scrum or something even more 'enterprisy' to their standard process that mustn't be touched in any way. But by acting like this, you're back in old waterfall days and you won't gain any advantage of agile working because you don't prefer individuals and interactions.

Do a retrospective, but do it right!

I can't tell how often I heard "We don't do retrospectives anymore, because nothing changes after all / they are boring / ...". After I was told how the retrospectives were prepared and carried out, I wasn't surprised that the team avoids them. Often the retrospectives were just done because someone / something expected it as part of the 'process' and they were too frequent. At the start of a project, it really makes sense to talk more often about optimizations. Your team is probably new and needs to learn how to work together. But after some time, you found a way to work efficient and you're adapted to your environment as best as you can. So I recommend to lower the frequency of retrospectives after a while and let them take place spontaneous in case of urgent problems. Besides the frequency of retrospectives the structure can be a problem, too. A lot of 'Agile Coaches', or especially 'Scrum Masters', love to play 'games' in the retrospective. This looks great from the outside, but in my observations most of the people I worked with were annoyed and frustrated by this, because they just wanted to discuss real problems. So if you are a 'Agile Coach' or 'Scrum Master' please ask your team what helps them to perform a proper and effective retrospective instead of unasked playing games.

So to conclude this: Please do retrospectives, but do it in a way and frequency that supports you and your team!

Try to meet in person regularly

I'm sure this is the most controverse opinion in this post at the time of writing. Yes, I think it is really important to meet at a regular base for more than one day. You may ask "Why? I love my home office and I can talk to my teammates in Teams!". Yes, you can do it. But in my experience this leads to a weak team spirit and information sharing since the individual members are only "pictures" in your chat client and using the chat client itself is a communication hurdle. In my opinion, the agile manifesto even has a principle supporting this view:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Sure a video call is a kind of face-to-face conversation, but let's be honest: it is something different to meet in person than just talking to a screen. Communication is more than just language and being able to observe your opponents body language helps you to understand them better. Also it is easier to grab a pen at a whiteboard to quickly draw some diagramm during a discussion instead of using some web-based tool that probably can't be used by every participant.

Also, as mentioned in the first paragraph of this topic, the 'team spirit' is another really important part of working in an agile environment. To be able to interact in the best way with each other, you really need to know our team members, because this way you understand their behavior and can react accordingly. I work remote since a few years now and I really recognize that it gets hard for me to work together with others, because everyone sits at home and stares at their screen. Some of my colleagues I've even never met. During my projects with on-site presences I didn't experience this, because the whole team knew each other ways better and spontaneous discussions and brainstormings occured more often. It simplified a lot and everyone was more motivated to help the other team members to achieve the project goals.

Find different ways to gather information

The classical meeting is probably the most common way to gather information. However, important information is often not elaborated, for example, because it concerns special cases that one does not think about in the limited time available. What are ways out of this problem? My personal favorite here is to shadow the people you work for, e. g. a clerk for whom you're implementing new software. Let them show you how they work and what they need to improve their work. This is so much better than locking a bunch of people in a meeting room and think on a whiteboard about things you can just do in reality. Sure, it is really hard to shadow someone and keep concentrated the whole time, but this kind of interaction helps a lot, especially in the beginning of a project. Two other approaches I really like for knowledge crunching are Event Storming and Domain Story Telling, because they are interactive and show end-to-end flows that can be better discussed in the first place than small use-cases.

Choose the tools you need, not what advertising wants you to need

Now that I talked about the "individuals and interactions" part, I want to share some thoughts about the "tools" mentioned in the value. I must really smirk when someone talks with me about agile development and mentions a wide spread project management tool as important part of being agile. And don't forget the widely used container orchestration software that is very important to scale your small inhouse software. My opinion on this: BULLSH*T. Use only tools that really help you and integrate well in your team's development methodology. You're usually not paid for using ten tools for managing simple things like tasks where you instead could use a simple whiteboard. Personally I prefer to use as less tech as possible for doing those things, because a white board is visible in the whole room during daily business and it makes the progress directly visible to all participants.

Relevant principles

Even I wrote some of them before, I want to collect all agile principles I think they belong to this agile value below. If one orients oneself to these, it is clear easier to find a good way of working together in an agile way.

• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Summary and outlook

This post described my view on what is important when it comes to find a way of working together in an agile environment. I'm sure I forgot thousand smaller things, but those mentioned are the most helpful in my experience.

The next post will treat the agile value "Working software over comprehensive documentation", a widely misunderstood one.