Are agile methods applicable for marketing

Agile methods - structure teams and organization according to agile principles

Agile methods are tools for organizing teams and companies according to agile principles. In this article I will introduce you to the most important agile working methods and explain under which conditions the introduction of agile process models makes sense at all.

When are agile methods useful?

The application of agile working methods makes sense under two conditions. First, you believe that people are intrinsically motivated and work independently. This inevitably means that all management artifacts of reward and control are also superfluous. Second, you have to deal with complex environments and tasks. This means that you can neither finally define the requirements for the implementation of a project, nor know the exact solution. The Stacey Matrix helps you to classify the field of activity in which your project is located. If these two requirements apply to your project or the environment of your organization, it is appropriate or even necessary to introduce agile models.

What you can expect from agile methods

If you cannot conclusively describe the requirements or the solution, then trying out and learning is the only valid approach. This assumes that you work with assumptions, try out solutions with and on the customer and adapt your approach again and again. This is the only way you can understand complex tasks, identify related requirements, solutions and suitable strategies. Agile methods give this iterative approach a structure. To do this, you put autonomy and decisions in the hands of implementing teams, and establish communication rituals and rules for maximum synchronization and transparency. At the same time, you make sure that work is organized end-to-end along value streams, instead of in functional silos like on the assembly line 100 years ago. This enables teams and organizations to be successful in dynamic and complex environments.

Agile methods overview - You cannot ignore these models

In the following overview of agile working methods you will find the most important agile models. In principle, you can differentiate between two types of agile process models. On the one hand agile methods with which you structure the cooperation of teams. In addition, there are agile models that you can use to organize collaboration in a company. To get a first overview, briefly introduce the agile methods in the overview and then go into a little more detail.

methodcontextSense / purpose
ScrumteamIntroduction of new products and services, development of technical platforms, agile project method.
LeSSorganizationOne of several “Scrum of Scrums”, but my favorite framework for more than two Scrum teams.
Nexusteam“Scrum of Scrums” approach from Scrum.org for two to nine teams, Nexus + for more than nine teams.
Design sprintteamWeekly workshop format for teams based on Design Thinking.
Lean startupteamIterative cycle for developing new services and products with the involvement of the customer
KanbanTeam, organizationOrganization of upcoming work according to the “pull principle” in order to manage the “flow” and the work flow in a self-organized manner.
OKRTeams, organizationFramework to align teams and organizations to common goals and to synchronize short, medium and long term goals.
Spotify modelorganizationBuilding an organization based on the model of the Spotify organization.
SafeIT and software organizationOrganizational model for the development of “Large Scale Software Solutions”
SociocracyorganizationOrganizational model for companies based on sociocratic principles.
HolacracyorganizationCommercial variant of sociocracy.

Scrum - Agile method for teams

Scrum is certainly the best-known agile method and is now used far beyond the limits of software development. The Scrum Team (max. 10 people) works in short iterations of 1 to 4 weeks (sprints) on the completion of specific work results. At the end of the sprint, work results are presented in order to get feedback from stakeholders and users. While the Product Owner prioritizes the upcoming tasks, the Scrum Master coaches the team in the implementation of the Scrum process. The developers work independently on the implementation of the prioritized tasks. Every Scrum Sprint begins with a planning and ends with a review and retrospective. This makes Scrum a suitable agile process model for the development of new products and services and an agile project method.

LeSS - Scrum of Scrums

The LeSS Framework describes rules for the cooperation of several Scrum Teams. My favorite “Scrum of Scrums” framework is LeSS (Large Scale Scrum). At its core, the agile process model LeSS is based on Scrum, expands the Scrum roles and meetings and also defines important rules so that the scaling of Scrum is successful. The special thing about this agile method is its systemic approach, the reduction to the essentials (“descaling”) and the belief that you should give the implementing teams as much autonomy as possible. While LeSS is for 2-8 teams, LeSS Huge is for more than 8 teams. In my understanding, structures and LeSS can also be used meaningfully far beyond software development and are therefore also an agile model for organizations.

Nexus - “Scrum of Scrums” powered by scrum.org

Nexus is a “Scrum of Scrums” framework for three to nine teams. The agile process model was designed by Scrum founder Ken Schwaber and published on scrum.org in 2015. At its core, Nexus is based on Scrum roles, events and artifacts. That means a PO, 1-4 Scrum Master, a review and a common increment. All meetings except for the review are double, which means that they take place on both a team and a nexus organizational level. In addition, a Nexus Integration Team (NIT) is set up, which consists of the PO, a Scrum Master and specialists from the development teams. The NIT has the task of enabling a smooth technical integration of the work results. To this end, the NIT advises and enables the respective development teams to integrate their work results. If the organization consists of more than nine teams, additional rules apply with Nexus +. In the Nexus Guide and on scrum.org you will find case studies and a detailed description of the agile method.

Design Sprint - One team, five days

The design sprint should not be missing from the overview of agile methods. Even if the Design Sprint is, strictly speaking, more of a workshop format than an agile method in the narrower sense, many companies rely on this format to work on important questions for product or further company development in a concentrated manner. The Design Sprint lasts five days and ends after one iteration. During these five days, one or more teams go through the design thinking process in a structured manner and finally present their work results. The Design Sprint is therefore particularly suitable as an agile process model for the exploration of new types of projects or services.

Lean startup - developing products and business models iteratively

Similar to a Design Sprint, Lean Startup is an agile process model that is used in the very early phases of product and service development. The three-stage "build-measure-learn" process forms the center of this agile model. To do this, you translate your ideas into minimally functional products (MVP's) (build), which you then test with the customer (measure). This allows you to verify important hypotheses and identify the most important value drivers of a product (learn). Because only when you confront customers with tangible prototypes and ideas are they able to give valuable feedback. Lean Startup does not follow a fixed and continuous process such as the Scrum Framework. Instead, you are pursuing the goal of minimizing the lead time through the "build-measure-learn" cycle as part of this agile process model. So your most important KPI is how many MVPs or experiments you have completed in a short time.

Kanban - the invisible hand of teamwork

Kanban is the most underrated agile method. Because Kanban can be used in many contexts, regardless of the number of people involved and applicable to every work and value creation process. You can use Kanban as an agile project method, as an instrument to organize operational work or even project portfolios at company level. To work with Kanban, you first structure your work process. Then every step in the value chain gets its own “swim lane” in your Kanban board. Afterwards, every task or project is processed by the Kanban board according to the pull principle. Instead of assigning or pushing work, Kanban, as an agile process model, relies on teams and employees pulling or pulling pending tasks. The current work status is visible at any time via the Kanban board. You can use it to visually capture bottlenecks and see the “flow” of the work. You can use Kanban in addition to other agile models such as Scrum.

Objectives & Key Results (OKR)

The agile method Objectives & Key Results (OKR) is essentially a syntax for talking about goals. Every OKR consists of a qualitative goal (objective) and quantitative metrics (key results). You evaluate the achievement of your qualitative goals using key results. Second, OKR are a target system that you use to synchronize long and short term goals across the entire organization. And thirdly, with OKR, you establish an agile process model supported by the self-commitment of the teams and continuous learning. Teams go in iterations of 3-6 months to work on the achievement of goals or OKR that they have set themselves. This work in short iterations, the synchronization with the goals of the company and also the easy entry make OKR one of the most popular agile methods in recent years.

Spotify Model - Agile Method from Sweden

The Spotify model, named after the Swedish music service, is an agile process model for the organization of entire companies or areas. At its core, the agile model is based on small, autonomous teams or squads, which in turn are part of a tribe. A technical and functional organization is also carried out via chapters. This means that while employees do their daily work in a squad, they find a professional home through their chapter (e.g. all marketing employees). In this agile process model, squads have end-to-end responsibility for creating a service or a performance feature. The Spotify model thus resolves the organizational tension between an end-to-end and a technical, functional perspective. In addition, the agile method relies on voluntary communities in which the exchange of employees on topics of their choice is in the foreground.

SAFe - Scaled Agile Framework

The Scaled Agile Framework (SAFe) offers an answer to the question of how you can scale agile methods for working on large software solutions and several hundred people. Unlike LeSS, SAFe has a very clear focus on IT and software organizations. To this end, SAFe in version 5.1 (February 2021) relies on seven core principles and supplements them with a series of roles, tasks, practices and work processes.

As you can already see from the structure of the agile model, SAFe is very extensive. In my understanding and in comparison to e.g. LeSS, SAFe is overregulated and too complicated. Due to the complexity and effort associated with the introduction, SAFe is really only of interest to large IT organizations and, above all, consultations that then accompany the implementation.

Sociocracy - leadership based on democratic participation

Sociocracy is an agile process model for the development of an organization based on the idea of ​​democratic participation. The agile method is based on four basic principles:

  1. Decision-making by consensus
  2. Development of the organization in semi-autonomous circles
  3. Double linking of the circles.
  4. Open options for the essential functions and roles

Instead of “departments”, sociocratic companies are organized in semi-autonomous circles. Each circle has its own goal and associated area of ​​responsibility. Within this domain, the circle makes autonomous decisions. Resolutions within the circle are never made by individuals, but always by consensus. Consent is a very structured and transparent decision-making process that you can use independently of sociocracy. In addition, each circle has a double link with circles above (uplink and downlink). As an agile model, sociocracy is mainly used in clubs, schools or nonprofits, and occasionally in commercial companies. Nonetheless, sociocracy is an important milestone and inspiration for how agile process models can be consistently established for entire companies.

Holacracy - Sociocracy in "commercial"

The holacracy as an operating system for agile organizations should not be missing from the overview of agile methods. Every holacratic organization has a constitution in which the essential guidelines, the structure and the processes for the management and administration of the organization are documented (German version). Work in the Holacracy is defined using “roles” instead of job descriptions. So every employee can have several roles. Associated roles form a circle, the circles are connected by double connections, just like in sociocracy. Another feature is a strict separation of operational and strategic meetings. While everyday life is in the foreground in operational meetings (tactical meetings), the structure of the circle is further developed in strategic meetings (governance meetings). The last important characteristic of the holacracy is the dynamic control and further development. As an agile process model, the holacracy submits itself to an agile process, shaped by the desire for constant improvement and organizational perfection.

Before you get started with agile methods

Before you start implementing agile methods and process models, you can critically question a few points for yourself and your organization:

1. Current values, beliefs and leadership models

Do you agree that people like to work voluntarily? Because if you are not ready to give up corporate rituals based on punishment and control, sooner or later you will experience difficulties with the successful application of agile process models.

2. Which problem do you want to solve?

What do you promise yourself from the use of agile models? What problem do you want to solve? In my understanding, agile methods should be the solution to a problem and not an end in themselves. So create transparency about problems and challenges in the current organization and evaluate the introduction of agile methods based on an improvement in these problem areas.

3. Understand customers, customer journeys and “demand”

Before using agile methods, you should first understand the nature of the work. Because not every agile model fits every job. For example, if you cannot plan your tasks autonomously, but work to be done is brought to you from outside (e.g. service), Scrum may not be the right agile process model. That means, look at the context in which agile methods should be implemented at all. Can the work be planned autonomously or are external requirements brought to you? What does your added value, your strategy and your business model look like? Only on the basis of this understanding can you make a meaningful statement about which agile methods make sense for you / your team.

4. "Trust the process"

If you have made a decision for an agile process model, you trust the associated process. Because essentially all agile methods are based on the idea of ​​continuous improvement (Kaizen). These improvements are an incremental part of agile process models. This means that you continuously reflect on the progress made in terms of content and the quality of the cooperation. Stay true to this process and trust that it will keep getting better. Because what is not good is not over yet.

Conclusion - agile methods provide security but are not an end in themselves

Agile methods are an indispensable stylistic device to be successful in digital and dynamic markets. Agile models are characterized by a high level of process loyalty, clear structures and communication rituals. The cooperation is based on agile values ​​such as voluntariness, self-commitment and the willingness to take responsibility.

However, agile methods are never an end in themselves. Before you rush to introduce agile methods, you should always ask yourself “what” you want to use the method for and what you want to achieve with it.If you are clear about this, the type of work fits the agile process model and you live a high level of process loyalty, then the success of agile methods is always a question of attitude in the end. Yours too.

Good luck with that.

Article to download:

Further articles:

Working with Andreas: