Anime scrum process flow
Sprinting is Fun!

Let me pause my daily Jira/Agile/Scrum busywork to say a few things about Agile.

As it works today, Agile Scrum usually causes more problems than it solves. Sure, the common response (like the ‘Design Thinking Sucks‘ thread) is “you are doing it wrong, then“. OK then, but it is getting worse with no sign of getting better.

Search the web for ‘problem with agile’ and you’ll get lots — here’s one exemplar about why developers hate agile. Essentially, the ringleaders of the Agile Manifesto even complain — because it was initially created by engineers to fix what management screwed up taking over system development. I’m sure initially these engineer-led internal projects were a huge success, actually delivering a working system and not just binders of requirement documents.

But don’t underestimate the ability of management to co-opt and screw things up again. Bob Martin’s talk summarized the business takeover of agile:

hordes and hordes of project managers started to get certified. And they would sit for two days in a class, and get a piece of paper, and feel that it was somehow significant. And they, literally, took over the Agile movement… The Agile movement shifted dramatically towards the project management side.

Bob Martin ‘Future of Programming’

Remember the Project Manager of the 90s-00s? Their job was to go to cube once a day and ask ‘Are you done yet?”. So they could report to the VP the project is XX% complete. Did not really care if it worked or not, or if it met customer needs. I always wondered where they ended up, now I know it’s Certified Scrum Masters and Agile Coaches.

Worse now, management consultancies feel they are missing out, so new certifications, consultations, schemes are being created like enterprise agile … any number of oxymorons in there.. Working towards adding more layers of management tracking, losing the picture of working code that solves problems.

Let’s look at one of the Agile Manifesto principles: Individuals and Interactions over Processes and Tools.

There are more processes, meetings, ‘ceremonies’ etc. in agile scrum than anything else. In a 2 week sprint you are working around these meetings, sometimes feels like there is more meeting than work time. Grooming, refining, planning, sprint close, demo, showcase, retro, standup, yada yada yada. More ‘sorry I was on mute‘ and ‘guess we don’t have anything so I’ll give you 30 minutes back‘ — but I don’t get that back because I stopped my work for your meeting and couldn’t schedule an interaction session with individuals over your block.

Now Tools. Atlassian Jira now runs your work life. Seriously I have spent more time creating an issue/card to the precise fields in the tool and rules from the scrum master, than creating the corresponding design mockup. And then get chastised not pointing it correctly or writing the acceptance criteria in the proper manner. Plus, don’t bother doing any work that pops up as inspiration, because adding it will add scope to the sprint and throw off the metrics. The report drives budget, velocity gets coders dinged on their performance evals.

OK so all these problems, but good luck working on a project that isn’t using agile scrum. I said UX Saves Agile anyway, so how is that true?

Because UX does waterfall.

Don’t call it that though, you will be shunned (literally, I am telling you). Instead, say ‘Discovery‘. In fact, there is a tweak on agile called ‘Dual Track‘ that folds discovery design work into development sprints. At a micro level it is a designer and researcher working on a feature design at least one sprint ahead of coding. Duh. But ideally, most designers hope to have the full product release mocked up or prototyped, and validated through usability testing, before Sprint 0. It becomes the basis for pointing the work. If you don’t, and discover a gap in sprint 6, you’re going to get hammered for adding scope and they’ll just release the half-assed version as MVP. Worry about it later. That is how tech debt and design debt pile up.

But devil’s in the details. If you insert the agile management into discovery, you will further screw things up. They will tell you to plan out in detail each feature you will discover, make cards, point them, add tasks for generative research, usability testing, etc. And if you have a design team, e.g. 4 designers collaborating on a prototype, you must explicitly assign designer X to feature Y, siloing work instead of collaborating… ugh.

Discovery is all the stuff you need to do to identify the problem to solve, which doesn’t lend itself well to Jira planning.

design squiggle showing uncertainty to insights
Fine, but let’s put it into Jira cards.

Not sure I have a solution to this, except do your design work well, on time and show an awesome prototype to execs. Then say: we can do more of this, just let us self-organize. Which should sound familiar.

Agile is Broken, But UX Saves it Anyway
Tagged on:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.