Agile methods are currently on everyone’s lips and a popular buzzword representing change and fresh wind. Until now, agile methods and especially SCRUM were mainly known from IT, particularly software development. Meanwhile, the trend is spilling over into all parts of the company. But can non-technical teams even apply agile methods? The short answer is: of course! Agile values and principles can easily be transferred to other environments. The new methods can be applied not only in teams but in entire departments. However, if a manager forces some method on his team that he just heard about, it can quickly backfire. Many are not yet familiar with the new ways of working, are skeptical or reject them outright. Therefore, one should not randomly introduce new meetings and Post-It walls just because another team is very successful with them. Agile methods should always bring added value and support the team, rather than create additional work.
Methods as Added Value
The starting point for a new method in an existing team is usually a problem, a conflict, or an obstacle that needs to be overcome. By using agile methods, the problem or conflict can be solved, thereby creating added value. The graphic shows a classic problem that many know from everyday office life. It’s always the same person who empties the dishwasher, refills the coffee beans, or brings cake. A thank you is rare, there is a lack of mutual appreciation and recognition. By introducing a KUDOS board (derived from the Greek word for fame and honor), everyone can express their gratitude and appreciation towards others. Every employee can write on the provided Post-Its who they are grateful to, be it for organizing a foosball tournament or advancing the company’s vision. Photos also fit well on the KUDOS board! As a result, satisfaction and cohesion among employees or team members increase. There is generally a higher willingness to take on smaller and larger everyday tasks.
Using agile methods to solve problems or conflicts
Clarifying expectations for agile methods
Before resorting to agile methods, one should be aware of what is actually expected from them. Only then can it be measured later whether the method really brought added value or was not suitable for the purpose after all.
It helps to be clear about the desired goal and write it down together for the team or department. Should everyone in the team be better informed about the project progress? Should the number of emails be reduced or a better overview of open and completed tasks be created? Usually, the purpose already arises from existing problems or conflicts. This also helps to make it clear to critics why something new is being tried. A clear expectation not only helps in preparing and selecting the right method. After a few weeks of application, it is much easier to understand whether the method has really fulfilled its purpose. Each team member can reflect on whether their individual expectations were met or not.
SCRUM without Programming
There are a variety of agile methods that can be used outside of technical teams. But since many are familiar with the SCRUM framework, I would like to discuss below how individual core elements of SCRUM can be used in any team, regardless of whether it develops software, rolls out new software, or is responsible for marketing measures. Those who want to refresh their knowledge of SCRUM can read a summary of the framework in this article.
Daily: A daily meeting of maximum 15 minutes, in which the project status is summarized together, allows every team member to have the same level of knowledge. It’s not necessary for everyone to be in the same room; a virtual meeting serves the purpose just as well. In the Daily, everyone can briefly present their progress, problems can be discussed together, and tasks can be quickly assigned to different team members. This can significantly reduce coordination efforts. Instead of many individual communication channels between individual people, a joint coordination can considerably accelerate the team. For example, I’ve had very positive experiences with this in a large rollout project. 15 minutes at the beginning of the workday later saved many individual phone calls, emails, and discussions.
Sprints: In SCRUM, the purpose of sprints is to divide a large block of work into smaller work packages that are processed successively. This concept can also be applied to other topics. At digatus, for example, we have an internal initiative to create standardized PowerPoint templates for recurring reports and presentations. Instead of a large project stretching over many weeks with 20 templates at the end, we have divided the work into several iterations. Rather than presenting twenty templates to the company after six months, we can present five templates every two months. The advantages are the same as in SCRUM: we deliver results continuously and can adapt our approach to circumstances at any time.
Retrospectives: A fundamental concept of agile methods is the constant reflection and optimization of one’s own way of working. Even without SCRUM, teams or departments can conduct a retrospective and analyze what’s going well and what’s not, which habits should be dropped and which the team wants to maintain. Retrospectives can be conducted in various ways, depending on what the team finds best. A good example is the KISS (Keep, Improve, Start, Stop) method. In this method, everyone first writes on post-its what behaviors they want to keep, strengthen, start or stop in the team. Then each team member sticks the post-its on a prepared surface (e.g., a flip chart or an empty wall). Afterwards, the results are discussed together and measures for implementation are determined. By the way, the initially defined expectations towards a new method can also be checked in a retrospective.
Conclusion
Many methods from software development can also be adapted to other fields. You don’t necessarily have to develop software, manage an application, or work in IT helpdesk to use agile methods. The field of agile working methods encompasses so many methods and principles that can also be used in non-technical environments. Not only project teams, but also departments (such as Marketing, HR or Sales) can rely on agile working methods. Particularly fast-paced environments where frequent changes occur can benefit from agile methods. It’s no coincidence that “Embrace Change” is a central theme of agility. It’s important to choose the method based on the problem to be solved and not to force something on the team just because it’s trendy. So it’s primarily about setting a common goal and trying to achieve it, rather than just implementing a method.
