One thing I’ve tried to do this year is to read and listen to things from outside the field of design. A desire to get different peoples perspectives on things. What’s been most interesting about this has been the parallels I've drawn between the types of discussions that go on in each field. Be it a blog, talk or interview; they often look similar:
- Designers talk to other designers and frame things as ‘design issues’.
- Marketers talk to other marketers and frame things as ‘marketing issues’.
- Sales people talk to other sales people and frame things as ‘sales issues’.
More often than not, there’s sizeable overlap between each of these issues. Sometimes they’re the same issue. But how they’re interpreted often depends on who’s looking at them.
Here’s an interesting talk from two notable people in the field of software development.
To any non-developer, it surely must be a domain that is full of robotic-like logicians who are only concerned with computer code and not the human needs, right?
Two of the illustrative examples in the video (one about communication, one about two types of ‘process’) could easily find their way into any ‘design’ talk. One of the most fascinating things I’ve observed about the software developer community is how progressive they have been in fostering better team collaboration and breaking conventions of project management. Something other fields should envy. Even when the community gets perhaps over-excited by a new methodology that appears to work – be it Agile or scrum – they’re often the first people go back and question it. Is still relevant? Does it still work? How could we do things even better?
One of the most pragmatic descriptions of software I’ve heard someone say was: “Software is a new type of building material that we’re still trying to figure out how it works. The beauty is that it can be both wrong and changed.”
The last part of that quote sums up perfectly the rationale behind methodologies like Agile. Planning, especially for big, challenging projects, is useful. But the plan itself useless. It always changes. Scope creep. Shifting requirements. Competitor activity. Whatever it is, it changes the original plan. Admitting this allows teams to remove the shackles of the 'planning fallacy' and operate appropriately. We should expect the plan to change all the time. So let’s proceed regardless and course correct as we go.