The Agile Fallacy

"That's not Agile!" - does it matter? My claim - no!

"Being Agile" isn't true/false - it's a spectrum from rock to photon. Everyone is somewhere.


When looking behind the "Agile vs. Not Agile" bifurcation fallacy, we can start asking more meaningful questions:

• Does the organization meet Market and Business Needs properly?
• Does the Product stay relevant over time?
• Are the Delivered Outcomes useful?
• Is the Total Lead Time acceptable?
• Is the overall Return On Invest of development positive?
• Does everyone Focus on the most important thing?
• Does development create up-to-date, Sustainable Solutions?
• Is Technology Debt under control?
• Is Improvement Potential leveraged effectively?
• Do Failures get addressed and corrected openly?
• Is there Continuous Learning going on?
• Does the company exhibit Resilience to market changes?
• Does the organization have a Sustainable Workload?
• Does the organization attract, grow and Retain Talent?

If all these questions are answered with "Yes", then I could ask "Why do you want to be agile?"
If the answer to some or all is "No", then I would ask, "Then what are you doing about it?"

Taking a closer look, even these questions aren't binary, but gradients which would usually range somewhere from "We need to do something immediately" to "Yeah, we might want to think about it."

All the above questions are merely indicators of whether an organization is sufficiently agile for its own good, so I would leave you, as a reader, with the initial question: If an organization is excelling in all the areas mentioned above, does it matter whether they're agile?

Can you afford to have an IT department?

Many non-digital businesses augment their core business with digitization and automation. IT is "The Thing", and even though every organization want to have the benefits of an IT, few seem to consider the cost of IT. In this article, we will examine a few critical considerations.

Bad IT is just as good as burning cash.

When IT becomes a poor investment

In many organizations, IT is still considered a "feature factory" where business dumps in requirements, gets a cost estimate and upon approval, a piece of software to automate a phrased request, and that's it. Business and management neither wants to think about what is being done, nor how much effort is required to create and maintain the solution.

This approach was okay in the past, when the major cost of IT was in procurement of hardware and licenses and the human factor was neglegible.

Fixed cost procurement

Factoring the cost of a purchased IT product is easy: you have a purchase price for hardware and licenses, sign a support contract with a fixed price, order some training and you're done.
The cost of such an IT can easily be computed as a business case: when the cost is lower than the savings, you're good.

Cost Estimation

Unfortunately, that's not how today's or tomorrow's IT works.
Today, business wants automation for something that they are currently doing either manually or not at all. There is no solution which can be purchased.
Knowledge work is required. Since the optimal solution isn't known, the cost becomes difficult to compute, and therefore, all cost estimates are just that - estimates. There is no reliable way to tell the production costs of a feature until it is done.

Hidden Costs

And now we come to the fatal trap which many organizations fall victim to: the accruing cost of IT over time! Business terms like debt, deprecation and amortization are also applicable to IT.

Debt in IT

A financial debt is accrued when spending exceeds available funds. In IT, debt is accrued when technology is being utilized in ways which will result in future problems. Known debt still can be controlled, although few organizations measure and control this kind of debt. Every accountant would cringe if someone told them, "Oh yeah, we're making debt every day, but we're neither keeping books nor make plans for repayment" -  yet this is how IT works in many companies!

Time-saving measures allow the business to get visible results faster, yet increase future cost.

In some organizations, this invisible IT debt is already so high that things which would take minutes on a green field take weeks within the existing infrastructure. Imagine that you're paying a loan shark an interest rate of a couple thousand percent per day - that's uncontrolled IT debt for you!

Deprecation in IT

The good thing about the constantly evolving field of IT is that new technology makes ever more complicated things ever simpler to achieve. On the reverse side of the medal, if you're not familiar with this technology, you're missing out!

While IT specialists are busy maintaining the existing legacy and struggle to integrate the latest feature requests, their technology outdates - and their knowledge, as well!

The company constantly invests into an ever-shrinking asset: status quo. At some point, the existing staff will no longer suffice to maintain status quo, so additional experts are brought in to keep IT running, although the marginal value of the infrastructure is already approaching zero.

Adding insult to injury, re-engineering the legacy based on the legacy processes with a legacy skillset using legacy tools exponentially increases the cost of change and produce a similiarly ineffective outcome.

Take, for example, the company still maintaning an IBM 704 mainframe: the costs of administration, maintenance and electricity are astronomical - yet the computing power of the system dwarfs a $100 smartphone! Yet, many companies still stick to their old systems because core business processes rely on them. Any effort to replace this legacy becomes unfeasible both because nobody has time and the effort is humongous.

Amortization in IT

The financial technique of amortization splits the cost of a finite-life product into a series of installments. and something similar happens in technology.
Danger: The analogy of amortization is highly flawed - your accountant would rip your head off if you tried to explain to them that:

• You have no idea when the final installment will happen, and there will potentially be an infinite number of them!

• If the present value of a system is lower than its cost, each installment will have a negative ROI.

• You're very likely to pay installments long after the marginal value is zero.

Let's say, you your developers need a technical training; If you don't invest, their code is more expensive and less valuable than it could be - but if you do it, in a year, their code will still be outdated. You amortize not to generate profit, but to reduce loss.

IT is a money sink

Running an IT department is not just about having a handful of servers and building some business functionality.
This is how IT costs money:

IT assets are debt-riddled

Quick wins in IT tend to be even faster losses. Without a future-oriented sustainability strategy, you're no longer taking a controlled debt, you're baiting loan sharks!

If you don't (want to - or can) control your technology debt, your IT will eventually kill your business with skyrocketing costs at little to ROI!

Make technology debt visible and keep the interest at a maintainable level.

IT assets deprecate drastically

Any technology should be replaced within 5-7 years, so regardless of whether you're investing $1000 or $100m, be prepared to re-invest a similar amount in less than a decade. The more your IT is worth, the more it will cost you.

Without a deprecation control stratey, your IT will eventually be worthless, yet continue to drain money needed for investments.

Move towards continuous asset migration and decommissioning rather than investing heavily into maintenance and support.

IT assets won't amortize

Any technical or knowledge asset which isn't worth its cost by the time it becomes available, will never be. While cross-subsidization or taking a loss in order to avoid greater losses are both feasible options, throwing good money after the bad isn't a strategy!

The acquisition and maintenance of assets which "might have future value" is an unsound strategy that will most likely result in an economic shipwreck.

Avoid over-engineering, keep as little technology as possible and consider any investment "lost" the minute you signed the check.
Obtain technology only when it is needed, and only as much as needed.

An IT Investment strategy

Based on the above, let us now consider a few choices that you need to make with your IT:

• Are you willing to consistently and scrutinously track and combat technology debt?
• NO: You will lose cost control of your IT if you haven't already.
• YES: Lapses cost twice. Be alert!
• Do you have a sound mechanism for determining the net present and maginal value of your IT?
• NO: Your ROI will most likely tank.
• YES: When a processes' cost exceeds its marginal value, eliminate it.
• Are you willing, able and ready to identify, replace or eliminate ineffective cost drivers?
• NO: Your IT is a gambit with diminishingly low odds of success.
• YES: Remember that yesterday's business driver can be tomorrow's cost driver!
• Will you consistently invest a significant amount of time and money into the continuous learning of your IT workforce?
• NO: Your IT is dead already, you may just not know it yet.
• YES: Keep an edge. Avoid tailgating others.
• Does your organization have the courage to admit and the grace to write off mistakes?
• NO: Your IT will eventually be the Emperor's New Clothes.
• YES: Turn failure into learning, mishaps into opportunities for change.

If you have answered "NO" to any of the above questions, either re-consider your IT strategy or consider obtaining services from a provider who would answer all of them with "Yes".

A brief history of IT

Is your IT future-oriented? 
The nature of IT is changing - if you aren't adapting, chances are that your IT is a liability rather than an asset for your organization. So - what's different?

Yesterday's IT

The era whene IT was nothing more than automation of repetitive data processing is over.  Old IT systems were difficult to use, required scrutinous training, changed slowly were fully defined by static, prescriptive processes which permitted little variation. "IT" was mostly a data dump and retrieval center.

Users had a desktop client software which connected to a central database. The flexibility these systems possessed was in their ignorance of business processes (albeit sometimes with the pain, "We don't have a form field for this").

IT had full control of who had which version of the software and how the data was used - oftentimes, without even understanding what this data actually meant or how it was used.  Business processes were fully part of the business domain and outside of IT scope.

The legacy of this era remains a pool of low quality data and systems which are difficult to understand, maintain and upgrade.

Complexity was on the level of getting servers stable and software to run. Business complexity was neglegible.

Today's IT

IT does data processing more than ever - but the nature has changed.

More and more business logic has been inserted into IT systems, to the point where IT systems are doing actual clerical and administrative work. For example, a modern IT system not only accepts customer data, it might validate the customer's address, credit score, and order. IT systems reject bad contracts, informs the customer when products are out of stock, offers alternatives and even provides discounts, cross-sales, upsales and bargains. And that's just pre-fulfillment.

Such an IT is no longer a dumb data shelf for smart business processes - it becomes more the other way around: IT systems have an even deeper understanding of the business than any human being in the organization.

While many companies still face the complexity of managing their infrastructure, today most complexity resides in automating and managing the business capabilities.

Tomorrow's IT

In the age of "everything-as-a-service", IT infrastructure and processes are mostly automated. "Serverless", client-independent services can be used from anywhere for pretty much anything. Interconnected services route smart, self-correcting requests to achieve their purpose.
Autonomous agents discover and learn rather than blindly act upon pre-defined rulesets.

The IT of the future can do anything we can set our mind on - if we have the right skills and are willing to invest into the right tools. Constraints are either willful ("we don't want to ...") or external (e.g., "we can't afford ...") and no longer technological.

Although the technological complexity of such systems is extremely high, it is self-managed by other technology, allowing IT specialists to focus on creating enabling features and their interconnections.

Where is your IT?

With the above historic summary, you can quickly decide whether your IT is past-, present- or future-oriented.

Many organizations want to have tomorrow's IT, yet they are stuck maintaining and servicing yesterday's IT, so they can't even take the benefits of today's IT.

From an economic perspective such backward-oriented investments are hardly feasible, yet sunken-cost fallacies and fear of the Unknown make them commonplace.

If you're not prepared for the IT of the future, now might be a good time for making some strategic adjustments - improvement doesn't happen by itself, we must work towards it!

Setting meaningful goals

Tasks, Stories, Features, Sprints, Products, the company strategy - they all have goals, and each of these goals has an impact on overall success. Beyond SMART and INVEST which are focused solely on the definition of a goal, let's look at some important considerations for in the timespan between definition and achievement, i.e. the implementation phase.

The Goal Factors

Here are six factors which will help you define helpful goals:

Clarity

In discussions, people shouldn't be talking at cross purposes. During implementation, we need to know whether an action will be progress or distraction to act accordingly.  Clarity also affects how we determine whether a goal has been achieved or there is residual effort.

Clear goals offer little space for interpretation when the goal is achieved - and partial solutions are likely a step in the right direction. Unclear goals cause people to constantly stab in the dark.

Significance

A goal should always be so important that success as well as failure have a significant impact somewhere. If there is no impact, other things are probably higher on the list. Significance depends on the bigger picture. For example, a task or a feature are only as important as their contribution to the strategy.

Highly significant goals create a sense of urgency and importance and thereby provide a boost to motivaton.

Traceability

Goals exist for a reason. Regardless whether a goal describes a specific customer need or a strategic objective, there should be tracibility of where the goal comes from, what it contributes to and who is involved.

Traceability is a two-way street, so goal definitions need to be traceable downward into implementation as much as they need to be traceable upward into strategy.

Relatability

Every person involved with a goal should be able to relate to this goal. They should be able to figure out their contribution towards success as well as the impact the achievement or failure has on them.

Goals that are highly relatable are much more likely to be achieved than goals which contributors can't relate to.

Constancy

Goals should mean the same thing from the time they are decided until met. In rhetorics, the metaphor of "Moving Goalposts" describes a surefire way to derail any effort to make progress. A goal should not change. If it becomes different, then that is a different goal.

Constancy reduces waste, as detours are evitable. Any shift in goals turns all activity towards meeting the previous definition into waste.

Flexibility

Goals should be as flexible as possible in ways of achieving a favorable outcome. When a plan doesn't work out, alternatives need to be found without compromizing either the goal or its traceable line in the organization.

When circumstances change, flexible goals only require changes to the corresponding action plan, whereas inflexible goals might cause inefficient replanning and adjustment at multiple levels.

The importance for management

Goals which meet these six factors can be monitored effectively in multiple dimensions because of enhanced transparency in the following dimensions:

• Success - was the goal met?
• Progress - are we getting somewhere?
• Blockages - are we moving?
• Delays - what affects what else?
• Waste - are we on the right track?

These items are equally important to individuals, self-managing teams and the overarching organization.

The importance for workers

Goals which meet these six factors will help workers in multiple ways. Working on such goals boosts:

• Motivation - why is our work important?
• Alignment - are we talking about the same thing?
• Creativity - which options do we have to contribute?
• Performance - how far have we gotten?
• Accomplishment - what have we achieved?

Summary

Regardless of whether you're setting goals for the day, for the Sprint, for a Product or a Project - for a transformation program or for the entire organization, keep in mind that these goals should offer:

• Clarity
• Significance
• Traceability
• Relatability
• Constancy
• Flexibility

Without creating yet another futile metric, goals which are better on these six items will be more likely to contribute more to your overall organizational success  than others.

And most of all, if you miss setting goals - you're losing out both on the factors and on the benefits.

Goal Setting in an agile organization

Is your agile team is on track? Are you making progress? How do you know? Here are some tips to keep in mind.

You will notice in this article that nothing has anything to do with a specific agile framework or even with "agile" in general. Indeed, the remainder of the article will avoid the term "agile" completely. The suggestions are still fundamental to agile transition, because without these things, you're in for a trip to Wonderland!

Take your time and define, step by step, in the order presented in this article, the following items:

Mission

Where do you want to go, as an organization? Why does the organization exist, and what will be different because of the work that people do?
"To earn money" or "To pay the bills" won't cut the cake, although that's obviously something a company wants to be able to do. Your mission should discriminate you from the broad mass, giving guidance on things which the company would do and wouldn't do while being simple to remember.

Here are some guidelines when setting up a mission statement:

1. Length: People need to remember it. Five words - maximum!
2. Clarity: Provide meaningful guidance and direction.
3. Breadth: Include everything you really want to - or are already - doing as a company.
4. Focus: Must allow people to align activity.
5. Avoid slogans: Must be useful as a yardstick in everyday work - and not just for marketing!

Examples:

• "Improving work" is a legitimate mission for a consultancy,
• "Delivered." would be a feasible choice for a logistics company,
• "Everything covered" might be appropriate for an insurance.

These statements are broad, yet focused - short and clear and can be used as a discussion point when discerning whether an activity is in line with the company's goals or not.

A mission statement isn't immediately actionable. It's guiding in nature and should rarely change.

Strategy

From the mission, a small set of strategies should be derived - how do we plan to make this happen?
A strategy is a mid- to long-term plan for moving into a certain direction and should lead to some relevant outcome that is aligned with the mission.

As odd as it seems, this step is often skipped or neglected. Since a strategy is a clear statement of a direction into which we develop the organization, the presence of a strategy is necessary to determine whether you're still on track.
It isn't even necessary for management to define strategy - in many cases, employees have a good idea what strategies they would pursue, but they don't have any means or transparency to communicate this.

Taking one of our above examples, if we have "Delivered" as our logistics company mission, the following strategies might all be valid options:

• Enter grocery delivery market.
• Partner with company X and employ their delivery network.
• Pivot Drone Delivery.
• Build a Delivery Hotspot Discovery service to monitor and optimize efficiency.

Some strategies might require just a few months, others many years.
A strategy is good when we can tell clearly which set of activities is part of the strategy, when these activities are achieving the strategy - and how the strategy relates to our mission. Ideally, we can also fathom who could be involced and how long it might approximately take.

Strategies still aren't actionable, but they help people deciding for action determine what to do.
Keep the amount of strategies small, as too many dilutes your resource pool and impairs focus. Also, try having more than one strategy as putting all your eggs in one basket is a significant business risk. Two to five strategies are a decent bundle.

Revisit them about quarterly, abandoning those which are obsolete, reinforcing those which are worthwhile and adding one when needed.
Keep in mind: For every strategy you add, you should axe another, lest you lose focus and mess things up.

Goals

Strategies aren't equal, and the things we actually want to achieve might differ as well. This is where we get into the realm of setting SMART Goals: Specific, Measurable, Ambitious, Realistic, Time-bound.
We must be able to figure out how much of what we want to achieve by when - and that should  likewise be challenging and possible.

Many companies have trouble with this step because the wrong people do it. Ideally, goals are uttered by the people who will be working to achieve them and verified for priority, plausibility and strategic alignment by management, rather than enforced top-down. Only when management realizes that the workforce isn't able to set meaningful and important goals, should they feel the need to intervene by providing more clarity and context.

All goals are not equal.
Strategic goals might take years to achieve in a stepwise process, operative goals may be met fairly quickly and tactical goals could be succeeding each other in rapid succession.

The importance is that depending on their nature, they're frequently revisited and constantly verified against their alignment both with the strategy and mission - as well as with other goals the organization might be pursuing.

Transparency of goals is important to prevent the accidental pursuit of competing goals as well as enabling collaboration between people pursuing synergetic or overlapping goals.

When goals conflict with each other or strategy, everyone should feel free to have a voice and raise their concerns, as working on such goals would result in a loss of time, money and opportunity.

A problem with goal-setting is that when undergoing change, goal-setting isn't a straightforward action. Larger goals need to be achieved incrementally with intermediate checkpoints and feedback loops - another thing many organizations get wrong. Either they forget to feed subgoals back towards overarching goals, or to act upon information that a goal no longer makes sense.

Goal-setting on different levels should be a frequent exercise, but when a goal hasn't been pursued or seen progress in months, then that goal can be considered obsolete for all practical purposes. Don't bother with these - axe them. The shorter the time between goal-setting and seeing their achievement, the faster the organization can act.

Actions

Goals need to be met somehow, so some action must be initiated. Regardless of whether this action is an initiative, a program, a project or even just a small task - it needs to be clear who is responsible for the action and how we can know whether it was successful.

As one action could contribute to more than one goal, or one goal could require more than one action, creating clarity between the relationship of goal and action is essential, although the only people who can do this in a meaningful way are those who set the goal and who will be executing the action. If these people don't know - nobody will!

Since actions are only required to achieve goals, depending on the complexity of the work, it may or may not be important to make these actions transparent. When people's actions could block each other, these people need to communicate. Other than that, actions and their tracking are irrelevant.

Results

Every action should have an outcome - and that outcome can be as intended, or otherwise. It's a good idea to define the intended outcome right alongside the result, in order to assist the execution of the action.

It's essential for those who complete an action to know the intended results and correlating goals, as this is the yardstick for progress. Performance should move away from amounts of action conducted towards results achieved.

Results are the compass for action:

• When results are moving away from the intended goal,s the action needs to be revisited immediately. 
• When results are moving towards the intended goals, the action is on track.
• If an action proves to be ineffective, it needs to be changed.
• And when the intended goal is met, it may be time to either complete the action - or set another, maybe more ambitious goal.

Results should be revisited frequently and feed into their goals on at least a weekly basis. While "no result because no action" is an acceptable explanation, this is a clear indicator that something should be done in this context:

• If the result is important, it needs to be prioritized for action
• If the result has become obsolete, no further action needs to be taken.

Conclusion

Let's return to Alice and the Cheshire Cat for a minute.
If you don't know where you want to go or why you would want to go there, or how you would know whether you have arrived - it doesn't matter which way you take.

You need to have your mission defined ("where you want to go"), so you can state which strategy you want to pursue ("which way you go") and by defining goals with verifiable results, you can even discover whether you've gotten somewhere.

If you lack these three components, you will still get somewhere, eventually - but whether that "somewhere" is where you'd like to be, is a completely different story.

Just like Alice didn't know Wonderland and she had to explore, we often define goals without knowing the way and discover midway that both the goal and our action was maybe not the best choice. Still, we are where we are and have to move from there, so our process of locating ourselves, and determining the next step are essential.

The more frequent and painlessly we can go through the feedback process of Goal-Intention-Action-Result, the better we become at getting where we want to be.

And to close with the Cheshire Cat:
"You sure do that, if only you walk long enough".