More Agile, More Problems

A few years ago I actually counted the projects I have been on, and found some interesting stuff. Among them, that at the time I had worked on 150 actually launched projects that used Agile methodology. That was a while ago, so certainly far over 200 now. And many long-term ones; just one project for one client I am now entering sprint 38 with no end in sight.

I have taken formal training a half dozen times. I mean, sit in a room and watch powerpoint and fold paper airplanes as a team for 2–3 days, six times. If Agile was a single thing, I’d have taken the Black Belt™ Coach Master® training to get the certificate, but as no such thing exists, I have not.

A process diagram showing how UX can make a target design and then test and iterate with each sprint.

Over time I have written or contributed to numerous articles on, Agile user experience design, working agilely, the role of user experience in the product development process, and much more.

And overall I complain a lot about it. But let’s be clear, the problems (outlined in 21 steps below) are practical effects. Speed, efficiency, flexibility and user focus are great. I am all for it, and work fast and cheap most of the time. But if you go make your team go Agile, what will more often than not happen is:

That’s not me throwing all the story cards in the air because the product owner just boned the free, open iterative process with a fixed delivery schedule. Still Agile though, isn’t it?

1. Agile is a cult, pursued with evangelical vigor. Simply writing this will make people excommunicate me from something or other.
2. Agile is predicated on lies. The opposite of Agile is not waterfall. Waterfall is not a software development methodology. If you don’t even have an inkling of this so you can argue it, stop and do some research on the history of software development methodology.
3. Agile isn’t a process. Or is it? Are you sure?
4. Agile is perceived of as a magic bullet. It gets poor oversight and intense demands for success, way too fast.
5. Agile is too focused on internal metrics. See #4 and wonder how often the numbers are… massaged, to meet the need of keeping-all-our-jobs.
6. Agile doesn’t measure quality.
7. The Product Owner is not the user. What they want is irrelevant to developing a quality product, much less a needful product. Review with the PO only means nothing.
8. Increments, iterations? Same thing. No, seriously, often have seen them deliberately conflated, but even when they should not be, 90% of the time (generously) a sprint is just another way to talk about an old school code increment.
9. SCRUM means nothing more than additional meetings. Okay, and a slide of rugby players to add to the other sports analogies in the Coach’s decks. See #8; very, very rarely have I seen flexible planning. A schedule is made, a schedule is to be stuck to or you aren’t a good fit for this team.
10. Change control boards are part of Agile most places I work. Or they aren’t because change mid-project is not allowed. Yeah, didn’t I already say you need to stick to the schedule?
11. Time, Budget, Features. Agile or otherwise, Product Owners continue to pick all three. So the fundamentals that it can improve on are entirely lost.
12. Because agile is rarely implemented adequately. Merged with existing processes, the bad parts of both are emphasized.
13. Agile is too strict. In principle you can solve any way you want. But practically there are approved methods. And if you use another one, even to laying out your team pod in a different way, you are viewed as a heathen.
14. Agile projects are measured off narrow, unique analogues to data instead of data. Velocity means nothing external to the project, and cannot be usefully measured between teams in the same building. Don’t tell me usability is soft: we have stuff like SUS.
15. Agile loves itself. Way. Too. Much. If you don’t think Agile will solve our problems without question, or bring up an alternative way to do anything, you should consider whether you like working here.
16. Agile is trendy. So it is used without question. Literally without being questioned in any way.
17. Agile encourages inefficiency. More often than not I see the mythical man month come bite orgs in the ass, as they add more Agile teams (from 20 to 200 developers!) to build more features, and the years go by with no launched products.
18. Even otherwise well-done Agile projects encourage technical debt. There’s no prize (no metric) for quality, lifecycle efficiencies, operations (DevOps), maintenance, or lordy documentation and annotation of code. This makes it especially bad for the startup, and in my experience is why so many startup orgs or efforts make great gains in a few months, then seem to stagnate for a few years. They are fixing the problems, but with a system which doesn’t encourage long-term thinking.
19. Agile is imposed. Organic simplification of methodology, building good teams and collaborating works great. These same things cannot be forced from above.
20. Agile is not user centric. I am sorry, but pretending you are talking about a user doesn’t actually mean you know what you are talking about, have empathy, or have data to back it up. I stopped being a developer because I wasn’t that good at it. How much experience do you have with usability, cognitive psychology, ergonomics, and human factors? Oh, none? So stop pulling “as a user” statements out of thin air then.
21. Agile is engineering focused. Again, it’s a software development methodology, and encourages progress not design, code not quality, completeness not needfulness. Many times I have been the UX guy for three or seven Agile dev teams at the same time.

Which brings us to the big issue: Agile is not a process. It is a software development methodology. How to integrate UX into Agile? As soon as you tell me how to integrate finance or marketing or legal into Agile I’ll talk to you about how to do Agile UX, mkay?

Zero projects go from gleam in your eye to sprint planning in 6 hours. There are weeks or months of organizing, scoping, fundraising, etc. During that, many things happen. Why can’t I do some needs research and then build IAs and draw entire UI specs during that time? They might help prove (or disprove) your idea before you get too far.

No reason. I have. Most Agile projects I have worked on did this. We did a target design up front, at the same time the DBA and system architects and everyone else was doing their design work. You did know you have to design before you build, right? This is about efficiency, and building the right product for your customers, right?

Some of my most successful projects have done this, and often it extends to UX writing Stories. Not by pulling them out of our great intellects, but by using lots and lots of research to understand what the user wants, and collaborating with business and technical teams to make sure that is wanted and can be built.

And design/specify up front doesn’t mean you can’t change. Sit with your DBAs for a few days and see how much they build and throw away work vs spending time to design then implement a single flexible solution.

This appears to be iterative, but is some spiral, not an agile step by step thing. Must be a mistake.

I do love the principles of Agile, but principles are not processes. I hate Lean a bit less as there are few Lean coaches that come in and make presentations for two days full of baseball analogies, and require you to follow Their Exact Process.

Be quick, be efficient, balance organizational needs with being end user focused, but most of all be yourself. Follow the method that works for your team and organization, instead of any trend. There is no magic potion so don’t go looking for it.