Last Tuesday we were excited to host the most recent event in our Executive Leadership Roundtable series. This time the topic was focused on the intersection of human-centered design and agile software development methods. It was a really insightful event with a panel that included experts from Cars.com, Trunk Club, Northwestern University, and DevMynd.
There were some fantastic insights that came out, not just from the panel discussion but the conversations over dinner. I’m going to share a few things that stood out to me. And, if you have an opportunity to attend one of these events in the future please do, the networking and content are always top notch (if I do say so myself).
Motivation, Value, and Satisfaction
One thing that was discussed, rather at length, was the fact that designers and engineers often approach their work from different motivations, different ways of measuring success, and deriving satisfaction from different sources. This is, of course, an overgeneralization as there is, in fact, more alignment than the previous statement may imply. But nevertheless, these slightly different worldviews can create friction at times.
For example, the act of delivering working software to production, with a low defect rate, high performance, and on-time is satisfying to software developers. While that same team’s designers are more satisfied that an end user’s needs are met in a new and intuitive way. These two are not polar opposites and in general can very much be in alignment. But, a system which does not meet a user’s needs, though delivered with high-quality code, will not bring satisfaction to a designer. Similarly, a product which surprises and delights users, but which is difficult to maintain and was delivered over-budget will still leave engineers wanting more.
This gap in the worldviews is a double-edged sword. In some ways, both sets of motivation are critical to a project’s success. “The most beautiful and effective design, when left unexecuted is merely art”, as one panelist stated. Yet, the most excellently crafted code is useless if it does not meet needs. So, this tension is healthy when appropriately moderated and acknowledged.
Systems and Foundations
Several of the panelists arrived at a similar conclusion that the creation of systems and foundations are necessary on both sides before a team can be truly agile. For example, until a product’s core business capabilities are in place much of the development team’s work focuses in this area. However, this is often merely a slog through the basics of a business which could mean little real innovation. And, until these fundamentals are in place these innovations must take a back seat.
Once the foundation is laid, however, iteration on the fringes can happen much more rapidly. Design can drive the product forward at a more rapid pace. And over time the cost of change should become much lower.
Similarly, developers can move much more quickly when there are a set of established user interface and interaction patterns available. When designers are rapidly changing things that widely affect an application it is hard for development to keep up. The creation of GUI-kits here can be a great help to developers who can move to working off of collaboratively created wireframes rather than requiring full-screen compositions.
Pacing Is King (but Difficult)
Another element to the discussion revolved around the ebb and flow of pace for both of these disciplines. While design teams can often timebox more of their work, the activities will shift dramatically throughout phases of a project. For a few weeks, the designers may be engaged in direct end-user research, then shift into an analysis and prototyping mode, then finally begin fleshing out interfaces. But all the while, the developers are continuing to push through a backlog while the pile of ready-to-go design work begins to shrink.
This misalignment in pace can be addressed, however. Some organizations have moved to a model which compresses the research -> analysis -> UX/UI design cycle to more closely align with the size of a development sprint. While this is not always possible given the scope of a particular problem or the logistics of research, when it works it keeps the pace much more even across the team. The downside can be that design teams are looking at a narrower view of an experience at any given time. This must be balanced by occasionally zooming out to view the entire product holistically.
Abstraction Brings Us Closer
One thing that the engineering leaders on the panel noted was the impact that time has had on the maturity of our abstractions. Meaning, that over time, open source and other platforms have become increasingly capable and are now freeing developers to focus on higher-level business concepts. For example, at the platform level, abstractions such as Ruby-on-Rails have made building web applications and APIs much easier. This means less focus on low-level technical tasks and more focus on the business domain. At the component level, third-party microservices are doing the heavy lifting of single-sign-on authentication or SMS messaging with just lightweight API calls.
The net effect of this abstraction is that developers are more often able to spend time in the world that has traditionally been closer to design: the world of the user. This naturally pulls both sides closer together and fosters shared language and shared objectives.
Of course, not all developers can play at this high-level. There will always be the need for engineers who build compilers and databases. But the bulk of application developers can now take advantage of these abstractions to move their thinking closer to the user and therefore closer to that of a designer.
Organizations Don’t Really Understand Agile
Lastly, the whole panel agreed wholeheartedly that the vast majority of organizations do not practice agile, but rather adhere to some loose set of techniques that masquerade as agile. One panelist actually pulled up the Agile Manifesto on his phone during the discussion and proclaimed: “the manifesto is actually really human-centered and not at all about sprints, standups, or SCRUM” – everyone agreed.
This, of course, begged the question: Well, if they aren’t doing agile very well then what is “well done” agile? There are numerous ways to answer this question and no particular methodology is a panacea for how to do it the correct way. But one panelist (in my opinion rightly) called out that what is needed is a shared set of principles for any product team. Not design principles, not agile principles, but [INSERT NAME OF YOUR BUSINESS]-principles. These principles need to answer the question: how do we, at XYZ company, want to be agile and human-centered?
—-
This was a truly insightful and challenging discussion. We heard from myriad perspectives, even opposing in some cases. But the thing that made it work was mutual respect and an expectation of trust. For me, these two things, respect, and trust, are the ultimate keys to successful teams that integrate designers and engineers.
