Yea right.

I bet your Agile process is broken.

Most of us are practicing some form of Agile today. Whether you’re following a “lean” process of design/build, test and iterate or something more along the lines of “watergile” with locked down sprints and deliverables, we’re in a weird space where a development delivery methodology has become the norm for design.

The reason Agile is so ubiquitous is easy enough to understand; it’s a way of breaking big problems up into small chunks. It also flips the tradition of “fixed scope” into “fixed cost/time”, which makes “what you’re building” fluid.

A sprint is supposed to look something like this:

Define the problem > Start designing > Test > Iterate > Test > Build

With enough sprints, or when the time or money have run out, we release the minimum viable (or valuable) product (MVP) and continue the cycle.

From the defined solution we design, test, iterate and develop; we learn as we go and we build up our product through cyclical iterations. Sounds good, right?

The reality, however, is often more like this:

  • Business decides on a PRODUCT (rather than identifying a problem)

After a few sprints, there might be budget or an appetite for testing.

By this stage, a bunch of stuff has been built. Results from testing come in, and it looks like we didn’t know our users after all. In fact, we need to change some things. But that’s cool — we take it in our stride by putting the changes onto a backlog. The developers (devs) will pick up the changes when they can. But in reality, new features take priority over changes to existing ones right? So… the MVP deadline is moved out or the quality is compromised.

Notice how design has moved further down the delivery line here. It’s “defined” by the user stories and services.

So what’s going wrong?

Don’t get me wrong — there are probably plenty of companies that are doing Agile design and rocking it. In my experience though, at an enterprise level, there are a few reasons why we’re struggling. It mostly has to do with the bad practice of Agile, rather than bad principles. I’ve identified six reasons why Agile isn’t working well:

1. Velocity over Quality

In daily practice, we seem to value velocity over quality. By the time the design starts, the services have already been built and the sprint plan is untouchable. Once something is in “dev”, nothing can be changed. They can, according to Agile, literally build something that is outdated, or untested — all because the sprint is sacrosanct. Often we’re left delivering the wrong things — and we know it — all because we need to keep moving. Testing is supposed to be an integral part of sprints. In reality — it isn’t.

2. Bad over Bored

On the scale of Agile maturity, Chris Thelwell says that all teams are somewhere between “throwing grenades” and “design facilitators”. In the middle is where most of us find ourselves — getting stuff done because the developers need work. It’s called “Feeding the Beast”.

We’re often having to send work to the devs even though it’s not right yet, just because we’re under sprint pressure. Added to this pressure is the ratio of design to devs. It’s often 1:6 or worse. So, of course, we’re just feeding the beast and sending mediocre work into development.

3. Incremental over Iterative

Feature roadmaps are effectively silos. We progress to “checkout” without a “shopping cart”. We “pay” without performing a “transfer”, because on the map these are different things. What ends up happening is that we design fully functional features that don’t talk to each other. Instead of designing a product, we are designing features.

That makes us incremental designers — those who design small chunks, rather than light features that will get richer iteratively.

4. Project over Product

Similar to the previous points, on a project roadmap, you will often find vague sounding features like Login or Checkout. What you don’t often find is “navigation model” or “prototyping”. That’s because we designers pack in so much more than what a “feature set” shows. These design processes and deliverables don’t feature in the plans. This results in sprints that go over because to solve one problem, a bunch of other problems need to be solved too.

5. Chicken or Egg

I’ve noticed two distinct approaches to design within an “Agile” environment. One is Product Owner/Tech-down, the other is Design-down. There are problems with both. But the former is worse.

The problem with letting technology define design is that we end up with poor quality. It’s well known that re-usability is valued highly in services and development, while design aims to solve problems contextually. This chicken or egg problem is one of the main contributors to team tension and bad solutions.

6. MVP over Product

Product design is hard. But you know what’s harder? Not seeing it through. I find all too often that the MVP is the goal. MVP becomes MVP 0, MVP +1 and MVP +2. These are not even things!

There is no plan for feedback after release, and often the team is moved onto another project before the real iteration cycles can take place. Because remember, according to Agile — time and cost are supposed to be fixed. The MVP should not be the goal; it should rather be a pitstop in the greater product’s journey.

So what now?

I have some suggestions for dealing with Agile… In the beginning of a project (lucky you!):

  • Question everything from the definition of minimum viable product, to the customer value proposition. Be the annoying voice of reason.

In the middle of a project:

  • If it doesn’t fit, don’t force it. If your team is struggling with Agile, chat to them and try other ways of doing things. It’s not the methodology that gets a product out.

Remember, big organisations don’t change overnight. Everybody is (still) buzzing with the Agile fever, often blindly. However, it doesn’t fit each place or each project equally. Agile is just another way of getting something done, and you should choose the approach that works best for your product.

I wrote this in 2017 to highlight the realities of practicing Agile design and development methods within enterprise level companies — where change is slow, and Agile is mostly a buzzword.

I spoke about this controversial topic as the keynote speaker at the 2017 World IA Day in Johannesburg prior to publishing.

Everything in life is a UX problem…

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store