Agility and 3.0 management in the technology environment: Surviving and innovating in an ever-evolving world
Volatility, uncertainties, complexity, and ambiguity — distinguishing features of the connected world we live in. In this scenario — reliant on the technological factor — we are less sure of what comes ahead and the paths our products, solutions, and problems will take.
How can we adapt to the speed of changes? How can we suggest an environment that breathes innovation? Are our traditional management practices (2.0) fit for the path we are going to take?
We live in an era that focuses on experiences. These experiences permeate our daily lives, whether in the things we consume or produce.
Solution and product providers that once imposed themselves and maintained the pioneering attitude in their solutions or their businesses’ soundness are now surrounded and threatened by smaller, lighter, and faster competitors. This speed of competitors is not only in delivering solutions but also in adapting to their consumers’ changes and needs.
This ability is connected to disruptive techniques and concepts that focus on collaboration, dissolution of hierarchy, diversity, low waste, and scalability.
The term Agility appeared in 2001, at a meeting between representatives of software delivery methodologies trying to find solutions for the fossilized method of traditional development (AGILE MANIFESTO, 2001), the Waterfall model (ROYCE; Managing the Development of Large Software Systems, 1970).
The Waterfall model consists of specific steps of the development process, working on them in isolation and with a closed scope.
In this model, the development moves sequentially through the phases. For example, requirements survey, analysis of requirements of the entire scope, design of the whole solution, development phase based on a survey — the scope does not change, phase of technical testing and conformity with the documentation created, and finally, the release implementation of the result. As a result of the immutability of the scope, we have extensive projects encompassing a grand solution. This model was considered functional in non-volatile times.
In times of significant changes, the model no longer makes sense because the results defined at the beginning of the process was once delivered for dynamic problems that changed frequently or were already solved, wasting time and investment.
Since this meeting, the central premises related to Agility appeared, and together they were called Agile Manifesto (AGILE MANIFESTO, 2001).
The manifest consists of the following values:
Unlike what many believe, Agility does not refer to the quick delivery of a solution but the speed of adaptation to changes. Always based on the manifesto’s values, the agile methods/methodologies prize smaller interaction cycles, with an open scope of the solution (mutable).
Ever-evolving requirements, development always in touch with the business and totally in line with the incremental strategies for products/solutions.
Each new cycle of interaction within agile methodologies/methods has as premise generating a potentially releasable increment, allowing for your product or feature to be tested by the market or in controlled environments.
This is indispensable to verify the solution’s adherence, learn from its data, correct flaws in the definition or solution, adapt to the environment, or even see that your solution is not fit for that problem. All of this can be seen during the solution’s embryo stage, minimizing the waste of time and financial resources.
Scrum, Kanban, and other agile methodologies
Some technologies may support the change in the use of the waterfall method and Agility’s adoption in the Information Technology environment. Among the methodologies, methods, and frameworks based on the agile principles, the most popular nowadays is Scrum.
Scrum is a framework for developing complex projects, which consist of reliable pillars (Transparency, Inspection, and Adaptation) and defined roles. The framework is calcified by a series of premises, with a minimum meeting and interaction times (timebox) to be respected. It works as a clock for the Scrum Team, setting the pace of the interactions’ deliveries.
As for Kaban, a method based on the Lean philosophy, its principle is to organize processes already used/defined by the organizations and set a pace and prioritize the delivery flows. The model was born for mass production companies and was adapted to meet the specificities related to software development.
Choosing to use one or the other jointly, or even with different agile approaches depends on each project, product, or organization. It must be based on how the organization works and on the feasibility of implementing the method.
Bear in mind that following a specific methodology/method/framework is not mandatory. Each organization or project may adopt its own, whether based on something that already exists, provided that the concepts, pillars, and values are present.
OKR (Objectives and Key-Results) is an agile management methodology for the flexibilization and control of goals.
In an increasingly volatile world, setting fixed long-term goals makes increasingly less sense since changing the course is a constant, which may often cancel a predefined plan.
The methodology is based on the concept of defining clear Objectives, defining where you want to go, and the tangible and measurable key results (KR) to be achieved. The methodology is based on premises such as the maximum number of objectives, the maximum number of KR per objective, that measure KRs in percentage, true/false on a scale of 0 to 1, and periodic reviews of the objectives defined.
Each OKR must have a quarterly cycle and period reviews every 1–2 weeks. In these reviews, the numbers corresponding to the KRs’ progress must be updated, points must be rectified, and strategies must be set.
At the end of the cycle, the OKRs defined are reviewed, and if the Objective has not yet been achieved but still makes sense, then a new cycle begins, and new KRs are determined based on the strategy created. This prevents goals from becoming obsolete and allows them to become tangible.
When we talk about management, we can divide history into three different approaches.
The first, usually called Management 1.0 or Taylorism, consists of managing people and organizations like machines, solidified into a strong hierarchy, high monitoring, repair, and replacement of parts (people). This concept was born with the Industrial Revolution, where a large portion of what was developed based on production lines with defined and repetitive tasks.
In this type of management, there is no room for innovation because people are left in the background, being mere executors of something predefined, with no room to think or give ideas to their superiors.
The second, primarily used nowadays, called Management 2.0, is based on the idea that people are not machines but valuable assets for the organization. It is based on the active work of managers as servant leaders for people. However, it still has a strong and vertical hierarchical structure. Most decisions are top-down (from the highest to the lowest level in the hierarchy), limiting peoples’ freedom to make decisions.
The third approach, Management 3.0, consists of a set of techniques and practices oriented to collaboration, focused on managing the system and not the people. It has six essential principles: Energize People, Empower Teams, Align Constraints, Develop Competence, Grow Structure, and Improve Everything (APPELO, J. Management 3.0, p. 370, 2010).
Its structure is based on making the organization like a community (holacracy). All the people involved are partly responsible for contributing to the success, and some are responsible for everything.
Thinking like this enables a horizontal view where everyone is interconnected and has the autonomy to make decisions, making the decision-making process fairer and more uniform. The picture below shows the representation of how people connect in this model.
Another crucial aspect of this management style is the incentive of experimentation. In traditional organizations, mistakes are treated as critical issues that must be avoided. But in an innovation-prone environment, we must think differently.
Each opportunity to experiment is an opportunity to learn, whether from the experiment’s success or failure. The relevant point is to learn as much as possible and as fast as possible from the mistakes.
Lean Startup is a methodology oriented to developing products, whether they are related to startups or not. The methodology is based on the Lean Production Model, also known as the Toyota Way (LIKER, Toyota Way; 2003), which combines organization and waste reduction principles aimed at the production.
The lean startup adapts these ideas to entrepreneurship, suggesting that entrepreneurs evaluate their progress differently from other business initiatives. (RIES, A Startup Enxuta, 2010)
The methodology is divided into three pillars: Vision, which focuses on the beginning, defining, learning, and experimenting; Direction, which consists of jumping, testing, measuring, and changing (pivoting) or keeping the direction; Acceleration, which focuses on growing, adapting, and innovating.
Going a little further into the Vision field, the main idea is to think about the product as an experiment, subject to failures. This enables an interaction based on learning, making it possible to know the product, the root of the problem that the solution will solve, and the audience.
Based on the definition of the view and its learning, it will be possible to direct your experiments, reduced to an MVP (Minimum Viable Product).
The MVP (Minimum Viable Product) concept consists of reducing a solution or product to its minimum acceptability level for release and tests.
Ries (A Startup Enxuta, 2010) defines it in its simplest form as: “a product version that allows for a full cycle of building-measuring-learning with minimum effort and the shortest development time.”
In the market, MVP’s mistaken concept is often used, being treated only as a fraction of something bigger, e.g. we may imagine that the desired product is a car, and the MVP would be delivering two wheels.
For us to have a successful MVP, it must be based on four important premises: it must be feasible, valuable, usable, and delightful (CAROLI, Lean Inception, 2018) Source: CAROLI, Lean Inception, 2018
Continuing with the example above, where the desired product is a car, the MVP could be a kick scooter with fewer features than a vehicle, less safety, and less speed, but has the minimum components to be used for the user to move around.
4.2 Measuring and learning
With a clear MVP concept and having finished building a lean product or solution, it is possible to make it available for the audience to use (whether in the form of a test or an actual release). The use must be supported by tools that enable the understanding and measurement of how the audience interacts with the product.
Based on the data generated by the solution’s use, jointly with the combination of feedback and interviews with users, it will be possible to define a strategy of continuity, evolution, or abandonment of the solution.
Learning from these inputs is crucial because they may contribute to the solution’s success. Still, more than that, they may help prevent the waste of resources (money, effort, and time) that may directly influence the perpetuation of your organization.
After all, what can we conclude?
Until now, we have presented the concepts of Agile Methodologies, the Lean Startup approach, and the Management Model 3.0, which is a disruptive model in contrast with the standard practices of the technology market.
But how can these concepts, methodologies, and methods ensure a better probability of survival and perpetuation of products, solutions, and organization in this increasingly less predictive future?
With the constant changes in opinions, needs, and desires, the growth and perpetuation projection can no longer be strictly linear. Instead, it must understand that there will be waves and cycles within the sinuous imaginary projection line that will determine the path to be followed.
Using the Lean Startup methodology, linear thinking begins to be left aside when the concepts of experimentation and learning come into play. The use of these concepts creates a wave of direct interaction with the consumer of your product or solution. This interaction will create inputs to validate or invalidate the path to be taken minimally. The organization will learn who it is, the audience to be approached, and how it reacts to what is being suggested.
If the path is invalidated, it is paramount that the destination point is reviewed and, if necessary, changed, a pivoting act that may ensure the non-waste of crucial resources, like time and money. If the path is validated, it is time to set the minimum viable level for this product to be released, its main features, indispensable functionalities, and the factor that will attract the consumer into using your service or product.
After defining the MVP, another wave begins, and its construction will require flexible enough tools so the learning cycle can continue to exist. At this point, agile methods are used to control and enable the flow of MVP deliveries and the constant evolution based on the product. The Agility will provide predictability for the delivery of construction cycles. If it is coherent, these cycles may be released incrementally to the product, giving more subsidies for your audience’s constant learning. Based on the understanding that Agility preaches that the product scope is mutable, the product will be shaped even more to the need or problem.
To set growth goals, whether, for the product or the organization itself, it is necessary to use methods that allow changes. Thus, the relevance of using OKRs to avoid leaving loose goals or goals no longer makes sense in the long term.
All this can be encompassed by using Management 3.0 practices to de-bureaucratize changes, empower people, manage the organizational system, and give enough freedom for the environment to become collaborative, prone to innovation, and so that the organization may have enough speed to keep up changing market.
The key to survival is knowing how to fail, knowing how to learn from failures, and adapting in the lightest, swift, and agile way possible. The use of the tools, concepts, and methodologies described are not guarantees of success, but they are a solid base to keep growing and evolving continuously and an adjustable base to mix up with other concepts.