Are you wary of Agile?

Over the past 20 years, I have observed that the success of agile software development is often impeded by several significant factors. One I consistently run into is the mix of employees and contractors within teams, which frequently complicates multi-skilling and the adaptaptive abilities of teams.

This situation is often worsened by conflicts between line management and product management, leading to misaligned priorities and resultant waste.

Additionally, I frequently experience a poor understanding of what “the product” everyone is working on actually is. Without a clear and unified vision of what delivers value to an organization and its stakeholders, teams struggle to deliver the desired value effectively.

Another big one is my recurrent observation that development organizations suffer critical dependencies on shared services, which become bottlenecks and slow down progress. Organizations often prefer to stick to the benefits of the economy of scale, thereby foregoing their adaptability and subsequent performance of the product organization.

A lot of the problems we run into have everything to do with the way we’re accustomed to solve problems, and the way we profess organization design in general.

These are just some examples of aspects of organizational design that I often see being overlooked when adopting frameworks for agile product development. In these adoptions the result is almost always a new organization (design) that is hardly more effective than it was before the adoption of these frameworks.

I spent most of my career as an agile specialist trying to understand such phenomena and what it is in Agile product development that causes these phenomena. As it turns out, it actually has very little to do with Agility itself. A lot of the problems we run into have everything to do with the way we’re accustomed to solve problems, and the way we profess organization design in general.

Reading and studying Creating Agile Organizations by Cesario Ramos and Ilia Pavlichenko was therefore an absolute eye opener. Instead of adding framework to framework, this body of knowledge boiles agility down to its essence, and explains what organizations need to become in order to attain that coveted ability: to outrun the competition by exploiting unpredictability.

Honestly, over the past few years I grew weary of seeing all the efforts of adopting agility go to waste by “pouring the same old whine in new barrels”. Luckily, “Creating Agile Organizations” has rekindled my enthusiasm for this field of work by teaching me what it takes to make new barrels.

So, are you weary or disappointed with the results of your agile efforts? I’d love to get in touch and see what I can do to rekindle your enthusiasm for actually making your organization Agile.

Jeroen Valkier

Jeroen Valkier

FiloGrant’s Agile Response to the Covid-19 Pandemic

FiloGrant provides and fulfills custom made financial services for entrepreneurs. These services consist of financial support for the development of business in the form of loans and grants to entrepreneurs. FiloGrant acts as contractor for MoneyWell. MoneyWell designs the financial services and pays FiloGrant for service development and provisioning. FiloGrant uses and develops a platform to publish and fulfill the services.

Fig. 1 Graphic showing the services provided by FiloGrant as commissioned by MoneyWell

The impact of covid-19

With the emergence of the Covid-19 pandemic MoneyWell decided to support businesses for the devastating effects that lockdowns and social distancing had on their revenue.

The desire of MoneyWell to compensate these businesses posed three key challenges for FiloGrant:

  • an increase in the rate at which MoneyWell requests FiloGrant for the fulfillment of new types of loans and grants
  • a tremendous increase of applications per loan or grant.
  • the need to get a new service delivered in weeks instead of months.

In this report, I share how MoneyWell used Agile organization design to deal with the challenges posed by the Covid-19 pandemic. I will assess the effectiveness of these measures in light of the principles described in Creating Agile Organizations (Ramos and Pavlichenko – 2022).

FiloGrant needed to provide Relief4All fast

To provide relief to entrepreneurs from the effects of lockdowns MoneyWell commissioned FiloGrant to provide a new financial service called Relief4All. The pressing circumstances demanded that Relief4All was to be published in weeks instead of months. This proved to be quite the challenge for FiloGrant. There were two main reasons for that. First, delivery times that were common for new financial services would be unacceptably long for Relief4All. Secondly, conflicting goals between two essential units within FiloGrant were causing ineffective performance for both.

In the following paragraphs, I will elaborate on these two main causes and how FiloGrant dealt with them

Long Delivery Times

The steps in the process of setup, development, publication and fulfillment of the financial services are shown in the graphic below. This process includes designing the fulfillment process and developing the software needed to support that process:

Fig. 2 Schematic showing the activities and actors in the process of setting up and fulfilling a financial service.

Under ideal circumstances, this process should go like:

  1. Design Service: a representative of MoneyWell contacts an account manager of FiloGrant to specify the need, terms and funds to FiloGrant.
  2. Choose Technical Platform: This account manager takes that information to FiloGrant and discusses it with information architects and analysts, who decide which of the key platforms to use to develop the software supporting the process of fulfilling the financial service.
  3. Design Fulfillment Process: With this choice made, developers work with the coordinator of a designated Fulfillment Team to work out the fulfilment process.
  4. Automate Fulfillment Process: The developers automate this process based on the process design.
  5. Add Marketing Content: work with marketing communications to ensure that the proper texts are used
  6. Review results: have the legal department, the fulfilment team and marketing communications do a review.
  7. Publish a service: the development team and marketing communication make the financial service known and available to entrepreneurs.

However, as you might have expected, this rarely happened.

The Reality Of Dependencies Between Teams

Unfortunately, this work was seldom done as sequentially as described above. Because each new financial service has its unique properties, developers had to regularly go back and forth between operations, legal and marketing communications to make sure they automated it correctly.

For example, when the designed process turned out to be legally non-compliant, developers had to redesign the process with operations, and they’d have Legal do a review again. Or when marketing texts didn’t match the terms of the service, changes to the process and the way it was automated might have new legal implications. This resulted in changes in the process, which resulted in changes in the software, which resulted in changes in texts. This led to endless loops and deadlocks due to these dependencies. What caused even more accidental complexity was the fact that developers, process coordinators, financial reviewers, project specialists, legal experts, and marketing copywriters were all part of different functional teams. These all had their own worklists, priorities and focus. The organization design assumed sequential dependencies between teams, but in reality, the dependencies were reciprocal.

Reciprocal dependency When it comes to dependencies between tasks, there are three kinds: pooled, sequential and reciprocal. Pooled dependencies (like sharing a resource) and sequential dependencies (one task needing the completion of another task) can be coordinated relatively easily by planning and coordination. Reciprocal dependencies (where tasks mutually require the output of other, like a surgeon and surgical assistant working together) however require twice as much coordination.

The Cost Of Reciprocal Dependencies

This complexity at FiloGrant can be understood in more detail by looking at the information exchange between each step in the process:

Fig. 3: The exchange of information between people performing the tasks required to set up and fulfill a financial service. Each arrow represents information coming out of a task and the subsequent feeding into another task required for fulfilling it. The dotted arrows indicate a relatively lower occurrence. Red arrows indicate a reciprocal exchange of information.

The tasks shown in Fig 3. were fulfilled by different departments:

 

 

Taskfulfilling Units
AMoneyWell + FiloGrant Account Management
BEnterprise Information Architecture
CDevelopment Teams + Fulfillment Teams
DDevelopment Teams
EMarketing Communications
FLegal + Fulfillment Teams + Marketing communication
GDevelopment Teams + Marketing communication
HFulfillment Teams

Table 1. Detailing which units perform the tasks depicted in Figure 3 

Due to the fact these people weren’t part of the same department or programme, people had different goals, different schedules and priorities, and because of that, a lot of time was spent coordinating and waiting on information. As a quick fix, the organization relied on special people to coordinate this information exchange needed for task fulfillment.

The result was super high coordination costs, goal conflicts and slow delivery. Half of the time it took to set up and publish a new financial service was spent on coordinating this flow of information between the people performing these tasks. This excessive coordination wasn’t just wasteful. It was also detrimental to the efficiency of the flow of work and caused tremendous personal stress for the people doing this work.

Making Sense Of The Situation

To understand what is going on, we can look at this complexity from a different perspective. When we display the tasks in a Design Structure Matrix, we notice that tasks C, D and F are dependent on each other in both directions: they are reciprocally dependent on each other.

Text

TASKS  ⇨
⇩

ABCDEFGH
A        
BX       
CXX X X  
D XX  X  
E   X    
F  XXX   
G     X  
H      X

Table 2. This DSM shows the task interdependencies for setting up and fulfilling a service. The black X’s indicate frequently occurring sequential interdependencies. The red X’s indicate frequently occurring reciprocal interdependencies between tasks.

Although the flow diagram in Figure 3 helps, we can spot the cause for the coordination more easily in a DSM. You can find the reciprocal dependencies as X’s in the upper right section of the quadrant. As the situation at FiloGrant demonstrated: if these tasks are not performed by a single department or team, coordination chaos ensues.

Luckily, the opposite is true as well. Following the 5th guideline of Creating Agile Organizations, containing reciprocal dependencies within a single unit can help lower these coordination costs.

Organizing Relief4All into a Product Group

The work to set up and publish a new financial service was spread over many different teams and departments (as shown in Fig. 3). Previous efforts to shorten delivery times failed because these units were only optimizing the performance of the separate tasks, rather than the delivery of the actual customer value: the financial service.

To remedy this for Relief4All, FiloGrant tried something else. First it was decided that the processes for Relief4All were to be developed on the UniPro Platform (one of the key platforms FiloGrant had at their disposal). Secondly, FiloGrant created a new unit by combining the responsibilities of the setup, publication and fulfillment of the Relief4All service into a product group. The product group’s purpose was to design and deliver this particular financial service from start to finish. It was staffed with all the people required to do the work shown in Fig. 3. This new unit was headed by a leadership team. This leadership team consisted of the manager for the National Grants department and the UniPro Programme Manager.

This resulted in a product group that was capable of setting its own course, and deciding on its own structure and processes. The Relief4All product group could rid itself of any work that wasn’t contributing to the delivery of the Relief4All service, and optimize its own working processes to get the service into the hands of the entrepreneurs as quickly as possible.

The creation of the Relief4All unit resembles the organization of a Product Group as described in the first guideline for Creating Agile Organizations: Organize into Product Groups. Looking from the outside in, the Relief4All service is the product as provided to the entrepreneurs. The people needed to design, set up, publish and fulfill this service were all included in the Relief4All unit, creating a semi independent unit with its own leadership.

Fig. 4: Showing the structure of FiloGrant after creating the Relief4All Product Group

This provided the Relief4All unit with a level of autonomy needed to create and adjust its own internal structure and processes. As a result this unit became more agile than the organization that contained it.

How Did FiloGrant Do This Redesign?

Looking at Figure 3 and Table 2 we can spot three reciprocal dependencies highlighted as red arrows and X’s between the following tasks:

  • Design fulfillment Process
  • Automate fulfillment Process
  • Validate Legal Validity

The dependencies between these tasks required the most coordination and were the cause of most of the delays. With the creation of the Relief4All Product Group the Leadership Team was able to set up a team that contained all these dependencies within a single unit.

Similar to the fifth guideline for Creating Agile Organizations, containing the reciprocal dependencies, the members of the team were now able to directly adjust their actions to achieve a common objective, without the need for a coordinator.

The increased dependency within the team (in contrast to outside of the team) led to minimal coordination cost, less delays, shorter feedback loops, more direct communication, less handoff of work, and more effective exchange of information between the team members. More importantly, the concepts of dependency within a team became silly as all team members were working towards the same goal at the same time; as a result collaboration improved and dependencies were handled as shared work.

Fig 5. Shows the organizational structure of the Relief4All unit. Red dotted lines show from which functional departments the Product Group was staffed.

Bypassing Account Management to increase learning

Looking at the creation and design of new service (activity A in Figure 3) we see a cooperation between MoneyWell and FiloGrant. At the side of FiloGrant, this task is performed by Account Management. The function of Account Management is to assess the need from MoneyWell’s perspective and help design a service that is operationally feasible at an acceptable cost. Although not common, it sometimes happened that either the demands of MoneyWell were unrealistic, or the needs of the customer were not represented sufficiently. In either case, this would lead to situations where the agreement made with MoneyWell was made to be more important than the actual customer value.

In any case, Account Management operated as the front-end, market facing part of FiloGrant and the rest of the organization as the output generating back-end of the organization. Both had their own local optimizations due to this functional setup.

According to Creating Agile Organizations it is clear that such a setup can get you into trouble rather quickly. The guideline that suggests to Group By Common Customer, recommends creating an organization in which units are grouped around a common customer, and contain all functions that are required to deliver value to this customer.

FiloGrant applied this guideline with a different approach, but with a similar outcome.

Instead of grouping two or more units by a common customer into a single unit (as described in the 6th guideline of Creating Agile Organizations), FiloGrant simply removed the need to group units by allowing Relief4All to bypass Account Management entirely. The separate front-end was effectively taken out of the organization for the Relief4All. This allowed a direct collaboration between MoneyWell and Relief4All. This opened up the possibility of weighing the objectives of the Relief4All services with the capabilities of the UniPro platform, and most importantly, its users. This saved both MoneyWell and FiloGrant a lot of time that would normally be wasted in expressing and resetting expectations of MoneyWell against the capabilities of FiloGrant and the UniPro platform.

Fig 6. Shows the direct cooperation of the Relief4All unit with MoneyWell on the design of Relief4All. The red cross indicates bypassing the structural account management at FiloGrant.

By engaging MoneyWell in the outcomes of the short feedback loops, the Relief4All unit was also able to decide and act on the new course of actions easily and directly. MoneyWell was able to adjust its demands on crucial details without the service losing its effectiveness based on what was feasible for FiloGrant to deliver on short notice. In turn, FiloGrant was able to (re)design the Relief4All unit in such a way that it met the needs of MoneyWell based on the feedback provided by MoneyWell and their customers.

Conflicting goals between the UniPro Programme and National Grants Department

As mentioned earlier, FiloGrant uses the UniPro platform to provide and fulfill Relief4All and other financial services. This platform is developed in house specifically for the financial services fulfilled by the National Grants Department. The platform was developed by the UniPro Programme. This was a unit separate from the National Grants Department. In that structure the UniPro Programme and the National Grants department strongly affected each other’s performance.

Fig 7. Showing the organizational structure of FiloGrant indicating coupling between two units.

In the structure above, the UniPro Programme is responsible for developing the software that automates the processes of publication and fulfillment of the financial services. The function of the Programme is to develop features from which as many financial services as possible can benefit. However, the function of the National Grants department is to optimize fulfillment and focus on operational excellence. The two units had competing goals which caused serious functional coupling resulting in significant effects on the service level.

Functional coupling When two units within an organization affect each other’s performance in fulfilling their purpose we call this functional coupling. Functional coupling is something we want to avoid when designing organizations, especially when it has a negative effect on the performance of at least one of the involved units. Functional coupling causes an organization to be less agile, when decisions or actions in one unit cause the other unit to lose performance. An example of functional coupling occurs when an organization has a unit responsible for quality assurance, and a separate unit responsible for product development. In this example Quality Assurance specifies company wide quality standards and processes. The Product Development unit develops and ships the product the company gets its revenue from. When the performance of the Quality Assurance unit is measured by the adherence of the Product Development unit applying their standards, and the Product Development unit by the number of paying users, one of them has to suffer. It’s either the Quality Assurance unit for not achieving their objectives because Product Development does not comply, or Product Development suffering missed opportunities due to unnecessary work done on irrelevant quality criteria and adherence to needless processes.

This functional coupling between the UniPro Programme and the National Grants Department meant that both suffered from suboptimal performance. Ultimately, neither of the two units were able to fulfill their purpose optimally.

Creating a leadership team to combine authority with responsibility

To make sure Relief4All wouldn’t suffer from this functional coupling, the leadership of Relief4All was shared between the manager of the UniPro Programme and the manager of the National Grants department. By creating this Leadership Team, the managers of the functionally coupled units, were now able to define a clear and dedicated function for Relief4All. By joining their responsibilities, and using their combined authorities they were fully capable to choose the right course of action, independent of other units. This leadership team reported directly to the responsible Director of the National Division of FiloGrant.

Fig 8. Showing the organization structure of FiloGrant with red lines indicating the leadership team for the Relief4All, made up of the managers of the UniPro Programme and the National Grants Department

As a result, this leadership team was able to design a process and structure that was optimal for the fulfillment of Relief4All, and also develop features that supported exactly and just that. For example, Relief4All generated an enormous demand from entrepreneurs resulting in thousands applications a day. The people assessing the applications were not able to process that many fast enough. The leadership team decided that the assessors had to focus on only those applications that were abnormal. The remaining applications were processed by an automated process without the intervention of a human. Combining their authority and responsibility allowed them to make this decision much faster and much more effectively then FiloGrant was able to originally.

First release within 4 weeks

Setting up Relief4All as a Product Group, bypassing Account Management, containing reciprocal dependencies in the development team, and creating a leadership team. The sum of all these changes in the organization for Relief4All had a significant outcome. Relief4All was able to publish the service and subsequent updates roughly twice as fast compared to any previously published service of comparable size. This resulted in the first release to entrepreneurs within 4 weeks after request by MoneyWell. Work continued with very short feedback loops of 1 week. The creation Relief4All unit proved to be successful.

Conclusion

FiloGrant created the Relief4All unit in response to the urgent need caused by the Covid-19 pandemic. The company made changes that resemble the CAO Guidelines 1, 3, 4, 5 and 6. This had the desired effect:

  • due to creating the Relief4All leadership team, and including all essential parts in the product group, there was no longer a need for coordination between the managers of the previously involved units (legal, market communication, enterprise information architecture);
  • the leadership team had full responsibility and authority to manage the performance of the Relief4All service, rather than its parts;
  • MoneyWell and FiloGrant engaged into a collaboration where real learning from the product and the way it was developed took place.
  • the people working in the new unit no longer experienced goal conflicts, because everyone had the same goals, priorities and focus: to set up, publish, and fulfill Relief4All.

In the end, MoneyWell was provided with what it needed for prompt publication of, and regular updates on the Relief4All service.

Faced with the challenges posed by MoneyWell, both the FiloGrant and the UniPro platform software proved “soft” enough to make the necessary changes. That being said, MoneyWell had quite a hand in that adaptability. It was raw urgency and pressure that MoneyWell exerted on FiloGrant that created the Relief4All unit within weeks without structural reorganization. Something that would not have been possible without this pressure.

This leaves to question what this means for the adaptability of FiloGrant without this externally applied pressure. In my next article, I will review the changes the organization UniPro Programme underwent and the effectiveness of trying to repeat the effects of the Relief4All unit to the broader portfolio of financial services FiloGrant provides.

Jeroen Valkier

Jeroen Valkier

Agility needs adaptability

When an organization decides to adopt the Agile values and principles, it can choose to adopt a framework providing roles, rules and events to achieve that. Practice shows however, that the mere application of these frameworks usually isn’t enough.

To actually reap the benefits, an Agile framework adoption should result in an organization that constantly knows about its current reality relative to the goals that organization has set itself. If it detects a gap between its goal and current reality, the organization needs to be able to understand that gap so that it can reassess what is the most important work to do in order to close that gap. If an organization can run this cycle of learning and adapting at a rate that is higher than its competitors, it will be able to outperform its competitors.

However, knowing that change is needed, and what needs to be worked on isn’t enough. The extent to which an organization is capable of constantly working on what is the most important work, and the time it needs to make any necessary shift of focus, determines the actual agility of an organization. If the cost of changing focus is too high, it might make the product or service itself too costly and become commercially unviable. Additionally, if it takes an organization too much time to make the shift in focus, it will either be undertaken too late or not at all. Either way, when this persists that (part of the) organization will eventually go out of business.

Ramos and Pavlicenko have described this concept in their book Creating Agile Organizations stating that an organization needs to be adaptable if it aims to be agile. Adaptability being the ability of an organization to be adapted to current needs. According to Ramos and Pavlicenko the ability of an organization to adapt depends on three key factors:

1. Minimization of switching costs

The costs involved with changing direction, or switching from one activity to another, are called switching costs. For example, these costs manifest themselves as the time needed for a group of people to develop a new skill, the deprecation of an investment made for a product feature that no longer fits a current market need, or the time it takes a ocean containership to to change it’s course once it has reached its cruising speed.

The higher these costs, the lower the ability of an organization to change its direction. High investment up front, into large commitments with the promise of benefit in the far future decreases the willingness or ability of an organization to abandon such a commitment. An organization would be wise to commit to lower investments, with a payoff as near in the future as possible, so that abandoning those investments generates a smaller loss. The cost of switching stays lower.

For example, shortening iterations (that result in done product increments) lowers the switching costs for an organization by lowering the investment made. This increases its ability to change direction.

2. Minimization of transaction costs

Transaction costs are the unavoidable costs involved by the recurring activities that are needed to do the work.
For example, such activities are the recurring meetings a management team has, or teams running their Retrospectives, the daily performance of a set of tests assuring the quality of software doesn’t regress, or the price of having an ocean shipping container sail between the shores of two continents. These activities do not generate value by itself, but enable or improve the work that does generate value. Transaction costs represent the fixed costs involved in doing the work.

Transaction costs that are too high can express themselves as “the investment not justifying the yield”. A good example of high transaction costs is the delivery of a feature that took half a day to develop, but needs days of manual regression tests before it can be deemed safe to release. Teams almost always choose to pool such releases with other features, so that the relative transaction cost per release goes down. This might seem economic, but it actually only prolongs the time it takes for an organization to get feedback on the change it made.

As a result, transaction costs make an organization less able to respond to change. It puts a limit to the minimization of switching costs, because lowering the switching costs by shortening the iterations (while transaction cost remain the same) will result in relatively higher transaction costs. Hence, lowering transaction costs is an economic requirement for a business to be adaptable.

3. Maximization of the rate at which an organization learns

And lastly, and perhaps a more familiar one: the rate at which an organization learns from experience. For an organization to thrive, this rate needs to be higher than that of the competitor. This is closely related to the frequency of evaluating the outcomes against expectations. In Scrum for example, this is called the inspect & adapt cycle and its frequency is inversely related to the length of the iterations (Sprints): the shorter the iteration, the more opportunity there is to learn.
The process from starting an iteration to getting the product in the hands of the user, and receiving feedback is a feedback loop. The longer this feedback loop takes, the longer it takes the organization to know the gap between its goals and reality, and the greater the uncertainty of the size of that gap. There will be less transparency, and learning will be less effective.
Hence, the shorter the feedback loop, the higher the rate at which an organization can learn and the smaller the uncertainty about the size of that gap.

How about your adaptability?

What about your own organization? It doesn’t matter what framework for Agile development your organization has adopted. If your switching and transaction costs haven’t been dealt with, it will keep you from learning faster than your competitors. You will reap zero benefit from the effort you’ve put into it.  It is worth looking around in your organization to see if you can spot high transaction costs preventing you from shortening your feedback loops, or whether there are high switching costs causing your response to change to be too late or completely absent. In my next posts I will provide some examples, how to spot them, and possible ways of how to deal with it.

Jeroen Valkier

Jeroen Valkier

To solve or to resolve

In my previous post I used a pump and bicycle to explain the importance of understanding a problem, before blaming the tool for failing to fix it.

Now imagine the same bicycle pump, and observe its parts: a metal cylinder, a metal rod, metal disk with rubber lining, a nozzle, a valve and a wooden bar.

All these parts are designed and aligned in such a way that the pump can fulfill its purpose: pushing air into the bicycle tire. All works well, until the pump ages over time and parts start to degrade. Metal rusts, rubber degrades and wood rots. All can cause the pump to lose its function; it can no longer fulfill its purpose. Chances are that you’ll notice its loss of function when pushing the wooden bar down. It no longer pushes back. And even worse, the tire isn’t inflating anymore. But the wooden handle is fine. And so is the metal rod that it is attached to. It’s still there. You instinctively know that replacing the handle or metal rod is not going to fix the problem. Upon closer inspection you find out that the rubber lining of the metal disc inside the cylinder has deteriorated and air that is no longer getting compressed. What we take for granted is that the problem manifested itself in a different place (at the wooden handle) then where we had to fix it (at the rubber lined metal disc). We don’t give it a second worth of thought. We’re wise enough to inspect the entire system and end up replacing the broken parts.

Now imagine a bit of an absurd situation where we take a much more local approach to fixing this problem with the bicycle pump. Let’s say the person experiencing the problem can think no further than the place where he experiences the problem: at the wooden handle. As a remedy the cyclist replaces the wooden handle. No improvement. At best, this leaves the performance of the pump unchanged. It doesn’t improve, but it doesn’t worsen either. When systems like the pump are simple and predictable in behavior you’ll run less of a chance of making things worse with fixes in the wrong place. Fortunately, we’re wiser than this, and look beyond the handle to fix the problem. You might be surprised though, that this wisdom doesn’t extrapolate to trying to fix problems in all kinds of systems.

Let’s make a jump to something a tad more challenging: organizations. Organizations are complex social systems made up of people and their interactions. An organization fulfills its purpose by organizing these people and their interactions in a way that it is most likely to do so. Because the “parts” of these systems are purposeful, the resulting organizations will  be purposeful as well. This causes such systems to be immensely more complex than something simple like a bicycle pump. Here, the effects of changes or fixes in the wrong place are equally more unpredictable as a result.

So you would expect people to apply the same wisdom in solving problems in an organization as we do in more simple systems: consider that the source of a problem might not be in the place where we experience it. Right? Helas. We usually don’t.

Unlike the systemic approach of solving the problem with the bicycle pump, we take a much more local approach to solving problems in organizations. For example, pressuring a team that is delivering features at a lower rate than expected, to just work harder, is like replacing the handle of a bicycle pump with a leaking valve and expect it to work again. Even if you’re not the kind of person that puts unnecessary pressure on teams, you’ve probably experienced fixes that backfired, or problems that became increasingly more difficult to fix over time, because you kept falling for what you thought was the quick fix. We do this, because we fail to understand that the symptom of a problem is not the same as the source of a problem.

“Over 90% of the problems that arise in organizations are better solved somewhere else than where they appear.” – Russel L. Ackoff

Dealing with problems in an organization requires a systemic approach. This means that you need to identify all parts of the system that are needed to fulfill the function that is broken. You need to find and understand its interactions, so that you can uncover the areas where the performance of one part negatively affects the performance of another, causing the system to lose its function. So it may seem that you’ve solved the problem, but if it’s in the wrong place, it will probably return bigger and uglier. If you succeed in finding the source of a problem, you have a better chance of actually resolving the problem: changing the system so that it is less probable to reoccur.

And this is where building an agile organization and systems thinking go hand in hand. You can inspect and adapt all you want, but if your adaptations are like replacing the pump handle, don’t bother inspecting at all. You’ll only make things worse.

Jeroen Valkier

Jeroen Valkier

Why even bother about Agile

Agile has been around for some thirty years now and there’s a good chance you’ve come across it in some way or another. There’s a good chance your organization has had a shot at applying it by using one of the many agile frameworks that have been developed.

In many cases it has become no more than a new way of working with little performance improvement to show for it. As a result, many organizations have tried and abandoned their shot at agility. So why even bother? Why should you bother with the agility of your organization when the benefits are either unclear or do not materialise? Is it just another fad that will pass in time…

You have probably seen it all come and go, and see some of it fail. Its failure might even have gone unnoticed to your organization.

To bother or not to bother, is that the question?

So you would expect people to apply the same wisdom in solving problems in an organization as we do in more simple systems: consider that the source of a problem might not be in the place where we experience it. Right? Helas. We usually don’t.

Asking yourself why you should bother about agile when the benefits don’t materialize, is like asking yourself why you should bother using a bicycle pump. You know why you’re using a bicycle pump. The benefits are obvious. And that is because you know it isn’t about the bicycle pump. You know that there’s something wrong with the tire. You don’t use the bicycle pump just because you’ve heard about how effective a tool it is. Using the pump is about riding your bicycle again.But what do you do when the pump doesn’t do the trick? You quickly conclude that there must be a reason the air keeps escaping. You probably won’t blame the pump for this. It’s blowing in the air allright. Instead, you end up fixing a leak in the inner tube of the tire. But what do you do when the same problem starts to recur over time? Will you blame the pump? Of Course not, because you know something must be causing the leaks right? As a result you might try changing your favorite route. ‘Cause hey, it might not be such a good idea to do laps around a glass recycling factory.

In the end we all know that it doesn’t make sense to expect the pump to have solved this problem. It is the cyclist that needs to solve it. The pump is nothing but a helpful tool.

It works the same with agile. It is not the quick solution to your problems. Agile has become a container term for concepts with very different meanings. There’s agile thinking, the agile values and principles for product development as stated in the Agile Manifesto, and agile sotware development practices. And last but not least agile as a set of frameworks that help to apply these values and principles in the practice of product development. Applying these concepts can help identify problems, and verify whether the solution was effective. However none of them fix problems by themselves. Applying any of these agile concepts effectively only makes transparent what needs to be fixed. But the fix needs to come from the people applying the concepts, not from the agile concepts itself.

Agile doesn’t solve your problems

So why do we expect agile to solve our problems or help us achieve our challenges just by applying it? To understand agile is to know that this is just silly. Agile doesn’t solve your problems, you do. Agile makes trouble transparent and requires you to understand this trouble and the context it arises in. This context consists of the structure, the processes, the behavior and capabilities of an organization and its people. Real understanding of this context is the key to lasting solutions, not the concept you’re applying.

Take a step back to have look at your organization design

To answer the question whether organizations should bother about agile, or become agile, requires taking a step back to look at the organization. Identify its true purpose and the environment it operates in. This is important, because the design of an organization derives from its purpose and what it should optimize for. Organizations that produce a commodity service might want to optimize their design to achieve cost leadership. Organizations that develop innovative products in new markets will probably have to be designed in such a way that it is capable to adapt to continuously changing conditions.Organizations these days have to operate in an environment that is volatile, unpredictable, complex and ambiguous (VUCA).  Organizations that embrace this VUCA world develop capabilities to deal with this, turning this challenge into their competitive advantage. To achieve these capabilities, such organizations have been designed in a way that they optimize for agility and become agile as a result.

At the beginning of the COVID-19 pandemic I worked for a Dutch government agency that was faced with an enormous challenge. The administration decided that businesses affected by the lockdown restrictions were to be compensated. The first policy to be effectuated was a compensation for patato and floriculture farmers. Due to the ability to quickly form cross functional teams consisting of developers, legal experts, domain experts, and process specialists, the organization dramatically reduced it’s time to market. The execution of such a policy would normally take months to be rolled out. Now it took only three weeks!

It is about the development of the right capabilities

When we look at agility from this perspective of competitiveness it becomes clear that this (whether one should bother or not)  is not a question of which agile framework to apply, but a question of asking whether your organization is designed in a way that it is capable of developing the capabilities needed to gain this competitive advantage.

Try to be like the cyclist

Just as the cyclist needs to understand the cause of the recurring flat tires and have the flexibility to change the daily routine, an organization has to apply itself to develop similar capabilities. Only then can it prosper in a VUCA world. Don’t ask whether you should be bothered about agile, ask if you are blaming the pump or resolving the causes of all your flat tires.

Jeroen Valkier

Jeroen Valkier

Man I really love Scrum!

I recall a sunny day on a terrace, at a wharf on one of the city islands of Amsterdam. Holding a book called Project Management with Scrum by Ken Schwaber, I was about to discover about the way of working I grew to love so much.

The Scrum framework is lightweight, and easy to get started with. But it is not something you “just do” starting day one. Instead, it is something that your team or your organisation can become. This is extremely challenging, and hard to get right. It demands a culture of brutal transparency, and if missed, this can cause your organisation to half ass the adoption. On the other hand, its empirical and iterative character shows forgiveness to those who really want to learn by doing. This is about learning how to deliver value to the client each iteration, and learning what the best process is to achieve that every iteration. This is also what is the essence of Scrum for me.

It demands a culture of brutal transparency, and if missed, this can cause your organisation to half ass the adoption.

It was 2009 when I first read Ken’s book. At that time, I was working on contracts as a requirements analyst on various e-commerce projects. I also tried project management in that area, but I decided to leave that behind me; too many failed attempts to achieve fixed goals at a fixed price, in a fixed time frame over too long a horizon. Many of the projects ended in exhausted team members, bullying managers and disappointed clients. For me it seemed to be the inevitable reality of software development. That was until I read Ken’s book.

Though not common practice as it is today, Scrum was already quite a phenomenon emerging at the horizon of software product development. As soon as I started reading the book, it was as if I was given the perfect explanation to all the misery I experienced in my past projects. At that moment my key take away of the book, was that our traditional way of developing software products didn’t account for the most important factor in its success and failure: the human being. It also taught me about our limited capability to create practical order out of chaos for any periods longer than a month. It taught me to respect those who do all the legwork, and how shielding a development team from daily interruptions is the work of a hero. It taught me about focus, and the power of commitment to that focus. I taught me how work is useless if the result is not subjected to inspection at regular, short intervals. The book spoke to me as the herald of the change that would relieve us from the suffering that is traditional software development.

It taught me to respect those who do all the legwork, and how shielding a development team from daily interruptions is the work of a hero.

Little did I know how difficult applying Scrum would prove to be. Not long after I read the book, I was given the opportunity the fulfil the role of Scum Master for a team working on the replacement of an e-commerce platform. Their current Scrum Master had fallen ill, and the project manager trusted me with the task. We didn’t think it was very far a stretch from the role of team lead. Right? Well, at least it was a great opportunity for me to try out this new role and framework.

Unfortunately (depending on how you look at it) it took us only three sprints to find out that Scrum was something the development team was only allowed to do, as long as management could make us adhere to the strict set of agreed requirements (i.e. just rebuild the old thing with new tech), set budget and delivery date. We weren’t expected to deliver working increments of software product that delivered value to a changing organisation at all. We were expected to build a thing they already had! And most importantly we weren’t doing it fast enough. No learning needed, no inspection allowed. Period. It was needless to say, that Scrum was soon to be scrapped, in order to meet strict deadlines and scope in this straight rebuild.

We were expected to build a thing they already had! And most importantly we weren’t doing it fast enough.

Although my first taste of Scrum was a disappointment, it was a first taste of the fun and hardship I was to have over the coming years. Since that first opportunity I decided I wouldn’t let a chance pass by to get a grasp on this freaky framework and that cool Scrum Master role.

It has been 10 years now, and it has taken me that long to begin to understand what Scrum really is, and how it helps organisations shape themselves to become better at learning how to build valuable products. Yet still, after all these years Scrum still surprises me with the silly simplicity it demands to battle needless complexity. During those years I came to love the role of Scrum Master, and how I can teach teams and organisations to face the chaos. Creating little pieces of order, to locally reduce entropy, and create beauty in function and structure. I just love it!

Using Scrum as it is intended demands transparency through inspection, but offers forgiveness in its iterations. It demands courage, but offers respect when it is shown. This doesn’t just involve Scrum Teams, but the entire organisation it is part of. At my start as a Scrum Master ten years ago, I had no clue of this. Many sprints and projects later, bruised and battered, but strengthened and with some trophies on a shelf, I feel more committed and courageous than ever.

Do you want to be courageous, but need some help? Do you think Scrum is the way forward for your organisation, but are you struggling to make it work? Just drop me a message, and we’ll see what’s holding you and your organisation down!

Jeroen Valkier

Jeroen Valkier