Agile organization – system view

What is an Agile Organization? A relatively simple question with a very complex answer. Many “definitions” state that it is an organization capable of responding quickly to change. It can also be read that this is an organizational arrangement in the form of a flat organizational structure, an adaptive network of multifunctional teams. And other information and observations, which together have one common shortcoming. In fact, it focuses only on the most adaptive, agile part and does not solve at all that activities of a different nature also take place in the organization as a whole. Process, project.

However, if we want to get a realistic idea of a real agile organization, we must include these “ordinary” things. Otherwise we will always miss something in the given model. So let’s think the whole thing systemically for a moment, as a whole.

An agile organization is not just Scrum

At “Agile and SCRUM” training or at various conferences and professional forums, I often hear sighs and remarks like: Scrum is nice, but it doesn’t really matter where the inputs come from or what’s next with it.

On the one hand, this is not entirely accurate. On the other hand, it takes things out of context. It is clear that the Scrum team (or any other team) is not hanging in a vacuum. But that for some purpose it was created and has some surroundings. Exceptions may be startups the size of one team, but this is probably not the majority case.

In addition, agile, agility or agile organization does not equal Scrum (or Kanban, SAFe, LeSS,…). This is just one of the applicable frameworks for agile development. Agile organization is a much broader concept and includes elements such as:

• focus on value delivered to specific customers (customer centric, value driven),
• complex situations are solved by adequate approaches (eg Scrum, Kanban, etc.),
• the flatest possible organizational structure and a high degree of self-management and self-organization,
• appropriately formulated and defined meaning of activity, existence, which gives people a sense of their actions,
• enables people to be motivated by giving them the possibility of autonomy, mastery and the above-mentioned meaning (see D. Pink and the book Drive),
• management creates an environment for the work of self-managed teams instead of directly commanding,
• works with values,
• has a high level of culture in which people trust each other, are open and error is not perceived as a problem but as an opportunity to learn,
  etc.

Agile organizations as a complex system

Therefore, when we look at the organization as a system, the whole, so (with respect to the CYNEFIN model, for example) we will see several basic streams of the value flow of organizations (Lean):

The picture shows a model situation that will be more or less different in different contexts, but I believe it will serve our purpose.

“Routine” activities

Some of the organization’s activities will consist of day-to-day operations. It is necessary to ensure accounting and other common agenda, which according to Lean is a “necessary” waste. We have to do it, even if it has no value for the customer.

The next part is also “business as usual”. Normal operation in which individual traders sell mortgages, couriers deliver rolls or anything else, the administration liquidates insurance claims, etc. In short, everything that takes place through some set process. In the case of banks or insurance companies this can be most of the activities of the whole organization.

Of course, these areas should, if possible, generate value without unnecessary waste. Thus, stable, cross-functional teams, self-organization and other Lean elements can be considered here as well. Why not? Although members of these teams may not develop a new product using Scrum, they can still be highly self-managed, with a flat organizational structure and an advanced team culture. This is not a question of the framework used.

Changes and new things – the focus of an agile organization

The other activities of the agile organization are certainly about changes and new things. There are various stimuli and ideas at the “entrance”, which are either completely new or are ideas and clarifications created thanks to the feedback. Internally or from customers.

No matter how they arose, these stimuli should go through some initial “assessment”. It will either be clear that YES, or clear that NO, or for some input, verification analysis will need to be performed.

Of course, such an input analysis makes more sense for bigger new things, such as a new product, plugin, etc. And in such a case, various forms of using techniques and tools such as “design thinking”, “product vision board”, “business model canvas” can occur. , “Elevator statement”, etc. There will be a number of prototypes and a lot of experimentation. This is what this phase should be about, specifying and validating the direction of development. About learning where to go and not to as soon as possible.

The result can also be NO, there is no point in dealing with it further, or YES, in such and such a basic form it makes sense.

Aggregate ROADMAP – Central Station

If the result of the assessment is positive, the whole matter will be included in the overall “Roadmap development”. An up-to-date idea of what could ever happen. Whether we call it a summary roadmap, an overall backlog or whatever, it’s about having those approved things in one place where we can see them side by side and how they interact. Let’s always take it as a visualization of the current idea, not some strict plan or definitive one into the worksheet. It will definitely change over time.

In addition, a list of some minor adjustments in the range of several members may (and may not) be set aside, which often do not even require a whole team, but even just one person. It can be various customizations, things related to the implementation of a particular customer, etc.

We must not forget to fix bugs that will simply occur for various reasons.

Coordination

Items from all entry lists (or one global one) should then probably go through some form of coordination, prioritization. So that it is possible to decide what will land on one of the teams of “pure” agile development (imagine one to N stable, cross-functional self-organized teams), what will land on the team (s) of minor adjustments (which will need their Kanbans) and what happens in a predictive way (with the team, teams or external entities designated for this type of activity).

Ideally some lean “pull” system.

Bug fixes should then also be subject to splitting and a certain capacity of all teams should be consciously reserved for them (according to the size of the buglog).

Synchronization activities

Mutual coordination during the work is important both because there may be an exceptional need for a small development team to do something small (eg for historical reasons, experience, etc.), to make it clear which team will take what, or to unknowingly, more teams did not make adjustments to the same functionality (albeit from different sides and on the basis of different stimuli), etc. In short, for the left foot to know what the right is doing.

Depending on the situation and need, overall coordination can take place either for each iteration (sprint) or once every several iterations. In any case, regularly and so that everything runs smoothly.

Value

For predictive activities, the value is usually released at the end. In the case of continuous handling and “pure” agile development, the value can be released continuously or at the end of the iteration. Depending on the context of course, where feedback should also always take place (thus closing the development cycle).

Of course, the question is whether the released value requires some further processing. E.g. the team that takes care of the operation, etc. This will probably be significantly different in different situations. Ideally, the released value should not require any further processing (done when done). However, this is rather difficult to achieve in practice. This aspect must therefore also be considered and not left out in the system.

Like coordination, feedback and retrospective should take place within all basic streams of value, ideally in synchronization with each other.

We can set up, for example, a monthly macrocycle, at the beginning of which there will be an overall coordination. Then the predictive and continuous current flow in their own way. The pure development reverses four weekly iterations. And at the end of the month, all three streams meet and evaluate how it went, etc.

This does not mean that communication and coordination do not take place on an ongoing basis. But if we design it well and the interconnections are minimized, it should not be so much needed. The goal is for individual teams to have enough space to focus on their work.

Not all that flows is a waterfall 😉

Be careful not to distort, the approach described above is not differently described waterfall! For many initiatives, it is initially only a global Yes / No decision whether to include them in the “backlog” or not. This step is not a detailed specification, etc.

Only at the product owner (s) level will there be a prioritization against other items on the list. And it is possible that some will not happen anyway. And only in the team will we solve their more detailed description, choice of implementation method, etc.

In the event that it is a more extensive stimulus and it requires an initial “product development” phase, even this does not produce a complete, fixed assignment. The purpose is different – to define the vision of the product and its basic features so that the team knows where to go at all.

And this also applies to predictive assignments, where we can imagine something like a “business case” or a “feasibility study” as a result of this initial phase.

The above solution corresponds, for example, to the concept of “Dual track agile” or the approach described in “Disciplined agile delivery” or SAFe.

Agile organization organizational aspects

Of course, this way of creating value will also have an impact on the appropriate organizational structure of our agile organization. Different, de facto dedicated teams can be created on different parts of the value stream. It is possible to consider eg:

• Expert team for conducting initial assessments (product development, can be stable),
• Scrum team (one or more, depending on the number of products, etc., stable),
• Kanban team (one or more, depending on the amount and type of work, can be completely stable),
• Project team (one or more, there will probably be the most “movement” in terms of composition, but even here there may be some type of “rapid deployment unit”),

The goal is to create teams that are as stable as possible and do not need intensive cooperation from others. Which depends a lot on our ability to map value flows and good coordination of whom to give.

Scrum teams will be probably the most closed grouping, which creates gains in value in short sprints.

The kanban team (one or more) may be a little more grouping of individuals who handle their items and more or less gather and dump as needed.

Project teams will be created primarily according to the needs of the project and most likely also with external entities. Internally, developers other than those allocated to scrum or kanban teams should be reserved for project work, otherwise we will impair their stability.

What is the responsibility of agile organization management?

Someone has to make an initial YES / NO decision, determine the overall priorities and vision of the whole organization, oversee coordination, create space for self-directed teams, support their culture, self-management, etc.

If an idea for a good new product comes up, someone has to say that one of the existing teams will take over or create a new one. Of course, you can leave this to the teams in some cases. Or that one of the products will be discontinued for some reason is a very “business” decision.

In addition to a suitable environment for development teams, someone must also take care of the environment and culture of the day-to-day operations teams, according to their specific value streams.

And last but not least, someone has to take care of the current administration and operational agenda, a necessary evil.

So there is quite a lot. However, the effort pays off and it makes sense to strive for greater adaptability of the organization. As a means to achieve bold visions and goals.

However, it is always necessary to think things as a whole, a complex system with various aspects, proceed with change cautiously and avoid dead ends.