A New Definition of Agility
Agility is becoming more and more popular. First, there was agile software development. Then came agile project management. And now we have agile general management, agile organizations, agile coaches, agile leadership and more.
In fact, everybody seems to be talking about agility, recommending it not only for software development but any type of organization. But different people have different ideas of what agility is:
Agility means that you are adaptable to the outside environment, and flexible on the inside.
Agile is when you have a flexible mindset and your team works at a fast pace.
Agility is when you do not develop the product before having gotten customer feedback.
Agility is when you work via Scrum in rapid sprints.
All of the above goes in the right direction, but nothing captures the whole aspect of agility. But if agility is so important, we should have a clear and understandable definition of it, which is exactly what we are going to build here. But first let’s look at the current definitions of agility.
1 The Current Definitions of Agility
While many people have their own definition of what they understand agility to be, there are several official definitions of it that unfortunately are neither precise, nor concise nor coherent enough to be useful.
The most popular definition are:
● Agile Manifesto containing values and principles
● Values and principles of Scrum
● Values and principles of Kanban
● Agile Organization definition of McKinsey
We will look at each definition below:
1.1 Definition by the Agile Manifesto
The agile manifesto defines the values and principles of agile software development, which are also adhered to by agile project management, and agility in general.
1.1.1 Agile Values
The 4 agile values of the agile manifesto are as follows:
● Individuals and interactions over processes and tools.
● Working software over comprehensive documentation.
● Customer collaboration over contract negotiation.
● Responding to change instead of following a set plan.
1.1.2 Agile Principles
The 12 agile principles of the agile manifesto are as follows:
- Deliver valuable work to satisfy the customer.
- Welcome changing requirements, even late in a project.
- Deliver software frequently in short intervals.
- Let business people and IT developers work together.
- Provide the team with a supporting environment and trust them to get the job done.
- Communicate face-to-face.
- Measure progress by the working software delivered.
- Create processes that promote sustainable efforts and maintain a constant pace of work.
- Continually seek excellence.
- Reduce the amount of work done by simplicity.
- Recognize that the best work emerges from self-organizing teams.
- Reflect at regular intervals on how to become more effective, and adjust behavior accordingly.
So there is no lack of definition of agility within the agile manifesto. However, these values and principles have the following problems:
● They are too extensive to be memorized: 4 values and 12 principles.
● Some principles are common best practices, and should be applied to any organization, independent of agility, so have no direct relationship to agility.
● Some principles only apply to software development.
● The list of values and principles lacks coherence.
The above drawbacks of the agile manifesto are not surprising, when we look at how it came into existence: 17 prominent software developers came together in the mountains to ski and have a good time. They represented the different viewpoints on software development such as Scrum, Extreme Programming and Feature-driven Development. As they were prominent figures with different opinions it must have been hard to agree on a common manifesto, which explains why it is so extensive, has conflicting principles, and is not coherent.
1.2 Definition of Values and Principles by Scrum
Scrum is together with Kanban the most popular agile methodology. An agile methodology is a set of rules to implement a work process that follows agility. That means that not every rule, value and principle of Scrum is required for the process to be agile. Nonetheless, the values and principles contained in the agile manifesto and in Scrum are overlapping to a large extent.
1.2.1 Values of Scrum
Scrum has 6 main values. 3 of the values -respect, openness and courage- are mainly related to empowered, agile teams:
Respect: We need to empower team members to be more agile and innovative. For this to happen every team member needs to be treated with respect.
Openness: In order to have empowered team members we also need to be transparent and open with information. Openness and transparency with the whole team leads to team members feeling that they are part of the decision and they are able to contribute to it.
Courage: As we want team members to contribute they need to have the courage to come forth with ideas, even with ideas that are challenging the status quo and might be disliked by others. Therefore courage is required.
2 of the values of Scrum -commitment and focus- are mainly related to agile development cycles.
Focus: In an agile development cycle we want to focus only on the things that we have put into the sprint. While the team is allowed to refocus at the end of the sprint, during the sprint it should remain focused on the items in the sprint backlog.
Commitment: Related to the focus we expect a commitment of the team to accomplish the items in the sprint backlog.
1.2.2 Principles of Scrum
Besides values, Scrum also has 6 guiding principles. 3 of theses principles -self-organization, collaboration and time boxing- are mainly related to empowered, agile teams:
Self-organization: It is focused on today’s workers, who deliver significantly greater value when self-organized. This results in better team buy-in and shared ownership, as well as an innovative and creative environment, which is more conducive for growth.
Collaboration: It is focused on the three core dimensions related to collaborative work: awareness, articulation, and appropriation. It also advocates project management as a shared value-creation process with teams working and interacting together to deliver the greatest value.
Time-boxing: It describes how time is considered a limiting constraint in Scrum, and is used to help effectively manage project planning and execution. Time-boxed elements in Scrum include sprints, daily Scrum meetings, sprint planning meetings, and sprint review meetings.
3 of the principles of Scrum -iterative development, value-based prioritization and empirical process control- are mainly related to empowered, agile teams:
Iterative Development: It emphasizes how to better manage changes and build products that satisfy customer needs.
Value-based Prioritization: It highlights the focus of Scrum to deliver maximum business value, from early on in the project and continuing throughout.
Empirical Process Control: It emphasizes the need to continuously examine the work process and the outcomes and do continuous adjustments.
The values and principles of Scrum are valuable additions to the values and principles of the Agile Manifesto. However, there are the following problems with these values and principles:
● They are too specific: For example, they mention “courage” and value-based prioritization, even though it is clearly possible to be agile without team members being courageous and without value-based prioritization.
● They are too extensive: 11 principles and values in total, thus they are hard to understand and memorize.
● They overlap with the agile manifesto, but both only explain part of the concept of agility.
1.3 Definition of Values and Principles by Kanban
Kanban is the second very popular agile methodology besides Scrum. It also has values and core principles.
1.3.1 Values of Kanban
There are 9 values of Kanban. These values are mostly related to agile teams, only “flow” relates to agile development cycles.
● Customer Focus: The Kanban methodology guides the optimization of the workflow in order to guarantee maximum customer satisfaction.
● Collaboration: Kanban encourages consistent improvement. Kanban guides to improve the way teams work together.
● Understanding: Kanban guides us to understand the working pattern within an organization.
● Transparency: The core strength of Kanban transparency comes from process visualization. Kanban teams enjoy the transparency at all the levels like status update, work visibility, decision-making process, and change of opportunities.
● Leadership: Kanban encourages leadership with the ability to inspire other team members for continuous improvement.
● Agreement: Everyone is committed to continuous improvement and agrees to move collaboratively towards the goals, but at the same time respects the differences of approach and opinion.
● Balance: The different viewpoints, capabilities, and aspects should be balanced to achieve the expected results.
● Respect: Kanban encourages respecting the current responsibilities and roles of individuals. By respecting the current roles of team members, it is easier to gain their willingness for the recommended changes.
The values of Kanban have a lot of overlap with the Scrum values:
● Respect is a value in both
● Transparency in Kanban equals openness in Scrum
● Leadership of the team in Kanban equals courage of the team in Scrum
● Agreement in Kanban is very similar to commitment in Scrum.
1.3.2 Principles of Kanban
Kanban also has 6 principles or Kanban practices:
● Visualize the work, so that everybody sees what everyone else is working on, as well as the status of each task.
● Limit work in progress, by focusing on first completing tasks that you have started before starting new tasks.
● Manage flow means paying attention to the workflow of tasks from “to-do” status to “progress” to “completed”. In particular you want to avoid too much work in progress as well as tasks that are being blocked.
● Make policies explicit, meaning being open and transparent with the whole team.
● Implement feedback loops means continuously paying attention to the results and making adjustments to achieve continuous improvement.
● Improve collaboratively means that the whole team should be involved in the noticing of things to improve and then doing adjustments.
The values and principles of Kanban are valuable additions to the values and principles of the Agile Manifesto and of Scrum. However, there are the following problems with these values and principles:
● Some are hard to measure and implement: For example, how do you measure and implement “balance”.
● They are too extensive: 15 principles and values in total, thus it is hard to understand and memorize.
● They overlap with the agile manifesto and Scrum but all only explain part of the concept of agility.
1.4 Definition of Agile Organizations by McKinsey
Agile organizations have been defined by the consulting firm McKinsey as organizations with the following elements, or trademarks:
● North star embodied across the organization
● Network of empowered teams
● Rapid decision and learning cycles
● Dynamic people model that ignites passion
● Next-generation enabling technology
The problems with this definition is that:
● The trademarks are very generic.
● The organizational-agility practices, the subcategories of trademarks, are too detailed and incoherent.
● Some of the practises do not make sense or are only empty words. For example, “performance orientation”, “hands on governance” or “sensing and seizing opportunities” are only empty words that do not give any prescription on how to become agile.
● Some of the trademarks and practices are not directly related to agility.
In conclusion, the McKinsey definition contains many impressive keywords that go in the direction of agility, but lacks a coherent framework for the definition of agility.
1.5 Streamlining the Definition of Agility
We can see that there are a lot of definitions of agility. In fact above we have seen more than 50 keywords associated with agility:
● Working software over comprehensive documentation
● Customer collaboration over contract negotiation
● Responding to change instead of following a set plan
● North star embodied across the organization
● Network of empowered teams
● Rapid decision and learning cycles,
● Dynamic people model that ignites passion
● Visualize the work
● Limit work in progress
● Implementing feedback loops,
● Customer focus,
● Transparency,
● etc.
While there are a lot of keywords, all of them lack a cohesive structure. We therefore need to combine the above elements and put them into a coherent definition of agility; a definition that meets the following requirements:
● Accurately defines agility.
● Has lesser elements, and therefore is easy to remember and understand.
● Applies not only to software development but to any process and organization.
● Maps to the existing definition of agile values, agile principles and agile organizations.
After reading the books of the creators of the agile manifesto, combining it with my knowledge from business school, and my 15 years of experience managing agile teams and consulting on agile transformation, I am convinced the best definition is the structure defined below:
● 2 main areas
○ 5 main components
■ 20 subcomponents
The final Agile Structure looks as follows:
2 The ECO FIT MERCI Model of Agility
The ECO FIT MERCI model stands for the 5 components that comprise the entire concept of agility.
We can see that 3 components are related to agile development cycles, and 2 components related to agile teams.
2.1 Agile Teams
● Empowerment [E]
● Constant Communication & Collaboration [CO]
2.2 Agile Development Cycles
● Frequent Iterations [FIT]
● Measuring Results [MER]
● Continuous Improvement [CI]
Agility is required to respond to a constantly changing environment by being more adaptable. This adaptability can be achieved by agile teams and agile development cycles, which have these components:
● Empowerment
● Constant Communication & Collaboration
● Frequent Iteration
● Measuring Results
● Continuous Improvements
We will now explain each component below!
3 Frequent Iteration [FIT]
3.1 Reason for this component
As the environment changes, we have to change internally. This change is too slow if we have long development cycles.
3.2 Elements of this component
“Frequent Iterations” has the following elements:
● Working in short work sprints
● Focus
● Recovery time
3.2.1 Rapid Sprints
Agile principles 1 and 3 state that we should work in quick iterations. Also, Scrum has as one of its core principles “iterative development”, which is called sprint. “Sprint” in common usage means running for a short period of time. This is different from a marathon where you run at a slower pace but for a long period of time.
Similarly, the objective of a work sprint is not to get very far over a long period of time, but get the maximum output within a short period of time. Thus a common sprint length is between one week and one month.
3.2.2 Focus
Focus is one of the values of Scrum. It means that the team should only focus on items in the sprint backlog. Kanban has the similar principle of “Limit work in progress (WIP)”, which means that the tasks that are started but not completed should be limited and opened tasks should generally be finished before starting new tasks.
Focus is thus an important part of both Scrum and Kanban. It is also inherent in the definition of iteration.
3.2.3 Recovery Time
A sprint would not be a sprint if you start the next sprint at the same time you finish the first. Then it should not be called sprint but unsustainable, fast marathon, because sprints need recovery time in between the sprints. So the purpose of the sprint itself is to get the maximum amount of work done, while in the recovery time in between sprints you have other important objectives:
● Recharging the batteries of the team members
● Reviewing the results of the sprint (sprint review)
● Reflecting on what went well and what needs to be improved in the work process (sprint retrospective)
● Planning the next sprint
This recovery time needs to be seen as an integral part of the sprint and thus of fast iterations. Without it sprinting becomes unsustainable and there is no learning which is needed for experimentation and continuous improvement.
3.3 Consequences of this component
With frequent iterations we can respond to change quickly (Value of the Agile Manifesto). In fact, it allows us to get last minute changes in requirements (Principles 2 of the Agile Manifesto). It also enables faster feedback and thus learning cycles, which are core to an agile organization.
4 Measuring Results [MER]
4.1 Reason for this component
If you work in frequent iterations with the goal of being able to adjust to change quickly, you also need to measure the result of the iteration in order to know how to adjust. In fact the better you measure, the better you know how to adjust.
4.2 Elements of this component
There are 4 main elements to measuring results:
● Requiring tangible work results
● Focussing on KPIs not vanity metrics
● Visualizing work
● Data driven decision making
4.2.1 Tangible Results
The agile manifesto mentioned working software, which represent tangible results, in principle 1 and principles 7 and as a value of the manifesto. This is thus an important part of the agility manifesto. However, the agile manifesto was limited to software development, while now the concept of agile is being applied to many other areas. Therefore, we have to be broader and ask not for working software but a tangible result.
In product industries this would be the product. In services industries it might be more difficult to define a tangible result. Nonetheless, every work has some kind of objective and outcome and the more tangible that outcome is and therefore the easier it is to show it to others, the better.
4.2.2 Focus on KPIs
In any business it is important to know the Key Performance Indicators (KPI) and to focus on those. This is even more important in organizations that have frequent iterations, because at the end of each iteration you get presented with new results that you can measure. If you measure those that are important, which are called the KPIs, and then make the necessary adjustments to improve further, you will become successful! But if you measure irrelevant things, you might make the wrong adjustments.
It is important to distinguish KPIs from vanity metrics, which are metrics that seem important but in fact are not. Examples of vanity metrics are website visitors that do not buy anything, while the real KPI is online sales. Similarly, if you are feeling proud about the many hours you worked, you are happy about a vanity metric because the real KPI is the work outcome, not the time you worked. Therefore, we have the principle 10 in the agile manifesto, which says ¨make things simple¨, which translates to work smarter rather than harder.
4.2.3 Visualize Work
Even thought the visualization of work is not mentioned in the agile manifesto, it is an important component of the two major agile methodologies, Kanban and Scrum. In Kanban visualization of the work is done on a Kanban board, while for Scrum it is done via a sprint backlog and a burndown chart.
Visualization of work goes a bit against the prescription of focusing on KPI and on tangible results, as work itself is neither tangible nor a KPI in itself. However, there are important reasons for work visualization:
● First, sometimes the results of work are not tangible or not a KPI. For example, researching the market, writing specifications, or answering customers questions, might neither be KPI nor tangible, but still be important.
● Second, the tangible outcome can only be obtained and looked at the end of the iteration. Even though sprints are short, and therefore delays minimal, it is still better to notice problems right away and not only at the end of the iteration. The work visualization allows every team member to see what is going on live and spot potential problems immediately.
4.2.4 Data Driven
The agile manifesto mentions that progress needs to be measured in working software, not in “only” data. However, it was written in 2001 when there was less data available and it was written for software development which has software as a clear tangible outcome. Therefore, for other areas of work and with the amount of data available in 2020, we need to add “data driven decisions” as an important principle.
As we said above, the frequent iterations allow us to frequently get results and reflect on them. Also, the constantly changing environment, which is the reason for agility in the first place, mandates that we constantly monitor data, specifically the KPI. Many times these KPI are in fact not tangible but in fact “just” data. This might even be the case for software. While it is true that a development team can show software at the end of the iteration, the KPI of their work should not be how well the software looks and works, but how well it achieves the business objectives, which could be measured in conversion rate or sales revenue, meaning data. Other important data might be profit, cost per click, email opening rates etc.
For these reasons we need to add data as an important KPI and need to make decisions based on it.
4.3 Consequences of this component
Each sprint or iteration gives you results. These results need to be measured, both in terms of the tangible product as well as in terms of the data. If you focus on the most important results, the Key Performance Indicators, then you can learn from each iteration and adjust to improve, continuous improvement.
Measuring results also means that you can do experimentations, and then use the learnings to find a product market fit, lean startup model.
Measuring results also allows you to have less micromanagement and instead have management by objectives, whereby you give more freedom and responsibility to the team and focus not on the way of working but only on the results. This means you can empower your team.
5 Continuous Improvements [CI]
5.1 Reason for this component
Every organization wants to improve, but this is hard if you have long development cycles. By having fast iterations along and measuring results at the end of each cycle you get the information which allows you to continuously adjust and improve.
5.2 Elements of this component
The main ways to achieve continuous improvement are by frequent iteration and continuously measuring results. Besides this the following elements are important:
● Self Reflection
● Experimentation
● Lean Startup
5.2.1 Self Reflection
Self reflection is mentioned in principle 12 of the agile manifesto. Also, in the Scrum principles we find ¨empirical process control¨ and in the Kanban principles ¨feedback loop, which both relates to self reflection.
Self reflection comes as a result of working in frequent iterations. Frequent iterations mean that there is a time of focused work but also a recovery time in between the iterations. This recovery time needs to be used to measure results but also to self-reflect on how the team is working, a process that Scrum calls sprint retrospect. This helps you to improve continuously.
5.2.2 Experimentation
At the end of an interaction or a sprint you get two benefits:
● an improvement in product (for example software, other tangible results, or even an intangible result , i.e. data)
● A learning
If the second benefit is very important to you, you need to do experimentation.
Experimentation is expensive when we are having long development cycles. For example, if we are working with a 30 week work marathon, we would definitely need more as a result of our work than just learning. We need a tangible result, as “just” learning would be too expensive. However, if we have fast sprints of one week we can use these sprints for experimentation.
These experiments will generate information that leads to learning, which in turn leads to a product market fit or to continuous improvement.
5.2.3 Lean Startup
It is often better to experiment first to learn something before executing the potential plan, especially if fast development cycles enable experimentation.
This is the main premise of the lean startup concept. In a startup, we might not know if what we are working on has product-market fit. For that reason, before we scale up, we have to learn, adjust and only scale up, once we are sure to have found a product-market fit.
In a rapidly changing environment the lean startup concept can make sense even for large corporations. But it is only possible with fast iterations that enable experimentation, which in turn enables learning that goes on to bring continuous improvements.
5.3 Consequences of this component
With measuring results, self reflection, experimentation and the lean startup concept we can achieve continuous improvement. Continuous improvement is especially important in an organization that is facing a rapidly changing environment, because if you are not improving continuously then in fact you are continually worsening.
6 Empowerment [E]
6.1 Reason for this component
With a rapidly changing environment, standard processes might not work or only work for a limited amount of time. In fact, standard processes can limit the required change inside the company necessary to deal with the outside changes. But if we have less processes, we need to have responsible and proactive team members to compensate for the absence of rules, which means we need to empower them. This means they have the drive and have the authority to do great work.
6.2 Elements of this component
● Objectives and Key Results (OKR)
● Self Organizing Teams
● Sustainable Work
● Coaching
6.2.1 Objectives and Key Results (OKR)
In order to get our team to be more responsible and proactive we cannot micromanage it but instead give broad responsibilities and check not the work process but only the results. This we can Management by Objectives. This form of management is also enabled by the fast development cycles, because at the end of the cycles we get results. And the frequency of the iterations means that we get results continuously.
Also, as we mentioned in “Measuring Results” we ensure that the results we measure are tangible and are the real KPI.
The Management by Objectives has been modified within the company Intel and after being called (Intel Management by Objective) it is now called OKR. This new model still has as its main message that the results count over the way how things are done, however it has several difference with Management by Objective which make it more suitable in an agile organization:
● Objectives are fixed by the team instead of the management
● Objective are made for short instead of long implementation cycles
● Objectives are transparent and can me measured by the whole team instead of the management having all the information and only it being able to see the accomplishment
For that reason Objectives and Key Results (OKR) are the better version of the traditional Management by Objectives to be used to empower teams.
6.2.2 Self Organizing Teams
If we want our organization to be ready for change and be innovative, then we have to:
● Encourage communication flow
● Work in fast iterations with continuous improvement, and
● Harness innovation from our team members
How? By working in small self organizing teams.
6.2.2.1 Why is it important?
If we encourage communication flow in a large organization people will quickly be overwhelmed by too much information, that will paralyze their work. However, in a small team the communication and information flow between members can be a lot but still manageable.
Also, teams that want to benefit from working in fast iterations have to frequently review results and gain learning experience from them. This experimentation and learning process is much easier in a small and self-organized team.
FInally, in small teams with a lot of responsibility, team members feel that their ideas are more heard which encourages innovation.
6.2.2.2 What it means?
Self organizing means that the team is responsible for many things that in traditional organizations are handled centrally, by specialized departments or the upper management. These responsibilities could be:
● Determining what to work on
● Determining work time and work location
● Determining communication channels
● Distributing responsibilities
● Hiring new team members
6.2.3 Sustainable work
Principle 8 of the agile manifesto is to ensure a sustainable work environment, which basically means “do not burn your team by overloading them with work”. Work overload is a danger in teams that work in frequent development cycles because by definition the deadlines are frequent and quickly approaching, leading potentially to continuous overwork.
While this kind of sprinting is OK to happen occasionally, it is important for any productive team to work sustainably, which could mean allowing sufficient off time as well as a work-life balance. While this is important for any team, it is particularly important for a team that is asked to do more than just execute as it should also learn and innovate.
6.2.4 Coaching
Coaching is a non-directive style of management, whereby managers instead of giving orders, instructions and advice (directive influence), rather ask questions, summarize and give opinions (non-directive influence).
According to Coaching workers do not reach their maximum level of engagement when receiving instructions and orders, but rather when they are following their own decisions. For that reason management does not need to give instructions and orders but rather listen and ask questions in order to further the insight of the workers.
The coaching style of management works well. In fact, a study by Harvard Business Review found that it was superior to 7 other styles of management.
The coaching style of management combines particularly well with management by objectives or the Objectives and Key Results (OKR).
6.3 Consequences of this component
If you are able to get people empowered, not only will you be more productive and innovative but you will also be able to quickly adjust to change. This is because an empowered team will proactive find innovative solutions to changing needs.
7 Constant Communication & Collaboration [CO]
7.1 Reason for this component
If the environment is constantly and rapidly changing then the information has to flow from the environment into the organization quickly and continuously. Also, information needs to flow within the organization, so that all parts of the organization are informed and the organization can adjust to the new environment.
7.2 Elements of this component
● Customer Orientation
● Small, Cross-functional Teams
● Transparency
● Technological Empowerment
● Fast Communication
● Non-interruptive Communication
7.2.1 Customer Orientation
In the values of the agile manifesto it says: “Customer collaboration over contract negotiation” and in the principles it says that late changes in software requirements are welcome. Also, customer focus is an explicit value of Kanban. This indicates that customer orientation is an important part of agility.
Customer orientation is important for any organization, even if not agile, as it is the customer that brings in the revenue. However, it is especially important for a company in a rapidly changing environment, as the customer is the source of information about changes in the environment and in particular changing customer needs.
Also, the frequent iterations allow for experimentation, which allows for the Lean Startup process, which has as its main component customer development. Customer development basically means experimenting with different customer propositions to find out what the customer wants the most.
Customer orientation should be seen broader than just a focus on the client paying the money. It should include suppliers, as these can also act as sources of information about changes in the environment, as well as other important stakeholders such as shareholders, legislators, and even the public at large.
7.2.2 Small, Cross-functional Teams
Not only is it important for an agile organization that information from the rapidly changing environment gets to the organization, but also that it gets distributed across all departments. Therefore, interdepartmental communication is important.
The problem is that information load in a rapidly changing and increasingly digitized environment is increasing exponentially. So if all available information were actually communicated to everyone in the organization, then teams would be overloaded and be paralyzsed in their work, which is the opposite of being agile. Therefore, it makes sense to work in small interdisciplinary teams. This solves two problems:
● information flows automatically between different departments (cross functional)
● information overload can be prevented (small team).
The small size is especially important, as the team in an agile organization should be empowered, or self-organizing. That means that less information flows from the top management to the team and more information moves between the team members. That means that each team member is not only a receiver of information but also a producer. So the larger the team the more danger we have of information overload.
The change in structure from a traditional, hierarchical, departmental organization towards cross-functional teams is illustrated nicely in this diagram from the McKinsey consulting firm:
7.2.3 Transparency
Transparency means making information available to people, even if you might feel more comfortable hiding it. While transparency is not mentioned in the agile manifesto, it is an underlying principle of both Kanban and Scrum. We already mentioned that both advice to make work status visual, by a Kanban board and a burndown chart, respectively. Also, Kanban has transparency as one of its 9 core values and Scrum lists openness, which is very similar to transparency, and as one of its values.
Transparency in practise means several things, including the following:
- Work should be visualized (for example in a Kanban board or a Scrum backlog).
- Any kind of information that could be relevant to the work should be shared with everyone (for example in the cloud).
- Top management should be transparent with the teams, even concerning negative information.
- The team should be transparent with each other.
While transparency is important for any organization, it is especially important for companies that are agile. First, as we said above, with a changing environment it is important that information gets quickly transmitted. Second, if we are empowering team members, giving them more responsibilities and letting them work in self-organizing teams, it is important that they are capable of making decisions by being able to access the right information at the time when they need it.
To have more transparency we can do the following:
● Create a culture of openness
● Make all the work visual, which if we want to have complete transparency means, letting everyone see what everyone else is working on, what time they are working on it, and the total amount of work.
● Sharing all files that any team member is working on in a common cloud based storage, e.g. Google Drive or Dropbox.
There are two problems with transparency:
● can easily lead to information overload
● can infringe on people’s privacy.
Both of these are valid concerns, but both can be mitigated by working in small teams. Small teams ensure that while you have to share intimate information, like what you are working on, when and how much total time you are working on it, you only have to do this with the small group of your team members. Also, cross-functional, self-organizing teams means that information and communication flow is focused on other team members, so by keeping the size small, we can reduce the information and communication load.
7.2.4 Technology empowerment
Technological empowerment is not mentioned within the agile manifesto, not by Scrum or Kanban, however, the McKinsey concept of an agile organization has technological empowerment as one of its elements, or trademarks.
In fact, technology is not required for an organization to be agile. A low-tech company can be just as agile as a high tech company. However, technology can support better communication and collaboration, which is why it is part of the element ¨Constant Communication and Collaboration¨. For example, Zoom and Skype can help to have frequent face to face meetings even when working remotely. Also, project management systems can help to visualize the work.
However it is important that technology does not become a burden that in fact can hinder agility. For example, in my own experience many times teams become frustrated by the need to use software that has a large overhead, which means that they have to spend a lot of time without getting actual work done.
7.2.5 Fast & frequent communication
As in the agile organization we are following fast and frequent iterations, we need to have a corresponding fast and frequent communication. This is important as:
● The environment is rapidly changing and therefore needs rapid adjustments
● We are working in short development cycles, and thus have to do fast planning and reviewing.
Fast communication in practice mainly means three things:
● High bandwidth communication
● Timeboxed meetings
● Bite-sized communication
7.2.5.1 High bandwidth communication
High bandwidth communication uses communication channels that are able to transmit a large amount of information. The order of bandwidth is as follows:
● Face-to-face meeting
● Video conference
● Phone call
● Chat and email message
● Documentation
The principle of high bandwidth communication in the agile manifesto, states that face to face communication are the best. This is true as far as it transmits the maximum amount of information per unit of time, and therefore is the fastest communication channel. However, nowadays, different from 2001 when the agile manifesto was written, video conferences represent a good alternative. Furthermore, we need to be careful of overcommunication as shown below.
7.2.5.2 Timeboxed meetings
Timeboxed meetings are meetings that have a specific time limitation, preferably short meetings. This is to prevent meetings from dragging on and thus prevent team members from getting actual work done.
Scrum prescribes several team meetings -sprint planning meetings, review and retrospect as well as daily standup- that all have a specific purpose and ensure frequent communication. However, the large number of meetings combined with the shortness of sprints, could easily lead to meetings becoming a large overhead. In order to avoid this overhead, meetings are supposed to be short and timeboxed.
7.2.5.3 Bite-sized communication
Bite-sized communication means that every communication needs to be as concise as possible. This becomes necessary due to the high frequency of communication within agile organizations. While every communication transmits information, it also takes time to communicate for both the sender as well as the receiver. So, if we expect people to communicate frequently this can easily lead to communication overload, which is one of the most frequently mentioned reasons for wasting time in organizations.
This communication overload often manifests in too long meetings and too much email communication. In order to reduce communication overload, but at the same time ensure frequent communication, communication has to be bite-sized, meaning as concise as possible.
7.2.6 Non-interruptive communication
● Asynchronous communication
● Culture of quick response
● Few communication channels
Non-interruptive communication is not mentioned by the agile manifesto, nor by Scrum or Kanban but it is an important part of making an organization agile. This is despite the fact that non-interruptive communication actually goes against the principle of constant communication, because we are in fact trying to limit communication and information overload.
This principle of non-interruptive communication is nonetheless important because information and communication overload is one of the frequent reasons for teams feeling paralyzed and overworked without getting actual work done. This situation has increased over the last 2 decades, as one the one hand the need for communication has increased and on the other hand communication channels have become digitized.
Non-interruptive communication is important for any kind of organization, but especially for an agile one that tries to foster more communication and collaboration.
7.2.6.1 Asynchronous communication
One element of non-interruptive communication is an asynchronized one. Asynchronized communication means that the sender can start a communication without interrupting the receiver and the receiver can respond when it is convenient for them. For example, you send an email and I open and respond to the email several hours later.
In contrast, synchronous communication is when you send a message and the recipient processes the information and responds immediately. In-person communication, like meetings, are examples of purely synchronous communication. You say something, I receive the information as you say it, and respond to the information right away.
This is a problem with constant communication and collaboration. According to the Harvard Business Review article “Collaborative Overload”, the time employees spend on collaboration has increased by 50% over the past two decades. Researchers found it was not uncommon for workers to spend a full 80% of their workdays communicating with colleagues in the form of email (on which workers’ spend an average of six hours a day); meetings (which fill up 15 percent of a company’s time, on average); and more recently instant messaging apps (the average Slack user sends an average of 200 messages a day). This limits productivity! Asynchronized communication ensures that the actual work of team members is not interrupted by constant communication flow.
7.2.6.2 Culture of quick response
In order to have effective asynchronous communication we need to have a culture of quick response. That means that each team member should be expected to respond within a certain timeframe, for example 24 hours.
If this culture does not exist the team will start to use synchronous or interruptive communication channels to get an immediate response, which will lead to communication overload.
7.2.6.3 Few communication channels
Finally it is important to limit the number of communication channels. Over the last decade communication channels have prolivered. Nowadays workers often use all of the channels below:
● Face-to-face meetings
● LinkedIn, Facebook and other social networks
● WhatsApp, Slack and other chat messaging systems
● Asana, Trello and other project management systems
● Zoom, Skype and other video conferences
● Proprietary communication channels of the organization
While all of the above communication channels can work, it is important that the team limits the communication channels in use to a minimum to avoid communication overload.
7.3 Consequences of this component
Constant communication and collaboration is the most extensive component of the ECO FIT MERCI model with 6 elements. This shows that it is an important component. It serves to on the one hand get information from the environment, particularly the customer, into the organization, and also to make sure that this information gets distributed quickly inside the organization. Also, it serves to empower the frequent iterations of a small, empowered team.
8 The overall ECO FIT MERCI Model
Combining all components to one framework it looks like this:
What is the importance of the ECOFIT MERCI framework?
The framework solves the problem of many people having different understandings of agility. This difference is due to the fact the agility had till now been defined by many different sources and each source only focusing on a few components or giving many unrelated components. The ECO FIT MERCI framework only has two major components that have 2 and 3 subcomponents respectively each containing further 3–6 subcomponents.
Also, it solves the question of “How?”. People often ask how do we achieve agility? Answer: “You need both agile teams and agile development cycles”. How do we achieve agile development cycles? Answer: “ You need Frequent iterations, continuous improvements and measure results.”
It also solves the question of “Why?? . People often ask, why do we need sustainable work? Why do we need self organizing teams? Answer: ¨In order to achieve empowerment of the team.¨
The ECO FIT MERCI Framework is useful to analyse organization using the 20 subcomponents as a checklist. It also helps to clearly identify the areas where work is needed and set the objective which components to turn agile first.
Finally, and most importantly it serves as a tool to arm agile evangelists with, so that they can explain what should the change be and why it is needed.
9 Mapping the ECO FIT MERCI model to other Definitions
Now, let us see how the ECO FIT MERCI model maps to the other definitions of agility.
9.1 Mapping of the Agile Manifesto Values to the ECO FIT MERCI model
Let’s see if we can map the 4 values of the agile manifesto to the ECO FIT MERCI model.
9.1.1 Individuals and interactions over processes and tools (Value 1)
Meaning: Processes are valuable when there is a constant environment, but when there is a rapidly changing environment they are less useful. If we reduce processes, we need to have more communication and empower team members.
Mapping to the 5 components model: Corresponds to AGILE TEAM, Empowerment.
9.1.2 Working software over comprehensive documentation (Value 2)
Meaning: Do not measure results of work in anything but desired outcome, which for software development is working software.
Mapping to the 5 components model: Corresponds to AGILE DEVELOPMENT CYCLE, Measuring Results and more specifically Tangible Results.
9.1.3 Customer collaboration over contract negotiation (Value 3)
Meaning: Do not have adversity between the person ordering the software and the person doing the implementation, instead communicate well.
Mapping to the 5 components model: Corresponds to AGILE TEAM, Constant Communication and specifically Customer Orientation.
9.1.4 Responding to change over following a plan (Value 4)
Meaning: Do not expect your plans to be valid for a long time but make frequent adjustments to the environment.
Mapping to the 5 components model: Corresponds to AGILE DEVELOPMENT CYCLE, Frequent Iterations.
Thus, we can see from the above that the values of the agile manifesto are mapped perfectly to the ECO FIT MERCI model.
9.2 Mapping of the Agile Manifesto Principles to the ECO FIT MERCI model
9.2.1 Satisfy the customer
Meaning: Customer happiness is priority.
Mapping to the 5 components model: Corresponds to AGILE TEAMS, and specifically Customer Orientation.
9.2.2 Welcome changing requirements, even late in a project
Meaning: Welcome frequent input from the client, helping you keep a close pulse of the changes in the environment and adjust frequently to those changes.
Mapping to the 5 components model: Corresponds to AGILE TEAM, Constant Communication, Customer Orientation.
9.2.3 Deliver software frequently in short intervals
Meaning: Do not wait too long for a new software release.
Mapping to the 5 components model: Corresponds to AGILE DEVELOPMENT CYCLE, Frequent Iteration.
9.2.4 Let business people and IT developers work together
Meaning: Very similar to the value of Customer collaboration over contract negotiation and also similar to the first principle of welcoming changing requirements, even late in a project.
Make sure you communicate to the business team, as they presumably know about the value of software.
Mapping to the 5 components model: Corresponds to AGILE TEAM, Constant Communication.
9.2.5 Provide the team with a supporting environment and trust them to get the job done
Meaning: Empower people.
Mapping to the 5 components model: Corresponds to AGILE TEAM, Empowerment.
9.2.6 Communicate face-to-face
Meaning: Communication is better in person, second best video call, third best call, fourth best email.
Mapping to the 5 components model: Corresponds to AGILE TEAM, Constant Communication, and specifically fast communication.
9.2.7 Measure progress by the working software develiered
Meaning: Focus on the desired result, software release or more broadly product release.
Mapping to the 5 components model: Corresponds to AGILE DEVELOPMENT CYCLE, Measuring Results.
9.2.8 Create processes that promote sustainable efforts and maintain a constant pace of work
Meaning: Do not put too much stress on development teams but let them get off time as well. It is not only important to work a lot but to work high quality.
Mapping to the 5 components model: Corresponds to AGILE TEAM, Empowerment, and specifically Sustainable Work.
9.2.9 Continually seek excellence
Meaning: Always try to make it better.
Mapping to the 5 components model: Corresponds to AGILE DEVELOPMENT CYCLE, Continuous Improvement.
9.2.10 Reduce the amount of work done by simplicity
Meaning: It is often possible to work less but achieve good results by making things simple, finding shortcuts or taking code libraries that have already been developed. In short: working smart rather than working hard. It means that the result is important, not the work.
Mapping to the 5 components model: Corresponds to AGILE DEVELOPMENT CYCLE, Measuring Results, and specifically Focus on KPI.
9.2.11 Recognize that the best work emerges from self-organized teams
Meaning: Self organizing are small teams that do not need much management. For them to work well, empowerment of the individual members and communication between them is important.
Mapping to the 5 components model: Corresponds to AGILE TEAM, Empowerment and specifically Self-organizing Teams.
9.2.12 Reflect at regular intervals on how to become more effective, and adjust behavior accordingly
Meaning: Reflect regularly who you can be more effective.
Mapping to the 5 components model: Corresponds to AGILE DEVELOPMENT CYCLE, Continuous Improvement, and specifically Self Reflection.
Thus, we can see from the above that principles of the agile manifesto are mapped perfectly to the ECO FIT MERCI model.
9.3 Mapping of the Scrum Values and Principles to the ECO FIT MERCI model
9.3.1 Mapping of Scrum Values
In the diagram above we see that the Scrum values map to the ECO FIT MERCI model almost perfectly:
● Focus is an element of frequent iterations.
● Openness is the same as transparency
● Respect to team members is a way to empower them.
● Courage of team members as a consequence of empowerment.
● Commitment is what you get at the beginning of a sprint, and the adherence is measured at the end using management by objectives.
9.3.2 Mapping of Scrum Principles
In the diagram above we see that the Scrum principles map to the ECO FIT MERCI model almost perfectly:
● Self-organization is part of empowerment.
● Collaboration is similar to constant communication and collaboration.
● Time-boxing is part of fast communication.
● Iterative development is the same as frequent iterations.
● Empirical process control is similar to continuous improvement, specifically self reflection.
9.4 Mapping of the Kanban Values and Principles to the ECO FIT MERCI model
9.4.1 Mapping of Kanban Values
In the diagram above we see that the Kanban values map to the ECO FIT MERCI model almost perfectly:
● Respect to team members is a way to empower them.
● Leadership is possible through empowerment specifically MBO and Self-organizing teams.
● Customer focus is customer orientation.
● Transparency is the same.
● Collaboration is similar to constant communication and collaboration.
● Flow in Kanban is similar to frequent iteration above.
● Agreement is a form of commitment on what needs to be done, which basically translates to focus.
9.4.2 Mapping of Kanban Principles
In the diagram above we see that the Kanban principles map to the ECO FIT MERCI model almost perfectly:
● Improve collaboratively, is similar to constant communication and collaboration but also contains the component of continuous improvement.
● Make policies explicit is similar to transparency.
● Manage flow is similar to frequent iterations.
● Limit work in progress is the Kanban version of focusing on a limited amount of tasks.
● Implement feedback loops basically means continuous improvements
● And visualize is equal to visualize work.
9.5 Mapping of the McKinsey Agile Organization model to the ECO FIT MERCI model
In the above image we can see that the McKinsey diagram of agile organizations maps almost perfectly to the ECO FIT MERCI model.
9.5.1 North Star embodied across the organization
Meaning: The team has to be empowered by giving it a clear vision towards which to work, instead of having many rules and processes.
Mapping: This maps to AGILE TEAMS, Empowerment and specifically Management by Objective.
9.5.2 Dynamic people model that ignites passion
Meaning: If we want the team to be agile and have less rules and processes we need to empower it and ignite its passion.
Mapping: This maps to AGILE TEAMS, Empowerment.
9.5.3 Network of empowered teams
Meaning: This basically refers to the organization not in traditional hierarchies but in small, cross-functional and self-organizing teams.
Mapping: This maps to AGILE TEAMS, Empowerment and specifically self organizing teams and Constant Communication and Collaboration, and specifically Cross-functional Teams.
9.5.4 Next-generation enabling technology
Meaning: Technology can help organizations be more agile.
Mapping: This maps to AGILE TEAMS, Constant Communication and Collaboration, and specifically Technological Empowerment.
9.5.5 Rapid decision and learning cycle
Meaning: We need to have frequent iteration and at the end of each cycle measure results in order to learn and constantly improve.
Mapping: This maps to AGILE DEVELOPMENT CYCLE.
Thus, we can see from the above that the McKinsey model of an agile organization is mapped perfectly to the ECO FIT MERCI model.
In fact, all of the above definitions:
● Agile Manifesto
● Scrum values and principles
● Kanban values and principles, and
● McKinsey agile organization
All map well to the all encompassing framework of agility described above, the ECO FIT Merci model.
Therefore, as people want to use agility and as agility becomes more important, we propose to switch the definition of agility to the ECO FIT MERCI model, which is more concise, more precise, applicable to any organization and work process and easily memorable and understandable.
In conclusion, agility is an important concept that potentially provides many benefits to various types of organizations. For the concept to be realized effectively it has to be fully understood with all its components. This understanding can be further with the ECO FIT MERCI model which provides a simple structure with all important components.
