The “do it” principle

Why and how to be really agile?

Agile, as a word, is burned!
Many people associate the word with scrum, a process they maybe do not like. And above all, there often still remains the question “why”.

And sometimes that is, for real, a good question. If we only replace the implementation process and team organisation with a scrum process, but the whole rest of our efforts is to keep track with the old company organisation, it is hard to recognize the advantages of an agile process. Maybe there isn’t any advantage we benefit from.

So, in general, nobody will become more agile by only implementing any agile method.

It is totally necessary to understand the meaning of being agile, and further, it is necessary to understand the benefit of and the need to be agile. Agile must be seen as a mindset, far away from any method or tool.

Design thinking, for example.

When I heard about it the first time, to me the novelty was not obvious. Sure, the “how” was new to me. And details like creating personas or in general defining this process exactly has been new. But the general practice of design thinking to evaluate facts as fast as possible and to re-build and re-evaluate in fast iterations was not that new to me. In my opinion, that’s the common development process.

And maybe it is more necessary to perform a process acting identical or similar than having a name or a ruleset to do so.

But if we stretch the context and look at the big picture we recognize a major change by implementing design thinking as a method at the start of the value chain. More on that later.

Let’s talk about the “why”. Why do we all have to become agile? Why is the cultural change of digitalism mostly associated with the need to become agile? To implement agile methods and to evolve an agile mindset?

Why agile?

In fact, there is one thing getting changed by spreading digitality. When we take a look at the core of the effects we will recognize that the speed of everything changes and the ways become shorter than ever.

As a first-class effect of digitalism, the increasing speed of communication, development and change is the obvious strongest effect.

Everybody and especially companies have to move on to keep track with changing times nowadays. Perhaps tomorrow there is a competitor moving faster, delivering faster or providing better service, and this competitor can be a thousand miles away.

It is necessary to improve ideation and development processes with the focus on reaction speed and general flexibility. From there the need for agility is born. And agility can be seen as the core tactic to react to those fundamental changes.

As a company, there is for sure the need to implement methods to organize, monitor and control the agile processes. But in some ways, agility will be accompanied by loss of control. That is unavoidable. And if we try to avoid every lose of control we will prevent agility as a direct effect.

Summarized there is a need for agility in every company to keep on the changed development speed required by digitalization. But not only the methods will drive this development process. Rather a mind change has to be triggered, to enable all participants to take their part in the process.

1. Shifting responsibility

Maybe the tools, implemented in the right way, can trigger that change.

One idea of scrum is to shift responsibilities from supervisors to employees. From controlling to the operational level. This is the first major change to build an agile and responsible scrum team, taking an important part of the whole process. If the operational level doesn’t have the responsibility and the chance to change things, to improve the output by re-evaluating ideas, nobody will become that agile to improve the speed of any development process.

This means especially, to reduce the initial concept of any project or feature to the core of the idea. The operational level can fill those incomplete concepts with details. A concept at the planning stage is detailed enough when general feasibility is ensured. To catch up all details at the planning stage is a dream never fulfilled in the past and still a time-burner preventing us to get from planning to doing.

Particularly in companies where the domain is no plain technical domain, the operational level can be a cross-functional team consisting of experts in every aspect a project or feature requires.

Ideas and projects need margin to get finally ideated on the operational level with direct input from the client, partner or customer. Finally, if we separate the design thinking or product development process from the implementation stage we lose the greatest benefit agile organizational structures can provide.

In some way, classical project management with its proposal and approval mechanism works like an artificial wall abstracting the two aspects of the value chain.

2. Uhm, customer-centred?

When it comes to agile, we immediately speak about customer centred development or design thinking processes.

What? Why?

Accelerated services, immediate communication and short time-to-market changed the way customers interact with companies. This is the real driver behind this whole agile thing. This means as a direct consequence that every effort has to be based on that.

The need for the agile mindset is mostly driven by customer expectations

If the ideation process is separated from the implementation stage, we lose much time and the high value of immediate testing results when a project has to be set up, proposed and finally approved. At all, if we can fulfil customer needs, does this need any further approval process? In my personal opinion not in the case of strategical projects.

So maybe the whole process has to be changed in the following manner:

• The continuous feature flow is mainly triggered by customer needs
• company board decides and prioritizes topics
• The interrupt if necessary or opportune comes from the board or legal requirements
• Maybe an architecture team (domain and technical) rearranging features to deliver as much value as possible in short development cycles

The design thinking process, a continuous process of ideation, prototyping and testing against personas and users must be established through the whole stack of the value chain.

From product development with direct customer or business partner interaction through all layers deep into the implementation, where real implementations are tested and improved again in short cycles. Like a rollercoaster with two endless loops where wagons unsteady flow from the first looping to the second and out.

3. Integration of design thinking principles

Beside the disruptive changes described before, maybe it is possible to integrate the customer-centred view.

Although it is necessary to be clear. We are taking about strategical continuous efforts and doings. Legal requirements surely have to be treated in a different way! The second point to recognize is that agile is never about getting the same amount of work done faster, it is all about getting done the right things at the right time.

Scrum is not about getting the same amount of work done faster, it will help us to get the right things done at the right time!

If we are able to understand our strategic sales or service projects as rough topic-boundaries we are back in the game. The most important change from here is to realize that measurement of success has to follow the agile way. The greatest showstopper of the agile evolution in classical project management is to stay on old controlling and measurement principles.

If a project is defined (as is) through rough but still well-defined features, to be realized in a defined time, the possibility to directly interact with the stakeholders and to improve project subjects in a very flexible manner is limited by the need to fulfil project and personal goals.

If controlling no more measures the implementation degree itself but the stakeholder or customer satisfaction, we can implement real agile project development based on topics within classical team and organisation structures.

By then, the development process can, in fact, be customer centred. The negative consequences got dissolved and the project team can flexibly react to client needs. At this point, our strategical projects will become a bit more like continuous feature streams flexible realized as a direct reaction to customer needs.

Not the direct output of amount of code or the number of features realized, even not the measurable (code) quality should be the indicator of project success. Only customer satisfaction matters within an agile design thinking driven development process!

4. Personal mind shift

Let’s face challenges for every person. What is necessary to be agile? What takes part in an agile working process.

• Avoid an emotional binding with your personal idea (not my favourite at all)
• Be responsible for every aspect
• Empathize with the client, no matter if college, supervisor, business partner or customer
• Understand that the one and only key attribute of the whole agile thing is that it everything can change every time
• Don’t rely on the stability of any plan
• Ahh, never fall in love with your personal idea!

Not to be misunderstood, change is not the goal of being agile. Accepting changes and further to welcome changes is the goal of being agile.

The acceptance of agile tools always starts with the employee. From top to bottom only general conditions can be set up. The important shift is a mind shift for every participant himself. This change process can’t be enforced at all. But how to gear it up?

And to be clear at this point, not every individual has equal agile capabilities!

In my personal opinion, a key task is the communication of the goals that should be reached by becoming agile. Accepting changes, in any manner is much easier when goals are well known. Concrete project-related goals are forbidden by the process itself. So soft goals must be defined and communicated! And the main goal will be company success in a faster changing world. In addition, employees have to feel comfortable. To facilitate employees to catch up responsibility, consequences of failing have to be reduced.

Last but not least it should be avoided to enforce methods and tools. Especially, the concrete practice of any agile tool should not be controlled and enforced in every way. Sure, the company may enforce the usage of a tool like Jira. But that’s not the point. An important key advantage of the agile process is that every Team is able to build a tailored process to get the job done.

If daily standups are done using chairs or if a particular team loves drawing images on story cards, does not matter at all. Controlling requirements have to be fulfilled and as the one and only first class demand, the work has to be done. Agile working means a mind- and toolset ideated for efficiently reacting to changes. Not for performing daily rituals effectively.

Many times I heard of teams or members asking about the need for retrospectives and team meetings in general. But they are the place to build the own tailored custom agile process. The ruleset has to be as agile as the employees performing the process.

Retrospectives are the meetings where teams build their flexible tailored custom agile toolset.

There are just a few requirements for the process

• Every team member has to be committed to the current ruleset
• The progress must be as transparent as possible
• There has to be space for continuous changing workloads
• Every team member must be responsible for the work and for each other

Scrum as a tool enables teams to meet these requirements. But the ruleset of scrum must be seen as a flexible recommendation.

5. Technical toolset

For everybody’s luck, modern tooling finally mostly builds on agile ideas.

Git for example. Maybe it never has been the Initial idea, but the branching concept and the own repositories ensure the possibility to test ideas and to delete ’em as well.

Test-driven development. The ideal environment for a continuous change process is tested to ensure functionality already realized.

Continous build and deployment pipelines finally are the consequent toolset to build fast value chains delivering products and ideas.

Finally, we experienced that swagger is the big deal. There is just a little learning step for domain related employees until they are able to use swagger to test functionality as early as possible within the development process. In fact, great UX starts with a great API.

6. Architecture

Much more interesting and much more difficult also is the definition of an optimal architecture.

To build highly configurable Systems seems to be a great solution as an enabler for flexible systems ready for iterable ideation and testing procedures. In fact, mostly they are complicated and the next important change is that disruptive that the value needed to be configured cannot be configured, for sure!

The value needed for configuring the next big idea, for sure is not configurable

The best guess is to realize some key requirements system-environments have to fulfil to provide best possible support for agile development processes.

• We need access to every type and kind of data from every domain entity related to our customer. This requirement, on the one hand, relates to the need for transparency and on the other hand on the need for individual products and services. Exactly these rough features are highly demanded opportunities of a digital world.
• Deployment units must be small. The concrete size is not fixable, at all, in my opinion. But if you have a deployment unit for every domain entity, maybe is a good sizing factor. Per technical entity sized systems and deployment units mostly will be too small. I’m consequently ignoring any sizing recommendation based on lines of code or something like that.
• Build and deployment pipelines within a highly flexible system environment can provide flexibility.
• A strong focus on process-oriented implementation strategies
• API first design in every software system! APIs are a fundamental abstraction layer for domain functionality in distributed architectures. But as an essential, maybe critical unit there is a need for rock solid API design. APIs have to be robust, solid client contracts or at least versioned. Documentation is a must and if REST is used semantical correctness should be ensured.

Based on my experience, I would suggest separation of server/service and client. Maybe some ideas even don’t need a client. But if there is an API there is an opportunity to integrate something somewhere.

BPMN as an expressional language to define stateful business processes interacting with highly distributed systems is an option to separate responsibilities.

Architectural patterns based on the general idea of a distributed system can support the agile performance through separation of concerns. But, in general, that is not a requirement to drive an agile development process.