Many companies want to make the agile transformation so that they can better organize their teams, in order to deliver more value and ensure more competitive advantage for the organization. However, throughout this movement of change, as we went through several companies with our consulting or assembles squads, we have identified some very common behaviors.
And we’ve resolved to bundle these top mistakes during an agile transformation, which are holding companies back from achieving results and getting the most benefit out of this process. Check out:
No short deliveries
Both in the transformation process (we perform the Agile Transformation process, in an Agile / incremental way – click here and learn more), as well as in the day-to-day of the teams that work in the development of the Product, it is essential to have short films delivered in order to be really agile. It is these deliveries, made with correct slicing and prioritization, that promote the inspection and adaptation mechanism – one of the main pillars of agility.
Think only about process and forget about Engineering
Another typical mistake we see within companies undergoing an agile transformation is to focus too much on the process and leave software engineering behind. To extract the maximum benefits from this journey of change, you need to pay attention to the quality of your engineering.
One of the items of the Agile Manifesto is precisely having a good software architecture and an adequate design to enable teams to have more shorter deliveries that can make Agility concepts be well used within the teams routine.
Do the mechanic and think it’s okay
Another failure that happens a lot is to think that the concepts and pillars of the Agile or Digital Transformation are just more processes and not giving the correct depth they have. It is not possible to have a traditional mindset (waterfall), using only some techniques or mechanical processes of the agile frameworks and achieving the estimated results. It takes a real mindset change!
Do you really want to change your organization’s mindset and have more engaged teams with more productivity? Click here and schedule a conversation with us.
Climbing too early
Still talking about depth, if you haven’t managed to make this transformation in a small cell within your company yet, don’t start scaling this initiative to the entire organization. This process of transformation, whether agile or digital, is based on a cultural change, a turning point in people’s thinking… And this change calls for the correct training to be carried out, the breaking of ties that exist in the daily lives of teams – that make them not have the necessary performance, among other characteristics, which take time to be modified. So it’s important to know the right time to start climbing!
Don’t measure and learn during transformation
The fifth mistake we most identify in companies during the agile transformation is not measuring and not learning along this process. Deliveries are being short, software engineering is getting the right attention, you’re putting agile principles into practice in the right way, you’re scaling at the right time, but do you have indicators for all of this?
You need to be data driven and use the data to measure theWhat’s happening. This will help you know if you are really delivering more value to the organization with these initiatives. Is the teams’ productivity higher? Is the number of impediments decreasing? Is lead time decreasing? Are users and customers satisfied with the product? These are some questions that need answers, data and analysis to help you measure and learn from this transformation process.
Low product and customer focus
When we talk about agile transformation, we have three main pillars: processes and/or management, engineering and product/customer. When you don’t focus properly on the product and the customer, you don’t have, for example, prioritization techniques and you don’t know what is really value and what is success for a project. You can work with any method, but if you don’t give proper attention to the product and its user, you are probably generating a lot of waste in developing this business.
Read more: You seem agile, but not focused on the Customer? You’re probably losing the game!
Finding that Agile is an end and not a means
The seventh mistake we see most in agile transformation processes practically consolidates all the previous failures, which is to think that Agile is an end and not a means. This is very common! During our consultations, we hear a lot of people say that they want to be more agile, they want to implement the Spotify model, etc… But what organizations should want is not these formats, but:
Get more results
Doing more with less
Increase Efficiency and Effectiveness
Competitive advantage
Making the technology area a protagonist within the organization
Delivering more value to the business
And, to achieve the above goals, Agility comes as a means! If for this you need to use other principles and concepts other than Agile, that’s fine. The important thing in this transformation initiative is to achieve the goals, that’s the end.
If you have identified some of these errors in your daily life and want to correct them, contact us. We can make this diagnosis in your company and help you to have more results!
Understand how it is possible to have more productivity and effective deliveries in any area of your company and make them more agile
Can I apply agility in any area of the company?
The answer is YES, but it depends on a few points.
Being agile today is no longer a feature of IT or Digital Products. Large organizations have several projects in all departments, which seek:
– Anticipation of the RoI
– Innovate more
– Improve existing processes
– Better meet the needs and objectives of the area
Projects today are surrounded by complexity and we can’t predict in advance everything we need to do to achieve our goals, nor how to make teams produce and communicate more.
Teams end up having different problems like:
Lots of external interference
Priority changes
Low visibility and transparencies
Many uncertainties regarding customer needs
The problem is not often with the professional – you have good people who work a lot (sometimes not so much), but, in the end, there is the feeling that something is stuck and that they have not been able to deliver what is necessary for the company.< /p>
Traditional management models through focused micromanagement people efficiency/productivity increasingly demand more and the results go nowhere.
In addition to the financial losses, this scenario directly impacts the team’s productivity and morale and this generates frustration for everyone involved.
Have you ever found yourself in this situation? If so, stay calm. There is indeed a light at the end of the tunnel.
We can rely on the scientific method for this and promote agility in any area of the company. By using an empirical process, we are able, through short cycles, to validate a hypothesis, learn from the feedbacks and adapt the plan if necessary.
When we talk about agility in any area of the company, we are actually talking about organizations that learn!
The first step is to provide transparency! We make it very clear:
which are objectives;
the flaws;
the action plan;
the next deliverables.
With transparency, we start short inspection and adaptation cycles.
This builds trust among all involved and paves the way for continuous improvement.
We often have a very good team, but without the tools to deliver more.
Agility provides the tools to support these teams to shine. Problems increasingly become visible and actions are taken to improve this.
In many cases we have problems with lack of focus, each person on the team has different goals, and in periods of close cycle each one starts looking exclusively at their goal and leaves the team in the background.
Through the Transparency, Inspection and Adaptation cycles we are able to understand what is happening and make the necessary adaptations
Often the organization itself creates these barriers that prevent the team from focusing on generating value.
On one of the projects I went through one of the directors said:
“No one in this company imagined we could do all of this in three months!” In this case it was a CRM initiative, no there were software developers, in the mamost were people from business areas such as marketing and sales.
The team had to learn to say no, we helped them set a clear, short-term goal and the whole team worked focused on that goal.
And you know the coolest thing about all this? The team worked at a sustainable pace, without the need for overtime.
Want to understand more about how this process works and how we can help you become an agile organization? Click here and get in touch!
We would be delighted to share more details in a chat.
A hug!
Considered one of the 15 emerging professions in 2020 in Brazil – according to a study published by LinkedIn, o Agile, or Agile Coach, or Scrum Master, or Agile Master, or Agile Expert, among other names given to the role of the Specialist in Agility, it’s one of the fastest growing jobs in recent times… But, you know how Agile’s journey is, its development and /or growth in this career? Or what is the lifecycle of this role within a team?
It was with this in mind that we, Ricardo Avigro and Fabricio Pequeno, decided to write this article! The idea of the Agile Journey was not meant to be a definitive journey, it was conceived from the moment in which a recurrent behavior in agile teams was noticeable.
It also doesn’t mean that following this journey, you will achieve absolute success. This path defends that the agilist has a life cycle to fulfill within a team and exposes some important milestones, which we must pay attention to before demanding maturity and self-organization from people.
Think about how, at any time, when talking to agile practitioners, you came across doubts about “how successful is this role?”. The role of Agilista has always left very vague how you can do things and how much you can do them…. We are not here to limit your creativity, nor your work, nor your background, but it is very important that we have a way to go. And, with that, this journey was born, one among many others that can be a good path to be taken.
… Now let’s get down to business, the Agile Journey
Lots of things happening, rushing, partial deliveries, activities entering the middle of the sprint, develops in this sprint and in the other forehead, “daily, why is this?” there is nothing positive”, but, in general, the team is doing well, delivers and is self-organizing to carry out its activities.
Did you identify any coincidence with something mentioned? Well, we’ve already been through some situations like this, and then we thought: “What to do? Where do I start? How to act?”. With this in mind, we mapped what we call “Agilista’s Journey”, based on our experiences that worked.
Step 1 – UNDERSTANDING
I arrived on a team, now what? We understand that it is necessary to read the environment. OK! You’ve read it everywhere, so here we go… How to read this or what we call it, “Understanding”, which is divided into four steps:
1 – Understand who your team is, who the people are, talk to each one and listen to their challenges, their moment and their difficulties, without judgment! Understand the technical profile too, this is very important. You don’t need to go into code detail, but it’s good to know minimally;
2 – Analyze the current workflow. Some teams think there’s a workflow when it’s actually a go horse in disguise and, in the madness of everyday life, they can’t see how much rework they generate for themselves. Also look at the constraints, as many companies have processes that stem from the traditional model and sometimes we need to live with that for a while.
3 – Understand the product backlog and its prioritization. Yes, the Agilista can help the Product Owner with the backlog, question the prioritizations and help generate more value in deliveries, and this directly influences the next point.
4 – Know the purpose of the team. A team with no purpose becomes a task team, a software factory and that discourages people.
There is no time or order for all this analysis, we put it that way because they were the points that we thought were the most important and that provided the basis for the next action.
Step 2 – ACTIONS
After you have all this understanding, comes the most challenging moment and it can be contradictory with some literatures, but, it is time to “ACT”!
Identify the problems, put together a proposal and present it to the company hierarchy – it is very important to always be aligned with your superiors.
Present this proposal to the team and seek allies to implement this plan. Although many say otherwise and in agility we preach that changes are part of it, people tend to resist them, so the more allies you have, the better for the implementation of the proposal.
Make this proposal visible to everyone, share the development journey, work agreements and whatever else you think is necessary.
One of the most difficult and crucial points of this step is identifying the saboteurs. Not everyone is prepared for change for whatever reason – and yes, saboteurs do exist and we have to deal with them. Like? Eliminate them!
A saboteur will not always be a person, sometimes it can be a not very intelligent process that generates waste, but in general they are people, and they can be people from the team, from other teams that we depend on or even a suspicious and centralizing manager.
This is the trickiest part, as we haven’t read it (at least I’ve never read it directly). But, in practice, the saboteur has become an impediment to improving the team’s workflow, proposal implementation, and/or daily life. And speaking of impediment, we agilists remove like no one else!
For each type of saboteur, we have an action type to take:
One Person on the Team: I’ve read that the team must or may not allow a certain person there and, as agile players, we only act when the team signals. However, sometimes the team does not have the maturity for this or has not yet realized that a certain person is a saboteur. Therefore, you Agilista, yes, yourself, must put on your “general” coat and order the saboteur to be removed from the team. (The way to do this will depend on the autonomy you will have within the organization, but you should report the case to the person’s direct manager for the action to be taken. Remembering that you should always have examples of the situations that led you to make this decision and after feedbacks with this “saboteur”.)
Centralizing manager: The ideal is to understand and minimize the fear or insecurity he has about the work, whether it’s lack of visibility, thinking that the team does a lot of meetings and “coda” little, thinking that the lack of a schedule impairs the vision, so the ideal is to understand and remove this “saboteur”, because even unconsciously or indirectly these attitudes hinder the flow and consequently the deliveries.
What we mean here is that, regardless of what or who is in the way, the flow progress and established proposal must be removed.
Another important point is to always encourage the team to take actions that guarantee the flow of the development journey, once established, it must be fulfilled. Always consider refinements and have dependencies mapped. They will be extremely important for team engagement in relation to Quality and Delivery – these are things that cannot be negotiated and one cannot go without the other.
At this point we will enter next – which is also controversial, as many say that the Product area is not part of the role of the Agilista, but, in practice, how we work together with the person who energizes the role of Product Owner< /em>, it is very important to guide and help. And how can we do this?
First, ensure that the backlog is clear, available and understood by the team, and then by the entire company.
Next, we must also make it transparent to all team deliveries.
Step 3 – SPREADS
Having the visibility of the team’s backlog and deliverables, we began to understand and question whether these deliverables are aligned with the purpose of the product. And, for this to be possible, we need to understand and get to know our client, looking through the eyes of UX and UI, to learn about your journey and your experience using this product.
At this point, it is very important that you and the person acting as PO stay close to the role of Designer and the Product Area specialist. In fact, this partnership is essential at all stages and, taking all this understanding to the team so that they can participate in strategic decisions, brings a sense of “owner of the product”, and you will see that this will make all the difference.
Finally, always thinking about visibility, we created a panel in which it is possible to show all product deliveries, focused on user experiences, regardless of teams.
Literature vs. Reality
Some literatures provide models of what we should follow, events with sequences in which, regardless of whether they are effective or not, they are important to do. We don’t think this is wrong, the point is that few times we’ve seen an orientation really focused on the Agile in all this….
It is understood that the Agilista must know how to behave and that the evolution of the team will happen perfectly as described from the proposed situations. The understanding of cycles is often applied to products and to the maturity of the team, but it is not applied to the evolution of the Agilista from the perspective of progress of the team as a whole.
Our proposal is to make everyone aware that there is a life cycle for the performance of the Agilista within a team and that this cycle, from its completeness, does not indicate that one should have a promotion, but a success criterion, aiming career direction. Thus, we can look for another team in which our performance will have more expressive results – aiming at maturity as a whole in a company.
These were some of the actions we took and made us achieve success in the projects we operate. Of course, we don’t always get it right and here we only tell you what worked…
Leave in the comments if you’ve been through something like this and how much this journey applies to your reality. Thanks, until next time!
Understand how the focus on the user and their journey should be the central point of development for a successful digital product
By Antonio Costa
Many companies that are in the Transformation process, whether Digital or Agile, are making a very serious mistake in their Product Development wake. There is a strong focus on the Product and a low focus on the Customer. This makes the organization even have more organized and faster deliveries, but still ineffective.
And do you know why this happens? Sometimes the company has a big focus on making money and doesn’t realize that if it pays more attention to the customer’s pain and tackles those pains in a more organized way, the profit follows.
For this, there needs to be a change in thinking, which we call here “Focus on Products to Focus on Journey and Customer”. I’ll explain better what this concept consists of.
Product Focus
It is when an organization looks only at its product, forgetting its customer – the product comes first. It may even have an agile team or agile practices, but probably the predominant thinking will be traditional thinking, which makes the team seek operational efficiency. Companies focused on excessive efficiency, or with a great focus on the product, have some characteristics, such as:
Begin analysis for product or feature creation, by internal systems – the internal system will shape the solution;
Focus on closing requirements, getting everything detailed;
Business and IT areas still working separately, where there is not great trust between them;
Development teams looking only at their delivery, looking to deliver more tasks;
Malignment of channels, as the focus is on efficiency, one channel does not need to wait for the other;
Great focus on team productivity;
Changes to requirements are not welcome;
Focus on releasing new features, without measuring what already exists;
Delivering the product is more important than the quality of what is already done.
This list can be extensive and a new text would fit here to enumerate more features and even detail them…. However, let’s talk about what really matters: the correct model – Focus on the Journey and on the Client.
Focus on Journey and Client
When a team focuses on the journey and the customer, it means the end user is REALLY at the center of all product development. Understand a little better about the characteristics of this team:
It starts with the customer’s need to define the viable solution;
The journey of users and personas is clear;
Business and IT areas working together daily in a collaborative way;
Teams orchestrating deliveries, with a focus on value;
Equal experiences in all channels (omnichannel);
Short cycles for collecting feedback from customers;
Analysis based on customer data;
Opening for scope change;
Focus on the customer as well as their emotions;
Company goals focused on business or customer, not project delivery goals;
Great concern with product quality (because if you launch something that doesn’t work right, nothing will add to the customer;
concern about measuring used and unused features and simplifying features – rather than releasing more new stuff;
This list doesn’t end here either, but it contains the main points we see in the market. The big change, in general terms, is to be concerned with the customer’s experience, in their journey using that digital product.
Exercise
Having seen the points above, I suggest you go back to these lists and reflect: “How many items above can you identify in your team? Are they working with customer focus or more product focus?”
I also suggest you put yourself in the customer’s shoes, but in the following way, for a moment:
Remember a service or product you recently consumed that provided a very unpleasant experience for you… Remember before you go.
What did you feel? Anger, impotence? Did you think or speak ill of this brand? What was your attitude?
Now ask yourself: could the product you are creating be generating these same feelings in your user? Could he be complaining about your brand or is he disappointed with the experience he had using this product?
Finally, keep in mind that the customer will consume your product not because you use Scrum or Kanban or any other agile method; not because you have legacy or disruptive technologies; the customer will buy your product or service, because it generates some benefit for him or solves a pain in his daily life.
And if you want to ask any questions or talk more about this subject, leave your comment here or contact us!
Initiating a transformation in a company, be it agile, digital or cultural, really is a very significant decision, considering the impact it has. Even though positive and with so many benefits, this journey of change still generates many questions in the minds of leaders. And so, let’s share some of the common questions about implementing an agile transformation that we’ve heard of lately.
“Is open scope a blank check?”
This is the first of six common questions when implementing an agile transformation, especially from IT managers: “Is open scope a blank check?” Agility is often confused with mess and lack of commitment to delivery goals. Therefore, the first way to mitigate this stigma is precisely to understand the purpose of what should be done.
Here’s one of the differences between features delivery and value delivery:
Another feature that is very important in the SCRUM is the delivery of value increment in each Sprint . A project that, every 14 days, has a software delivery running, generates much more transparency for the client.
By the way, another characteristic that should be taken into account when these doubts arise when implementing an agile transformation is transparency. A scoped project quickly introduces the typical blocks, that prevent software from going to production. Proceeding on these points in an honest and non-personified manner allows the stakeholders to act and resolve these blocks so that the whole project succeeds.
Finally, the development of a project can undergo several adaptations. Whether by changing the target of the project, some block or a change in the market. Open scope doesn’t hide behind a pre-defined contract, but engages customer and supplier around one goal: delivery in production.
“But what will I get?”
We talked a little about the differences between scope and value. Invariably, this value means software in production – and fast. Therefore, this second question arises, one that is very common among the common questions when implementing an agile transformation.
Agility offers this delivery of value in a very simple way. Purpose-engaged teams are able to make small deliveries in production, every time. And these small deliveries serve to keep the client and teams engaged, and give the possibility to prioritize next steps with “software in hand”.
So, small deliveries in production give the customer the comfort of knowing what is being done, at any time.
“How do I track the evolution of development?”
This is one of the questions we hear the most! Therefore, it is important to emphasize that the customer is part of the team, either as Product Owner or stakeholder. Therefore, the follow-up is automatic and fluid.
Therefore, the client is an integral part of the status report. He, like the rest of the team, is responsible for mitigating, adapting and publicizing on a daily basis.
It is worth mentioning the old PMO (Project Management Office) for closed scope projects. The traditional PMO charges and delivers a status report. And this status doesn’t usually show exactly what’s going on in the project.
“My boss won’t let me do this.”
This is another speech that is part of the common doubts when implementing an agile transformation. However, we believe this “boss” position is there for a very good reason. Or he spent many years in his company, climbing positions and conquering his space. Or he is very competent at what he does and was brought in to lead and solve problems in his organization.
In this situation, the ideal is to understand his motivations to stay in the traditional model. There are usually two big reasons:
– For multinationals, it can be a directive from the head office (although it is very infrequent);
– The company is used to “having someone to blame” if the project goes wrong.
In the first case, the most obvious way out is to start creating the culture of agility within the organization. And the Human Resources department can help you with that!
In the second scenario, we have a lot of real arguments that make Agility a good way out for the transition from the traditional model to deliveries with more sense and more added value.
“And what are my guarantees?”
The customer’s main guarantee is precisely the continuous delivery of value. We know that Agility exposes the facts quickly and the client is constantly informed – taking into account that the client is part of the project, as PO.
And then the question arises: “but if the software is not ready by date?”
We come across fatal dates all the time: Mother’s Day, Father’s Day, Christmas, brand launch, investment round, among others. The main tool to mitigate delivery is prioritization. Assessing what is most important, working in small delivery cycles, adapting at all times, focused on delivering the best product on the date… This is the best successful technique for us to meet that date!
“We are still very traditional and Agility is not for us.”
In addition to all these questions, finally, we still hear this statement a lot during the negotiation of a transformation as big as this one.
But, once again, it is necessary to understand that the world has changed. Not only because of the ignorance virus that causes COVID-19, but because of the professionals’ eagerness to be happier in their work, at all scales.
The Cartesian organizations (those “my boss orders and I execute”), is increasingly decaying.
Continuous deliveries make more and more sense in this VUCA world, in which we’ve talked a lot this article here.
Understand now the five bases necessary to succeed and competitive advantage in this Digital Transformation process
Every day we can see how the world is changing and how it is happening faster and faster. “We are on the cusp of a technological revolution that will fundamentally transform the way we live, work and interact. In its scale, scope and complexity, the transformation will be unlike anything human beings have experienced before,” said Klaus Schwab, Founder and Executive President of the World Economic Forum, on the unfathomable, ambiguous and open future of the Fourth Revolution Industrial.
In this scenario, Digital Transformation ended up becoming a new buzzword in the market, in which many say they make this journey of change, but few actually do it efficiently, with a holistic view of the subject.
It is noteworthy that some companies were born in the Digital age and in a Digital way, while other companies were born Traditional and are only now trying to migrate to a Digital world. With this, it is not uncommon to see people who have tried to transform traditional companies without success, break away from these corporations and create a new company, now with the digital culture ingrained, since its birth.
Therefore, we currently classify companies into two groups:
Companies that were born in the traditional way and are now trying to migrate;
Companies that were born with digital culture.
As we have already explained more deeply in a another text here on the blog, we mean by Digital Transformation as a fundamental change in the way the company is organized, using technology, people, processes and business models, in order to be adapted to the a more complex and dynamic universe, where it is essential to focus on generating customer value. This will be decisive in the life of companies: the more digital mindset the organization has, the greater competitive advantage in the market it will have in this new world VUCA.
For this change to happen, that is, for the company to leave Traditional and become more Digital, we at Agile.Inc created a model that helps in this migration process. This concept was developed by our team after many studies and daily practice.
So we have five pillars for a correct Digital Transformation:
Pillars for a correct Digital Transformation
CULTURE
The culture change is the first pillar for the true Digital Transformation to happen, not by chance. After all, it all boils down to a change of culture and mindset.
Among the various changes in culture, we can highlight:
Really put the customer at the center of your business;
Having a culture of applied innovation;
Empower teams, but with high alignment;
Create a culture of “not being afraid of failure” and
be more transparent in actions, decisions and plans
These are some examples of how cultural change is the primary point of transformation.
“You make a lot of mistakes along the way, but that’s okay. It’s okay to make mistakes as long as you learn from them. (My father and CEO) Vince has an expression: ‘It’s OK to make mistakes, but never make the same mistake twice.’”– Stephanie McMahon, WWE Brand Director during debate, 2018. – https:/ /www.istoedinheiro.com.br/confira-10-frases-inspiradoras-do-forum-economico-mundial-de-davos/
INTERNAL CAPACITIES
In addition to culture, companies need new internal capabilities, that is, teams need to have new skills to solve more complex problems.
Among these skills, we can highlight some such as:
Working with new technologies (Big Data, Blockchain, Machine Learning, among others);
Agility in product development,
Lean management in product design;
Use Design Strategically.
These are just a few examples of internal capabilities that need to be developed depending on the context of each business.
STRUCTURE AND GOVERNANCE
This pillar consists of rethinking the way the company is organized. Companies that are already digital organize themselves differently from traditional ones:
How are the areas of the company structured?
How to break the organization’s silos?
How is the budget defined?
How are initiatives prioritized?
How is work tracking done transparently?
How to create greater operational efficiency, for example with automation?
Again, these are some examples of questions that are addressed during this transition from Traditional companies to the Digital age, in terms of structure and governance, which vary greatly for each type of business.
PEOPLE
Having the right people, in the right places and with the right direction is critical. In this pillar of true Digital Transformation, we look at:
Roles and responsibilities (noting that, it’s no use just being defined, but must be followed and monitored in a natural way by everyone),
How is people’s motivation?
And which leadership model to apply.
As we think here at Agile.Inc – at the end of the day, it’s always people working with people to create products to other people.
But, unfortunately, we still see many companies treating people as resources, in a very “commoditized” way, in which it is enough to just hire employees from the consultancy that is cheaper,for example.
BUSINESS MODELS
The fifth pillar of Digital Transformation is to think of new business models for the VUCA world. The way people buy and consume services is changing and companies need to adapt as quickly as possible.
For example, the typical case of a bank that starts charging something without you seeing it and knowing it, is no longer accepted by everyone. If this happens, people will soon go to social networks or complaint sites to talk about it, creating problems for the institution’s image. Thus, new service models appear more frequently, such as Subscription, Freemium, OnDemand, among others, always aiming at the user experience.
The work then consists of developing these five pillars for a correct Digital Transformation in organizations. We feel that each company has one of the pillars more or less developed, or with the need to develop a pillar first, etc.
However, we strongly believe that some points are levers for transformation, meaning that not everything will happen at the same time. The levers are:
Developing leadership
Enabling teams
Applying Agility Concepts
If we start with these three points, everything else ends up being positively encouraged. Count on us in this transformation process – we increasingly want to bring true digital transformation to companies and people.
