I bet your Agile process is broken – 2017
I wrote this 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.
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 the 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)
They decide on a deadline
They get product owners (POs) to start the project
POs do a cost-value analysis and say that they’ve done customer validation
They sometimes put user stories together, or some requirements based on the definition
Design and dev start together
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 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.
At the beginning of a project (lucky you!):
Question everything from the definition of the minimum viable product, to the customer value proposition. Be the annoying voice of reason.
Do your own validation. Even though everybody thinks they know their customers, very few actually do. Make sure you know that the problem you’re trying to solve is a real problem.
Insist on a design discovery phase, as you will need this to be able to put together your feature maps, high-level flows, or mood boards. Check if your work lines up with the proposed MVP. If it doesn’t, speak up.
List your design deliverables. Your product owners and sprint masters may not know that you need time for prototyping, testing, or logo exploration. Make sure your tasks are included because nobody is going to do it for you.
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.
Prototype, prototype, prototype. It’s not just a way to show how something could work (and for testing), but prototyping is a very effective tool for showing how something shouldn’t work. Use this power.
Pick your battles. Not everything is equally important. Fight for what is, and let the rest go.
Optimise the ceremonies. In sprint planning, add in your design deliverables. In grooming, only bring sketches. In retro, raise what’s bugging you. Use the ceremonies to be heard and to build empathy for the design process.
Plan for after MVP. Even if you can’t fix the process now, make sure it changes for the next set of sprints. Get your design bugs listed and make sure you have time for your design diligence in the next one.
Remember that 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 in my opinion, it’s not the best for product design.
