There's a contradiction at the heart of agile practice that only design can resolve.
Agile requires iteration. Build, release, learn. But engineers are used to iterating internally. Find a bug, fix a bug. Ship when bugs = 0.
Design cycles thru exposing unfinished work to users.
Agile requires iteration. Build, release, learn. But engineers are used to iterating internally. Find a bug, fix a bug. Ship when bugs = 0.
Design cycles thru exposing unfinished work to users.
When designers bring work to test with a user, it's usually nowhere near done. The goal is to understand which direction to evolve it in. Designers can be satisfied with an obviously flawed output because they know that it will lead to learning, and the flaw will soon be fixed.
Engineering practice IME is not like this. A lot of up-front work goes into building scalable, stable systems that use the latest technology, work end-to-end, and anticipate evolving product needs.
I think that engineers should be a bit more like designers in this respect.
I think that engineers should be a bit more like designers in this respect.
Starting with the fancy tech and trying to learn it on the fly and get it right shouldn't be done up front. Figure out what you want to do using cheap, familiar guts - and only then turn to the how of it.
Of course, a lot of engineering practice evolves out of organizational constraints. Many engineers have been burned by building quickly, and then having refactoring cut short by PMs pushing aggressive deadlines.
Trust is the keystone of good design, as well as good code.
Trust is the keystone of good design, as well as good code.
Rather than optimizing engineering practice for low-trust environments, it could be more effective to look at how you could build up trust between different groups. And that requires a certain amount of vulnerability and yes, empathy. I wonder who's good at doing that? 😏
