Thread by @johncutlefish

Heard (again) that #design and #ux is somehow incompatible with #agile (which to most, means #scrum).

..that ppl can’t always jam their work into little increments

..that MVPs suck because they’re never improved

..that work can’t always be boiled down into a “ticket” 1/n

...that #design is more than screens...a more holistic view is needed

...that an output fixation is killing products

...that quality shouldn’t be sacrificed just to get stuff out the door

...that craft should be respected

...that #ux debt sucks 2/n

...and you know what? Those exact same things are muttered by engineers/QA all the time.

They have nothing to do with #agile, but everything to do with paint-by-numbers approaches to “delivery”, org silos, and overly simplistic “#design then build” models. 3/n

Engineers and #design tend to both care very deeply about the impact of their work.

As equal members of a team (and that’s the crux), there’s plenty of room for “inspect and adapt” and figuring out something that delivers value to customers and feels good as a contributor 4/n

Finally... this idea that [insert function X] needs to figure out how to “do #agile” is wrong. Do what works, and in so doing, you’ll draw from SOME patterns/approaches that fall under the Agile umbrella, and many that do not. #agile is ideas and a community, not rules. 5/5