Agile ownership concepts
Most Agile folk are familiar with the Chicken and the Pig story.
While some think of it at face value and think they get the point of commitment, I actually think that it's also about ownership.
Who owns the product?
In a recent Agile Philippines meetup, I was asked by a scrum master, "Who pushes for the design thinking? The product owner? The scrum masters? The designer? Who does that?!"
My initial thought was, it probably is those people who own the product development and design.
So I quipped, "well, in our team we believe everyone is involved in the product..." and briefly explained about Design Thinking and how it is about figuring out the right problem to solve, before starting to design a solution for it.
Following this Chicken and Pig analogy, I think that the team has the ultimate control and their effort estimates, while they are "estimates", they still have ownership, and hence commitments. Agile has always been about the team. I thought about it some more, and I now realize maybe what he meant was - "Should scrum masters be designers now (aside from being familiar about the technology )??!".
I think if we are on the mindset of #OneTeam, the answer is yes! Roles are very important in Agile as mentioned in the article, but there are certain roles that overlap with each other. The days of when people had roles wherr "You are only responsible for one thing, and onlu one thing", are over.
Today, many functions that were formerly taken by teams with different niches, have merged. There are now "full-stack" developer roles, which expects you to both a developer that can take responsibility for every aspect of application development, frontend, and backend, but be able to manage and communicate well.
One of my favorite parts of Agile is the poker planning phase. For those who don't know, poker planning is the process of estimating story points by using scrum poker cards. The way it is done is the scrum master shares about the problem or task, and the team (the people who will be developing the product) discusses how much points they should estimate the effort by dropping their fibonacci-numbered cards in the table at the same time.
From a Project Management perspective, the other thing to consider is time, resources, and cost. "Is there enough time to do design thinking?". "Do we have enough users to interview?". "Can the dev team work on the solutions that they have in a cost-effective manner?"
I think one can find a way for teams to add Design Thinking to their process, maybe it can be a part of requirements gathering phase. The point is, everyone works together in development. I think that it isn't just something that the designer or devs or the other stakeholders should push for. It should still be a team decision, after the designers have shared their thoughts, if additional process like Design Thinking is useful for the team.
Sometimes however, for simple features that don't require a lot of interviewing with the user (user research), Design Thinking is overkill. Sometimes, all you need is just some common sense.