Sean Kennedy
Sean Kennedy
January 19, 2017

Whole Team Design Thinking

There has been growing interest in and discussion of Design Thinking, however, as Cait Smith wrote, many limit themselves with a “lingering belief that design thinking is only applicable to designers or those in product development”.

Organizations with that limiting belief, tend to either:

  1. Do all their Design Thinking “up front” instead of iteratively and through team expertise and speed avoid all implementation challenges and market changes that would knock that work out of alignment
  2. Count on some super human who can be the Master Designer throughout the product lifecycle personally integrating all learning and directing all necessary adjustments

Interestingly, organizations can make these approaches work.
Unsurprisingly, most organizations are not among the ones that can.

Over my time with PointSource, we’ve been uncovering ways of approaching problems, selecting solutions, and working together, that has enabled a wide variety of organizations to delight their users. Our experience is that the combination of Design Thinking and Agile principles makes it possible for more, maybe most, organizations to regularly and reliably realize the benefits of both.

As a software developer who has spent his entire career in the post-Agile Manifesto industry, I look at our success applying Design Thinking through the lens of mainstream interest in Agile. While neither concept is new, I think the combination of Design Thinking and Agile is an important practical breakthrough. It helps us consistently delight users, while addressing business priorities, with the least amount of risk, as fast as desired.

Agile Development and Delivery – Scrum and DevOps

Ever since my third-year Computer Science Object-oriented design course, I’ve been working on Agile teams (or, at least, working to make that a true statement). As software development professionals, we’ve had an enormous impact on the world through our determination to apply the principles of the Agile Manifesto. By adapting and applying the “better ways of developing software” that we uncovered and shared, the value and pace of working software has never been higher. Still, for many organizations, large and small, Agile has almost exclusively been applied to construction, while the rest of the necessary work proceeds in a traditional waterfall manner. This common state of affairs lead to the coining of the term Water-Scrum-Fall.Agile 1Compared to traditional software development, the pragmatic Water-Scrum-Fall approach represents a huge step forward in creating quality software with high business value and lowered risk.

In the spirit of continuous improvement, however, DevOps has emerged to extend the Agile approach “to the right,” into the “Fall.” Driven by a growing business appetite for faster and more frequent delivery, the application of Agile ideals to traditional QA and operations has spurred innovation in both technology and technique, such that organizations are now implementing Agile from development to production.Agile 2With Agile and DevOps teams now build and deliver working software whenever they want-need, even dozens of times a day.

Even with DevOps, however, we still have a whole bunch of “Water.”

Solving the Water Problem with Whole Team Design Thinking

Originally mainstream interest in Agile development drove many organizations to adopt and adapt Scrum. Similarly, later interest in Agile operations caused the emergence of DevOps. The current Design Thinking trend has been a catalyst for us, and I think others, to finally apply Agile practices to the work of the Scrum Product Owner.

Just as most organizations don’t have a superhuman to be a Master Designer, they don’t have a superhuman to be a Scrum Product Owner. Really, these are two names for the same magical, if not quite mythical, role. A role that carries the expectation that the market, the business and the technology, can be (perfectly) understood by a single person, and applied to the product at hand, to provide users with a delightful experience.

With Whole Team Design Thinking, the whole team is responsible for delighting the user, and collaboratively bringing their experiences and expertise to bear on the problems at hand. Just as in Lean Manufacturing, any worker can stop the assembly line when a problem is detected, in Whole Team Design Thinking, any team member can instigate a collaborative application of Design Thinking to solve problems uncovered anywhere in the product lifecycle.

Agile 3

Whole Team Design Thinking is a collaborative approach to delighting users and maximizing business value.

Whether it’s a developer noticing a more efficient way of implementing a UI design if only the design were slightly altered. Or a tester realizing that regression testing could be reduced for many changes if the system had a different architecture. Or a business analyst discovering an emerging market need that the product doesn’t address. Whatever the case, with Whole Team Design Thinking no one proceeds by blindly “following a plan” or by blindly changing it without engaging the team and their range of experience and expertise.

Agile Product Delivery

Whole Team Design Thinking is the result of integrating Agile principles and practices and Design Thinking. Considering all the effort it took organizations to get to Water-Scrum-Fall, no one should expect to start doing Whole Team Design Thinking overnight. Still, for an organization that has implemented Water-Scrum-Fall, and may already be starting to apply DevOps, Whole Team Design Thinking should be on their strategic roadmap for process improvement.

Very few companies can choose not to delight their users without adversely affecting their perception and market share. If you are looking to adopt and apply Design Thinking in your business, it should be for the Whole Team, and our team is ready to help you do just that.


Filed under:

If you like this, you'll like these:

More Blog Posts