Author: Tom Mortensen

These are some of the videos that have helped me change my own thinking and in turn helped me help others do the same.

Peter Green on the Laloux Culture ModelWhy? It is a reminder that the extend and success of an Agile transformation is limited by the organizational culture. It gives an easy-to-understand foundation for discussing the ambition level and whether a dedicated cultural change effort should be an element of the transformation.

Eric Ries on Lean StartupWhy? We need to stop wasting our lives building stuff that nobody wants. There is another way and even large enterprises are starting to pick up on Lean Startup as it, despite the name, not only applies to startups. Read the book!

Dave Snowden on the Cynefin FrameworkWhy? Understanding the difference between the complicated and the complex domains (knowledge work belonging to the latter) will lead to a disturbing insight: The frequent failure of big IT projects is both understandable and avoidable. Since it is impossible to predict exactly what will happen as we develop and eventually release our products, we need to release, get feedback and adjust as frequently as possible, aka. iterative and incremental development, aka. Agile.

Henrik Kniberg on the resource utilization trapWhy? Because it is really, really hard getting everyone to shift focus from managing other peoples time to establishing a “pull culture” throughout the organization. There is much more to this than to stop “pushing”, e.g. a shared understanding of vision and goals, empowerment, trust and courage but the video is a good starting point.

I have lost count on how many blogs and articles I’ve read about how UX and Agile can play nice with each other but no matter what “solution” was suggested, it always left me with a strange aftertaste. It turns out that almost everyone who writes about this topic has a UX rather than Agile perspective on the issue, which shows itself in a number of different ways:

Agile is confused with Scrum

Agile is thought not to be user-centric

Agile is believed to only cover how to create code

Agile is defined by practices

The goal of Agile is seen as increasing productivity

Let’s be clear: Agile is a mindset and if you think you understand it without having it, you are most likely wrong. It’s like Morpheus tells Neo: No one can be told what it is – you have to see it for yourself. Nevertheless, I will point to two principles that are fundamental to Agile. This will not reveal the UX-Agile solution but it may explain why Agile practitioners are reluctant dance partners when well meaning UX practitioners proudly presents one attempt after the other at how to make it all fit together.

Avoid hand-offs
When management as we know it came about with Taylor more than a century ago, one of the breakthrough ideas was division of labor, which in turn required hand-offs, standardization, thorough planning and command & control. When IT development became a thing, the production management culture quickly led to waterfall.
Agile is based on a fundamentally different approach that aims to eliminate hand-offs by including all competencies needed to iterate on a product in a cross-functional team. This leads to end-to-end responsibility for the product. Even within the team, hand-offs are minimized by working together on few or only one task at a time rather than working in parallel or sequence. Firmly believing that the potential disadvantages of this approach are significantly outweighed by the benefits, is at the core of the Agile mindset.
I am not going to go into details about the benefits here but just say that they can be counter-intuitive/difficult to measure and therefore hard to convince people about. Still, Agile practitioners will work to avoid hand-offs like the plague because they understand how important that is.

Deliver value as quickly as possible
In a complex system, no one can predict with certainty what will happen. So until a product is actually being used, we have no real knowledge of the value it will create. Instead, we have assumptions and risk. Studies indicate that assumptions about the value of our product ideas are wrong disturbingly often. Further, we would rather have some of the value early and the rest of it later than all of it later.
As a consequence, work should be segmented into the smallest possible chunks that we think will be valuable to the user and then deployed as quickly as possible so we can validate our assumptions and feed learning back into the next iteration. The more effort we invest in pursuing bad assumptions before they are validated, the greater the loss. Even worse, we will have a harder time accepting we were wrong, which could lead us further down a doomed path. That is why e.g. architecture and design needs to emerge as we learn and not be done up front.
Again, there are undeniable drawbacks but also significant benefits from this approach. However, an Agile practitioner is convinced that the pros will overshadow the cons and that is why any attempt to systematically conduct work in phases will be met with strong opposition.

So, where does that leave us? I believe that UX and Agile need each other and in stead of waiting for the perfect solution, we should embrace the awkward and sometimes clumsy dance as long as we continuously work hard to improve. In my mind, the end-state is UX integrated with all other disciplines. Nobody thought it was possible with e.g. testing or operations but look at us now. UX is next.

When I first headed over to the Agnostic Agile website, I really liked what I saw. In many ways I still do. I like the idea of being agnostic towards Agile practices, and in my mind that means not believing that any practice or framework is the answer but being open to the idea that, under the right circumstances, they could be. Also, I fully support high ethical standards and always improving as an agile practitioner.

However, as the title indicates, I have concluded that I need to withdraw my support for Agnostic Agile in its current form. Here is why:

We need an open mindset – and that includes openness towards criticism. We are not doing ourselves, our customers/employers or the Agile movement any favors by withholding our honest opinion. The more I look at the Agnostic Oath, the more it reads as an attempt to establish a ceasefire between framework practitioners. Personally, I insist on retaining my right to call out frameworks, and even their practitioners, if I feel they are selling something as Agile that is not.

So, if you want an oath from me, here is one: I promise to do my best to understand and promote the Agile movement in all its diversity and to challenge whoever and whatever undermines it.

A question that regularly pops up in the Agile community is how to convince people (often upper management) to go Agile. While this is a valuable question to answer, there is an even more important question:

How do we convince people that an Agile transformation of a sizable organization is an ongoing effort and not something that can be completed in a year or two? And how do we do that up front while still convincing them that going Agile is a good idea?

I believe this is necessary to avoid losing momentum after implementing the very visible practices at the team level (typically Scrum). Whether you focus on the rest of the organization sequentially or in parallel, the changes to management mindset, organization structures, competences, culture, governance etc etc. will take longer, have greater impact and be less visible. The problem is that these changes are much harder to explain and will significantly affect those you try to convince – now it’s suddenly about them changing and not only deciding whether others should change.

Find an answer to this question and you will have done your organization a favor of tremendous proportions. Alternatively, you risk ending up in the dreaded “Agile reboot scenario” after a few years.

This is my personal website. I’ll use it to share some of my thoughts on Agile.

My thoughts are often disorganized and developing much faster than I can articulate them but sometimes I intuitively hang on to some of them until something coherent crystallizes in a flash of insight. When that happens, I really want to tell someone about it. If you stick around, it’s going to be you.