Why HR is essential for an agile people-first organisation to work.

Sadly, HR is still overlooked. Many organisations state they have difficulty finding good talent but leave HR on the back burner.

Often, HR belongs to the "extended management", but many organisations don't make it a priority in agile transformations. So, to a certain level, it is also HRs own fault. In many organisations, HR still has an old-school reputation that needs dusting off - where it is perceived to be "bureaucratic" and "ineffective".

If your organisation has difficulty finding good talent, an agile people-first strategy may be a good way forward. And for this to work, HR, or to give it a modern name, people development, needs to get the attention it deserves.

However, one must consider that this is also a double-edged sword - with great power comes great responsibility.

To become an agile people-first organisation, HR will need to evolve and do its part. It will need to make some concessions regarding its domain - as you might imagine, more collaboration, cocreation and transparency are essential for success.

This article discusses positive patterns that a modern HR strategy may include along the "lifecycle" of a person within an organisation.

If your recruitment doesn't work, you'll never get the right talent to develop your organisation.

In many organisations, recruitment is still relatively disassociated from daily business - something you can't afford to keep doing. So how do you define the criteria for a new role, and how do you structure your recruitment process?

There are two types of hires - tactical hires and strategical hires.

If you are looking for new talent to add to an existing stable setting - a tactical hire - then defining the role should be delegated to the team. The peers/teams should be in control of defining the profile they are looking for - HR and the leadership team should only challenge these roles from diversity and financial angles. Aside from it, the team/daily business should be in control.

The recruitment process needs to be fast and transparent; it makes sense to use a shared recruitment tool, and the peers/teams should be in the loop. Through this method, the recruitment process becomes intelligent and flexible - the peers/teams understand what is going on and can help screen candidates early on. In addition, opening up the process encourages "hire for attitude and train for skill approach".

As a result, peers can avoid high-potential junior applicants being removed from the process because they do not fulfil some criteria. They can also bring in the gravitas needed for senior applicants, asking specific and detailed questions early on.

In the end, the team should decide who is hired - this may sound obvious - but in many cases still isn't.

Strategical hires are a different topic - if, for example, a new team with new skills is to be introduced, the leadership team may need to drive this process.

Onboarding – a critical topic that is underestimated and vital for successful talent development.

I have often thought of onboarding as a somewhat less important administrative chore. However, how your organisation performs the task of onboarding talent sets the tone for everything that is to come.

It doesn't need to be perfect, and it should be performed in line with the spirit of the organisation, but it is nevertheless vital.

Here are a few questions you should think about - not rocket science - is your organisation handling these questions adequately?

• When the new person starts, do they already understand how things at our organisation work, e.g. social norms?

• Before an individual starts their new position, do they have a contact where they can ask questions and get to know the people who will be in their future team?

• During the first week, does the person have a "coach" that proactively supports them in removing the most common impediments?

• During the first month of their employment, has the person had multiple check-ins with their leadership team to clarify questions and expectations?

• Did the person define the first set of realistic and shared goals within the first month?

• Did the person define and agree upon a personal development plan within the first three months of their employment?

Suppose you happen to be in a big organisation with highly standardised processes. In that case, you should watch out for waste in the process and check how "honest" the process is - e.g. if something gets flagged, do you diligently follow up on improvements?

Suppose you happen to be in a small organisation with variable processes. In that case, you should monitor the process's effectiveness and ensure that every new talent has a good experience - e.g. if something is left out or shifted, make sure that it still happens.

Roles, mobility, and teams – how are you coping with a fast-changing world?

Cycles are generally becoming shorter - this has also an impact on roles, mobility, and teams. How are you coping with these changes?

One of the central underlying questions is how your organisation's structure looks. For example, some modern organisations are organised around product value streams, and others are built around stable teams. These preconditions will indicate how much flexibility you have in defining your roles, mobility and team frameworks.

E.g. in an IT/services company, you might be relatively flexible in letting people move around. However, in a highly regulated medical/financial company, you might have some additional constraints to consider.

It is generally advisable to have roles established - they support you in shaping responsibilities, career paths, and compensation. Nowadays, roles are changing faster, and a modern employer also needs to provide mobility - aspects like more or less responsibility or a lower or higher amount of work.

Again, HR needs to take over a leading and serving role at the same time - HR needs to signal that it encourages change, needs to channel initiatives, listen to the requirements, and track the impact. Oscillating between these two states is challenging - providing the organisation and teams with enough room to self-organise while still being able to run and channel the central aspect of the HR role.

Combine intrinsic and extrinsic aspects to make people want to give their best and stick around.

I recently had an interesting discussion about how Gen Z interacts with the job market and vice-versa. Behaviours and expectations have changed. This goes for how the employee behaves towards the organisation and how the organisation behaves towards employees.

So, it is time for new reward systems? But how to design and evolve reward systems?

We can use a few established baseline patterns as starting blocks:

• You want to build a reward system that encourages collaboration - incentives should be at the core, promoting holistic actions.

• You want to develop a reward system that focuses on unleashing intrinsic motivation - while still considering extrinsic factors.

Here are a few key checks I run on salary and reward systems:

• Is it fair and transparent? It needs to be fair and transparent to keep the actors honest and avoid backroom deals.

• Does it have clear, measurable and agreed-upon benchmark criteria? Only like this people can understand what they need to perform. Consider: The agreed-upon benchmarks should also align with the organisational values.

• Is there a fixed and a variable component to the incentive strategy? Is the variable part collaboration-friendly? It is a missed opportunity if there is no variable part - not having a dynamic system where the person has a direct impact and gets feedback from the system is a missed opportunity. However, the variable part needs to be collaboration-friendly - it should not lead to suboptimisation.

• Does the organisation have an instrument to promote intrinsically driven actions? Of course, it should always stay the goal of reducing extrinsic factors to a pure "hygiene factor". However, this is the most challenging part in practice - truly unleashing intrinsically driven aspects needs a difficult-to-achieve equilibrium between mindset, people, and mission.

As always - design, test, execute and review change. Rinse and repeat. In today's fast-moving world, reward systems should also adapt frequently.

Offboarding – is just as important as onboarding.

Nowadays, it seems to be nearly established good practice to have a side gig going. As a result, tenures at organisations have generally become shorter. The reasons for this are manifold.

In general, it is safe to say that the commitment in the employee-employer relationship has decreased. Employers seem to be less committed to a social contract/social responsibility, and employees are less invested in the long-term sustainability of the employer. It goes both ways and is probably, to a certain extent, an overarching social pattern - at least in the "western world".

Offboarding is an afterthought in many organisations - the last step in the employee-employer lifecycle. Something that still "needs to be done" to end the relationship. Seeing it that way is, in my opinion, plain wrong.

Offboarding is a new beginning. Who tells you in today's quickly evolving world that you won't meet again? E.g., at some point, the person might like to return to the organisation. Or the organisation might need the person again. Who tells you that you can't create future win-win situations? E.g., at some point, the organisation could use the person's skill in a subcontractor setting. Or the person could point other contacts as customers or future employees in the direction of the organisation.

There is vast potential - and the organisation should make it a priority to benefit the person. If it is an honest and well-meant initiative, the organisation will also reap benefits. Do you need some ideas & patterns?

• Do you have somebody from your organisation regularly checking up on people who have left the organisation? Primarily to ask them how things are working out and if you can continue to create win-win situations. This assignee should not be a random person but a close colleague who has a personal connection to the person who left.

• Do you have an actively managed alumni network? To help alumni co-create after their tenure at your organisation - and maybe even come back someday. If you do it, it should be clear that you do it "actively" and honestly - continue pushing information (like job offers) but, e.g., paying for an annual snacks and drinks party.

These are just some ideas. There might be specific things depending on your context. And always remember - put people first, as it is an "infinite game".

Digital product design. How to build a product backlog? A central challenge for success.

Maintaining product backlogs is one of the major challenges of developing digital products.

Greenfield or not?

At inPositiv, we have begun work on producing our first internal product. One of the central guiding questions is whether you can go for a greenfield approach or not. Only seldom can you go for a greenfield approach. In most cases, there is already something there - as was in our case. The existing artefacts may range from an early throw-away prototype to full-fledged legacy software.

Some people argue that a greenfield approach is easier - I would say neither nor. When going for a greenfield approach, you must perform a diligent product idea validation, which is a costly process - while not (yet) delivering tangible business value. At the same time, the product idea is still in the early stages, making it an easy target.

If you are going for a brownfield approach - as in our case - it is essential to not fall into the "all-legacy-features-or-nothing trap". We have an existing piece of software that works. It is up to us to improve it from a functional and UX perspective. We may even remove some functionality if it provides little value or is badly implemented. In fact, we intend to ship a first release that doesn't include all features our stakeholders would like to see. But this is how we will start to gather feedback and improve relentlessly.

In a nutshell: If it is your task to build up a product backlog, ask yourself if you are in a brownfield or a greenfield situation. Then, depending on the preconditions, you have to consider and evaluate the input artefacts differently. The general rule applies: Your backlog, aka output, will always only be as good as your input.

Do you understand the big picture?

Do you know in which direction your product should evolve? Do you understand the big picture? These are essential questions to build up a product backlog successfully. Of course, you can't know everything - you never will - but it is vital to have some rough guidance.

How did we solve this challenge?

We feature a brownfield approach. Therefore, it was easier for us to understand the big picture. However, we faced the same challenge when building up the backlog.

Depending on the tool you are using (we are using Jira) and the size of your product development (single team vs multiple teams), you have to consider different abstraction layers. Side note: It is advisable to start small and verify first in most cases.

In our setup, we can work with long-lived epics and stories. This structure is good enough for the size of our endeavour.

In multiple workshops, we have shaped and prioritised the epics. These represent our big picture. Interestingly, we had a vivid discussion about whether we should go for domain-driven or user-centred epics. For now, we ended up with user-centred epics.

Currently, we have 18 epics of different sizes and priorities. One is the technical enabler, 12 cover mostly existing functionality we want to improve, and 5 are brand new functionality, which will act as differentiators for our product.

It is of utmost value to share the big picture with all stakeholders. Therefore, we will continue doing this and refine it continuously.

Have you considered technical health?

Technical health is essential for a successful digital product. Have you considered it? There is often a fine line between considering technical health adequately and over-engineering.

What is technical health, and what impact does it have on your product?

Technical health considers all underlying technical aspects of your digital product. I would differentiate between technical health in the narrow sense - the topic here - and non-functional requirements / operational elements - which I will discuss later.

Technical health directly impacts the speed and quality of your product development. Therefore, consider it, but making some trade-offs is also possible.

In the section before, I mentioned the technical enabler epic in our backlog. This epic serves precisely the purpose of managing technical health and creating a space for major technical health-related tasks which are too big for daily business.

We will establish standard good practices like coding guidelines and code reviews that are beneficial to technical health.

But there are also further-reaching aspects like an environment concept, good quality test data, static code analysis and even potential moderate change to the architecture, aka refactorings.

Technical health is essential. Not considering it from the beginning will introduce technical debt, which will slow things down, generate quality issues and drive up costs in the long run.

Do you involve the right stakeholder?

Do you involve the right stakeholders in your product backlog? How can you identify these stakeholders, and why is it important?

The two most important domains of stakeholders are the sponsors and the users. Often there is an overlap here. In some cases, they might even be the same people.

• The sponsors often have a higher-level perspective and are interested in seeing the product achieve its big-picture vision. Often, they may also be the stakeholder that delivers the funding and expects a return on investment. So when building up your product backlog, this type of stakeholder will be interested in aspects like shortening time-to-market, scalability and fulfilling value propositions.

• The users usually have a down-to-earth and operations-driven perspective. These users can be "internal" or "external". Depending on the product setup, the internal user may be wearing an operational hat, and external users are the actual end-user who reap the benefits by consuming the product's value proposition.

These two important stakeholder groups exist in most settings, and keeping them in the loop is vital. Additionally, these two groups will have different interests throughout the product development process.

Not involving one of these stakeholder groups will jeopardise your product development efforts.

• Alienating your sponsors may lead to a situation where the funding for your product development efforts will run dry before you can get to an MVP state.

• Alienating your users may lead to a situation where you lose backing and demand for the results of your hard work. So the product you are working on won't get any response on the market, and the usage will stay below expectation.

Identify the relevant stakeholders, keep them close and include them in the process of continuously validating your product backlog.

Are you prioritising correctly?

Missing, unclear or conflicting priorities is one of the classic challenges when developing products. It is usually less complex if you have just one team and hold the product owner role. But it can become a significant issue.

Many concepts tell you how you should define your priorities. But, unfortunately, reality seldom works like a predefined concept - there is usually more in play than can be predicted.

I discussed the critical stakeholder groups that help set priorities straight. However, it can also become extra tricky if you have to decide against the interest of one of these important stakeholder groups.

So here are a few concepts that can help you to prioritise:

• How relevant is a feature for the core experience of your product? Does it lead to a substantial differentiation?

• What is the time-to-market impact of a feature? For example, does the introduction of the feature accelerate time-to-market - e.g. by convincing more potential users that the product has reached maturity?

• Does the feature scale well? For example, are you implementing a custom finish, or is it something that a broad range of users can use?

• Is the feature decreasing or increasing the complexity of the product? Is it a starting point that demands follow-up investment, or is it a consolidation that may even tie up some loose ends?

Considering these or similar open, shared, universal concepts as benchmarks can simplify prioritisation.

Having clear priorities and a good plan increases the effectiveness of product development.

Do you have a sound project setup?

At first glance, this may sound like a rather administrative topic. But neglecting it will throw all your product backlog efforts in disarray.

Let's assume you have a good product backlog and are on the journey to build your product. How are you proceeding on your product development journey? Can you demonstrate progress? Can you respond to change? These are classic issues that can stall product development.

To fix these issues, you need a persistent and disciplined mindset. But there is also the methodological part of the setup which needs attention. When building up your product backlog, you should actively investigate the following questions:

• Who is holding which specific role when developing the product? Mainly to define and establish clear responsibilities - may come in handy if, e.g. a difficult decision needs to be taken.

• Who challenges these roles to perform admirably over a longer period? Mainly to coach and challenge these roles - may come in handy if, e.g. there are some interpersonal issues in the team.

• What product development setup/shared rules are we using? Mainly to measure progress and check if you are delivering according to plan - it may come in handy if a sponsor wants an update by when she can expect the delivery of a new feature.

• How are we responding to change? Mainly to define when one can safely raise a flag and design the change process - which may come in handy if something in the team or the product roadmap needs changing.

A clear understanding of these questions will increase the chance that the product development initiative will succeed.

There is no need to reinvent the wheel - applying a tried and tested framework like Scrum is undoubtedly good enough.

Do you have a healthy product roadmap?

A plan is a plan - product roadmaps are tricky because reality usually does not treat them nicely. Nevertheless, it is essential to have some guidance to know where you are going.

Some agile evangelists might argue that you only need a backlog and you should "just" let the team pull from that backlog according to identified priorities. This idea sounds nice in theory, but product development doesn't work like that.

In complex settings, dependencies and stakeholders need additional consideration. For example, your product setup will depend on other solutions, teams, and external suppliers when reaching a certain size. Additionally, you will need to address and involve upstream and downstream stakeholders - like business development, operations, and product sponsors.

It is advisable to have a lightweight product roadmap to increase the chance of successful orchestration in complex settings. You should know which stakeholders you focus on and make it as simple and "universally understandable" as possible.

You can take these considerations as guidelines:

• Which time horizon do I want to cover? Consider: Reality is usually more complex than anticipated. Up to two years ahead is usually a reasonable timespan. More than two years becomes vague.

• Which stakeholders do I want to address? Consider: This is a critical question. It will impact everything - from detail grade to the domain language of your roadmap.

• Do you only want to "send", or do you also want to "receive"? Consider: In most cases, product roadmaps "send" information to other stakeholders. But good product roadmaps are interactive; the stakeholders can also interact with them and contribute valuable data.

• Which depth do you need? Consider: Has a relation to the stakeholder selection topic. For example, do you go down to feature and dependency level or are you on a higher business/value proposition flight level?

Starting from these questions, you can then design your lightweight product roadmap.

You can treat the product roadmap as a second-class citizen if you have a clear mission and closely involved sponsors - because good product development execution should always go first. But if you have room to improve these supporting elements - go for it!

Is your backlog able to adapt?

One of the most demanding challenges is balancing "backlog discipline" with good execution; this is one of the most challenging trade-offs in product ownership. However, if you can develop your product and have these two aspects in a good balance, you can proceed with the highest effectiveness.

Let me quickly describe the two anti-patterns:

• I've already seen beautifully designed backlogs-big, well-maintained, and lovely stories - but these usually lack execution. You start to become defensive about "embracing change" if you have already invested "so much" in your backlog. And trying to specify too much in advance draws resources away from building and running the solution. Edge case: A setting where you can invest as much as you want - but this is undoubtedly not the highest effectiveness from an economic perspective.

• And this is usually the more familiar anti-pattern: I sadly often see dried-out backlogs. In the beginning, the product is new, there is a push to build a cool backlog and convince stakeholders, and onward, it is drained. The backlog doesn't really live, and also critical new features are built in-flight, or the team might even stop using stories. This is one of the most severe product ownership anti-patterns.

As so often, the optimum lies somewhere in the middle. There should always be a slight tension.

If you have time to specify everything ahead easily, there,

• is either not enough demand in the market for your product,

• you don't do enough product-centred innovation,

• or you have too many resources in the design process.

If you experience the situation of a draining backlog, you either:

• Don't live your methodology/manage your stakeholders to the full extent

• Don't have a vision/valid product,

• or not enough/right resources in the product design process.

As in many entrepreneurial areas, good product development is a state of creative restlessness. But it would be best to prevent it from becoming chaotic - a welcome complex challenge.

Knowledge management. More important than ever in a VUCA world. But also more difficult than ever.

In a fast-paced data- and knowledge-driven world, we hear many pointed statements like "we want to learn directly from real-time data" or "all our applications should be self-explanatory". Granted, these premises are valid and exciting. But, organisational contexts are becoming more interconnected and complex. This does not reduce the need for effective knowledge management.

Many organisations face major challenges in the area of knowledge management because they are not yet able to deal adequately with the increased speed. For example, in software projects, it is difficult to keep documentation synchronised. Because the reality is in the code which may have to change quickly from time to time. Nevertheless, knowledge management remains essential. Otherwise, knowledge gets bogged down in the organisation. With the result that it is then just hoarded again implicitly and distributed. In a complex world that operates with vertical teams, t-shaped skillsets and short decision cycles, good knowledge management is more important than ever for a powerful organisation.

No sooner has knowledge been documented than it is already out of date again. An omnipresent challenge. What should be documented?

It makes sense to first create a consensus within the organisation on this matter. Again, the requirements vary from organisation to organisation. In certain industries/domains, there may even be legal requirements to consider.

To create a common understanding in the organisation, one can be guided by the following four dimensions:

1. Strategy: What knowledge is of strategic importance to the organisation? The strategically relevant knowledge should be documented. This dimension provides the incentive to rather document too much than too little.

2. Horizon: Is the knowledge relevant in the medium to long term? Cycles are getting shorter and shorter these days. Accordingly, it is more difficult and also more costly to keep short-lived knowledge up to date. This dimension tends to reduce the scope of the knowledge to be documented.

3. Multiplication: Can the documented knowledge be multiplied? If the documented knowledge can be easily shared and applied, the usefulness of the documentation also increases. For example, an FAQ can be thought of that significantly reduces the support effort when rolling out new software.

4. Interest: Do the documenting and consuming stakeholders have an interest in keeping the knowledge up to date? Documented knowledge that is seen as "of little value" by the stakeholders involved has a hard time. Here the circle can be closed - how strategically relevant can the knowledge then be? But nevertheless - there may be situations in which one also has to document "unattractive" knowledge. In such cases, one then needs a binding process and at the same time should limit the documentation to the minimum.

These four dimensions help to define what should be documented.

Who should document knowledge? Typically, people who are knowledge holders should document. Relatively obvious? Yes, but the challenge is once again in the details…

If knowledge is to be documented and maintained, it also needs time and focus. There can be several anti-patterns that prevent successful knowledge management. We look at two of them to illustrate who should document knowledge.

• No time: No time is probably the biggest opponent of sustainable knowledge management. Rarely is time organically allocated to knowledge management in organisations. Once you have identified which knowledge you want to document, you have to create space for the documentation. If this does not happen, knowledge is documented robotically and is not maintained.

• Empire building: There are knowledge holders who like to document knowledge. But if only certain people actively pursue this task, it can lead to "empire building". The specialists build up their documentation according to their own structure and sometimes even develop a claim to dominance. As a result, other people are not allowed to contribute or, in some cases, the documentation is reduced to absurdity because the knowledge is not comprehensible for the actual target group.

Positive patterns can be derived from these two frequently encountered anti-patterns:

• The best people to document are those who know the most. However, these people must be actively given the time to do so. Conversely, if the time for knowledge documentation does not seem to be sufficiently valuable, something must have gone wrong with the definition.

• The documentation of knowledge must not be a singular act. It needs a shared structure and the documented knowledge should be jointly reviewed. Depending on the size of the setting, it may therefore make sense to give one person an additional role to empower the documentation process.

Which tools should be used? It is better to start too small than too big. Many organisations tend to make the process of knowledge management too complicated. This does not have to be the case.

In the past, knowledge was documented in a library or archive. Thankfully, technology has given us new possibilities over the last 20 years, ranging from a simple word document on SharePoint, to fully developed Wikis with questionnaires and video tutorials.

Word files on SharePoint can work but come with challenges. You have to know explicitly where to find what. Which can be rectified with a "Table of Contents-Word". All OK, but manual, error-prone, implicit and difficult to multiply. In such settings, it becomes particularly time-consuming if the structure of the documentation has to be changed. On the other hand, the entry barrier in this system is low, since practically anyone can operate a Word document. Conclusion: It can work, but is hardly sustainable.

There are various stages of expansion from this starting point. One can move from Word to One-Note - but this does not solve many basic challenges. I would advise a wiki as a tool for knowledge documentation in most settings. Depending on the requirements, size and IT affinity of the organisation, different constructs are possible. If you are deeply in the Microsoft ecosystem, then SharePoint is a good choice. If you are looking for a somewhat simpler alternative, you can use Confluence. Note here: Organisations with a development department in particular often already have Confluence without actually knowing it. And if you want to expose the wiki to customers, it can make sense to use an existing framework like Wiki.js, XWiki or MediaWiki.

How deep and extensive one wants to go in terms of content is then again up to the setting and also the willingness of the organisation to invest.

How to make knowledge management sustainable?

In this article, we have looked at some positive patterns:

• What should be documented - to generate interest in knowledge.

• Who should document knowledge - to create the right incentives to document knowledge.

• What tools to use - to make the process of documenting knowledge engaging and simple.

With all these patterns considered what now can go wrong?

These are good and positive conditions, but they do not ensure structure and consistency. A role is needed to coordinate the knowledge management process. This role should not document knowledge itself - it cannot be a specialist in everything - but it must channel the knowledge in the organisation. You can think of this role as a Scrum Master. The person is not an "administrator" but a "leader".

How does this understanding of the role manifest itself?

The role must understand and represent the concerns of the knowledge consumers - so that relevant knowledge is documented. The role must establish consistent and shared rules for documenting knowledge with the knowledge documenters - so that knowledge is documented correctly and in a structured way. The role must coach the knowledge documenters and also require them to do so - so that the documented knowledge is constantly refreshed. In smaller organisations, this can be seen as a part-time task. In larger organisations, it needs the full focus of one person. It depends on how much the role still contributes/can contribute materially itself.

If the mechanisms considered in this article on knowledge management play together, the chances for the sustainable success of a knowledge management system are good.

An important topic - please do not neglect it.

I want more agility. How can I move my organisation towards that goal?

What about classic change management?

The need for change is nothing new. I remember learning the 8-step model at university. But how does an Agile transformation differ from "classic" change management?

It makes sense to start with the relationship to change management. Why? Because all agile methods build on what already exists - for example, one could argue that the foundation of modern agile methods was laid by the TPS (Toyota Production System) in the 1950s. Accordingly, it is not wrong to also reference the 8-step model (Kotter, 1996) as a starting point for Agile transformations. All well and good, but how does this apply?

When you talk about a transformation or about a classic change, you convey a sense of finitude. One "does" a transformation and "ends" a transformation successfully. But this is not agile’s purpose. Why?

The goal of an agile transformation is to build continuous flexibility into the organisation. Aligning the organisation in such a way that it automatically recognises the urgency for change - the culture develops so that one does not try to remain in the status quo with closed eyes for as long as possible, but rather approaches new challenges with an open mind. It is also important to adjust the organisation in order for change initiatives to organically gain the necessary support - the structure must be opened up so that people can empower themselves. Sounds like chaos?

As always, simple, shared and binding rules are needed so that the constant flexibility does not become a constant restlessness that tears the organisation apart. It should be clear nowadays that lethargy is not an option.

Once the transformation flywheel has been set in motion, the first 3 steps of the 8-step model should no longer be a challenge as the organisation is conditioned to continuously execute the first 3-steps of the model automatically.

Find the problem.

If your organisation doesn't have problems, then it probably doesn't exist anymore. Every organisation has problems. How do you tackle the right problem?

Ask yourself if you have really found the problem or just a symptom. Often we feel we know what the problem is, but instead we’re dealing with a symptom. Finding the underlying issues is not easy. Sometimes it takes a while for the real problem to emerge. Is a symptom good enough?

A serious symptom can be good enough. However, it needs to be where the shoe pinches. If your organisation has to really bend over backwards for more agility, it is reasonable to assume that aspects such as culture and structure are not at their best. Still "push full steam ahead"?

This is not necessarily advisable. If an organisation does not yet live agile-compatible thinking, pointing out problems too transparently can lead to a downright allergic reaction. Instead of progress, you then get regression. How can you tell how far the culture has come?

An agile-compatible culture promotes the making of entrepreneurial decisions in a transparent environment. Decisiveness at all levels, high transparency before and during decisions, and adequate execution of decisions reflect positive patterns. If there is uncertainty in this regard, what is the best way to deliver the finding?

The problem should have a certain severity, but not be too threatening. The problem should be somewhat within the traditional area of responsibility, but also concern multiple domains in the organisation. The problem should not have any proven simple solutions, but at the same time focus on achievable improvements.

Without the will, there is no way.

If the leaders of the organisation don't want it, it won't work. How do you overcome appearances and start being?

If the leaders of your organisation do not want agility, then the initiative will not have sustainable success. Why and what are the possible solutions?

The primary problem is that agility cannot radiate in the organisation without leadership support. In a certain microcosm, agility will work, but in the bigger picture, agility will always face insurmountable obstacles and contradictions. This is because the necessary mindset or positive patterns cannot be truly established. It is a classic "doing agile" and not "being agile" case which erodes agility instead of promoting it. It is important to add that one should nevertheless not be dogmatic about this - one grows into agility and achieving an agile organisation is not a walk in the park.

The solution here is: accept limitations, limit agility to microcosms and continuously prove that agile methods bring better results.

But shouldn't we also want agility at the leadership level today? Yes, in the optimal case, management roles have also recognised the signs of the times - provided the organisation moves in a volatile and complex market environment - and wants to change something. The theoretical understanding can be easily acquired. Even "classically respected" magazines like HBR regularly bring up agility. So if you can win the leadership stage, you need a problem to solve. Once you have identified the problem, it is advisable to think about scenarios with the leadership stakeholders early on, as agility is not absorbed by the organisation without resistance.

I have leadership support and a problem - will the organisation just embrace agility? Of course not. The biggest challenge is to make the change "sustainable".

Roll out agility.

Operationalise agility. A difficult task. Not the most difficult, but a difficult one. How do I get going?

There is no need to reinvent the wheel. In fact, you should probably avoid doing so, as you cannot benefit from the lessons you have already learned. It is also helpful to fall back on established patterns. But how exactly should one proceed?

One should be guided by the following three things:

• What does our own "attack vector" look like? Large or small? Incremental or radical? Prescriptive or co-creative?

• What are our competitors doing? What patterns seem to work in our domain/industry and what doesn't seem to work?

• Which concepts from established methods and frameworks do we want to be guided by? Which concrete methodologies do we need and which tools correspond to the culture of our organisation?

These three points interact - you can imagine them in your mind's eye like a triangle - and you then define your position in the triangle.

• Accordingly, based on the answer to the first question, it may be that you only get started on two out of five business areas, for example, and then let agility radiate from there.

• Based on the answer to the second question, the structure of the organisation may be cut somewhat differently or incentive systems set distinctly.

• Based on the answer to the third question, different method modules are applied, for example, in the day-to-day business and at the portfolio level - one is inspired by an established method/framework for the day-to-day business and another is applied at a higher portfolio level.

This custom-fit needs to be rolled out. It is advisable to proceed incrementally and to have an adaptive roadmap. Why? So that one can react adequately to obstacles that arise.

Overcome obstacles.

Obstacles are everywhere. Overcoming obstacles is, next to recruiting leadership support and creating "sustainable agility", probably the most challenging task to becoming agile. How to tackle them?

Obstacles can come from all directions at any time. Accordingly, there are three premises that can be particularly helpful.

• Create transparency and keep it high. Without transparency, obstacles are seen too late and may be misidentified. Before the pandemic, one could have advised "Gemba" here - "floor-walking", "going to the frontlines". Since this is no longer possible or, in most cases, ineffective, reporting that is as lightweight and unadulterated as possible with short coordination cycles are much more effective.

• Keeping leadership on board. Without leadership support, you don't stand a chance from a big picture agility perspective. Accordingly, it is vital to demonstrate a high level of transparency towards the leadership stakeholders and to keep them continuously informed. This ensures that their trust in the initiative remains constant and that they can advocate for the initiative among their stakeholders, also allowing them to proactively advise and assist in solving obstacles.

• Maintain good risk management. Certain obstacles will require difficult decisions to be made. Effective risk management is very helpful in assessing the impact of these decisions. Interactions and dependencies must also be able to be interpreted from a risk perspective. Risk management is thereby also conducive to the first two premises, or rather - as with almost everything in a complex world - there is an interaction.

If one takes these three premises into account and has chosen an incremental and adaptive roadmap (see last and penultimate post), obstacles will always arise, but one will be able to solve them convincingly.

Is everything now peace, joy and happiness? Of course not.

Sustainable agility.

Shouldn't agility be "sustainable" anyway? Yes, but in practice, it often isn’t. What exactly is meant by this and how do I make agility sustainable?

When you think you have successfully implemented agility, you then have to think about making it sustainable.

But you probably can't really tell until a year or two after the rollout is "complete" whether the culture and mindset are also evolving positively.

Here lies the crux - don't let up and remain attentive. But why does this take so long?

You can compare an Agile transformation to a birth. The organisation is reborn, rejuvenated and can rethink what is outdated. But especially at the beginning, it is not yet strong, must be able to learn and needs support.

The organisation acts with agility, but it cannot yet reflect on its actions.

If the organisation has a bad upbringing as an agile toddler, these negative patterns will remain ingrained later.

Accordingly, it is important to get into a healthy learning mode after the establishment of the tools is complete so that the positive patterns can be reflected and anchored.

Just like in the classroom, a few troublemakers can have a huge impact on the learning experience. It is important to remain attentive to this.

The patterns for recognising and solving obstacles discussed in the last post can help.

To continue with this example: Teachers (= leaders) also need to be coached to prevent the organisation from slipping into passive agility.

Maintaining an effective corporate culture is one of the most difficult entrepreneurial tasks.

But if this task is avoided, the organisation will not be successful in the medium to long term.

Note: Corporate cultures are individual; accordingly, there is also a different measure of "effectiveness"; although of course certain universal positive patterns such as "collaboration" exist.

In summary, it is important not to see an agile transformation as a project with a fixed beginning and end.

The idea of an agile transformation is that in the long run, it is the last transformation. As you embed the foundations for more flexibility in the organisational DNA.

At the same time, this needs to be coached in the long term, otherwise, sustainable agility cannot take root.

This important point is often forgotten.

Agility has become the standard over the last few years. But what is agility, and do you really need it?

If everything is running smoothly in your organisation, you don't need to change. As the old saying goes, “if it ain’t broke don’t fix it.” You could leave this statement as it is. The problem is: what do you do when things are no longer running smoothly? The speed and frequency of change has increased. Therefore, it is advisable to increase organizational flexibility.

Agility is a tried and tested means to this end.

But do I really need agility? You need flexibility and most likely you already live certain agile patterns. Do you need agility? Not necessarily - depending on the conditions of your organisation, you can of course apply other methods, but many of the principles of agility are not wrong. So what actually is agility? Agility is by no means a ready-made method. Rather, it is a set of overarching patterns that allow your organisation's stakeholders to more quickly identify and respond to the need for change.

In summary, you could say that a more agile organisation is a more future-proof organisation. However, agility cannot replace strategy.

Your organisation needs to know why it exists now and also where it wants to go in the long run. Agility can improve the process of gaining insight through simple rules of the game and also help the organisation to continuously better align with customer value and value streams. But agility, and agile methods in particular, are not a miracle cure to replace a weak business strategy.

Agility is more than a method. What are the key building blocks of an organisation and what influence does agility have on these building blocks? Employees.

Employees are the most important building block of any organisation. The first employees of an organisation shape the culture and are essential for building the basic structures. Staff members who join later in the life cycle of an organisation are essential for the organisation to keep rejuvenating itself.

If no fundamental new impulses are set, the organisation will no longer adapt and will sink into insignificance. This, of course, must be prevented. Accordingly, it is central for every organisation to attract the best employees at all times and to give them maximum space to develop in the interests of the organisation.

People are at the centre of agile methods. Again, it is important to consider the current state of an organisation when starting an agile transformation, but agile methods should flow into the entire lifecycle of the employee and the organisation. From recruiting to staff development to offboarding. This will help attract the best talent.

Talents that can be optimally developed according to their own interests and also in the interests of the organisation. Win-win situations are continuously created in the employment relationship so that the joint life cycle can be designed for as long as it is mutually beneficial.

The organisation must be designed accordingly so that employees are at the centre and concrete agile practices support the implementation of the shared life cycle. There is an essential interaction between employees and corporate culture.

A healthy culture is needed for the benefits of agility to bear fruit. What are the elements of an agile-compatible culture?

The best agile methods and talents will not be able to survive if they are used in an incompatible culture. There is also the well-known saying "doing agile vs. being agile". A culture develops from various aspects. One central aspect is how incentives are set in an organisation. What behaviour is rewarded and what behaviour is punished?

For example, if individual performance is rewarded in an organisation instead of overall shared goals, it is difficult to work together sustainably in stable teams - because individuals are encouraged to work in their own interest. If, for example, a healthy learning culture is not established in an organisation, the agile pattern of continuous improvement cannot gain traction.

So if agility is only understood as a collection of methods for improving processes, some of the most important advantages of an agile organisation cannot take hold. In an organisation that wants to be flexible and future-proof, there must be an understanding that the incentive and value systems must change or become more modern.

This is because they shape the culture, and culture in turn is decisive for how talent develops in the organisation. Besides incentives, the structure of the organisation is another key factor that has a big impact on company culture.

Rigid corporate structures are one of the biggest obstacles to agility. How then can you avoid becoming too rigid? No structure? Of course not.

Depending on size and existing organisational structure, different adaptations can be effective.

Structure can be one of the most visible limiting factors. While structure is the easiest to change, when isolated, change alone does little. People and culture are more important to consider when meeting business objectives. Nevertheless - the wrong structure can lead to great inefficiencies. So what are possible patterns for successful approaches?

Different sized organisations need structures of varying complexity. An organisation with up to 50 staff members may have a simpler, more "family-like" structure. An organisation with 150+ employees, on the other hand, needs additional coordination.

The need for flexibility also plays a major role. An organisation that seeks to become more efficient in a highly standardised and regulated sector will be sufficiently sustainable even with a more rigid structure. An organisation that operates in innovative and volatile market conditions, on the other hand, needs a more dynamic or more frequently adapting structure.

What then should one look for in the actual design of an organisation's structure? To achieve the maximum possible customer benefit.

Practically every organisation wants to deliver customer value in an “agile” way. That’s all well and good. But how does one actually approach customer value. Many organisations don’t know.

Of course, every organisation has at least some KPIs that provide an indicator of customer value - primarily profit and order entry. But is this enough?

These two KPIs do not make it clear, for example, whether the organisation is providing the right services or building the right products in the medium term and whether the quality of delivery is satisfactory.

How can agility help here?

A more agile approach allows better and faster reactions to the demands and needs of customers.

The organisation aligns itself in such a way that more frequent and meaningful exchanges and cooperation with customers become the norm.

What does this mean in concrete terms?

This disruption can go a long way - from team compositions to team focus to the frequency of structural changes.

The building blocks of staff, culture and structure must be coordinated and aware, so that the need for change can be recognised early and responded to correctly. Thus the process of change can be transformed from a stressful process into an eye-opening adventure.