Effective Solutions Through Partnership

Category Archives: Design Thinking

How our Team Performed Remote Design Thinking

Continuous Improvement, Decision-Making, Design Thinking, Digital Transformation, Information Technology, Innovation, IT Modernization, KAI Partners, Organizational Change Management (OCM), Project Management, Project Management Professional (PMP), Team Building, Technology

By Terry Daffin, PMP and Denise Larcade, Prosci

KAI Partners has recently been using design thinking to help create new products and improve existing processes to support the work we do for our clients. Even before the stay at home orders, one of our design thinking teams held a design sprint that was done almost completely remotely—and resulted in a product ready for implementation!

Here are some of our experiences and what we learned through our remote design thinking experience.

Remote Design Thinking Challenges

As with using any kind of new approach or methodology, there were some challenges and we certainly went through the 5 stages of group development: Forming, Storming, Norming, Performing, and Adjourning.

Working remotely added another level of complexity with the addition of anonymity or facelessness. With a lot of strong personalities on our team, it was easy for some folks to disengage from the group.

So, how did we get past this?

To get through the storming phase, we had to work together to develop trust and respect.

True trust and respect empowered the team and were ultimately what led us to the norming and performing stages.

Because we met virtually (over Zoom) once a week, we had to become more vocal than usual. It was not uncommon for members of the group to speak up in order to keep others on task so that we did not go down a path not in scope or bring up topics that should be added to the backlog for future discussion.

Remote Design Thinking Successes

Despite our initial challenges, we did make it to the norming and performing stages! How?

We didn’t wait for people to join in order to begin—we jumped right in and started working.

What made this easier were our tools—we used MS Teams to share files, document meeting notes, have team conversations, and even to build our prototype. There was rarely an occasion where people felt out of the loop, because all the notes, resources, and information were right there in Teams.

Working remotely also allowed us to reach more people, cross more boundaries, and include more perspectives, as opposed to in-person coordination.

People are busy (and that’s a different problem for another blog post!) but working remotely gave more people the opportunity to participate and contribute.

Self-Organizing Team Tips

Part of our remote design thinking method was to truly self-organize within our team. Here’s what worked for us:

Set expectations and make team agreements from the start.

Because there was not one person designated as our “Lead,” we created a list in Teams with the Facilitator and Scribe for each meeting. If someone was unable to Facilitate or Scribe on their appointed day, it was their responsibility to find coverage.

This helped promote ownership—we were all one team of equals and therefore equally responsible for the team’s success.

Of course, since we are a firm that provides organizational change management (OCM) services, OCM was always on our mind. Design thinking was new for some folks and people are often wary of change. Assigning the rotating roles was a good way to share the workload and learn a skill—we were all in this together!

Another tip is simply to have patience. We were learning a new way of working and change is hard. Trust and respect had to be established and re-established and that process took patience!

At the end of the day (or sprint), it was satisfying to see how we created a product through sheer teamwork—even though remote design thinking was a challenge at times, the final product was worth it!

Have you done any kind of remote design thinking work on your team?! Let us know your experience in the comments!

About Terry: Terry Daffin is an Executive Consultant within KAI Partners. He has worked in the IT industry for more than 30 years and has over 25 years of project management experience. As a public sector consultant in the health care industry, Mr. Daffin assisted in the development and implementation of Project Management Offices that include project management, service management, lean agile and traditional product development lifecycles, and governance processes. He has been an innovation advocate and evangelist for 15 years and has implemented innovative processes for projects that he has been engaged in since 2001. Mr. Daffin currently works as the Project Manager of the KAIP Academy, KAI Partners’ training division and is the Community Manager at KAI Partners’ coworking space, The WorkShop Sacramento.

About Denise: Denise Larcade is an Organizational Development Consultant and Merger and Acquisitions Expert. She is a Certified ScrumMaster, Certified Scrum Product Owner, Lean Six Sigma Green Belt, and is Prosci certified. She has over 25 years of experience in training, development, and leading companies through organizational change management. Denise has worked in corporate retail, technology, and government healthcare and most recently has experience with large-scale implementations nationwide. She currently works as an Executive Consultant with KAI Partners, Inc., providing client support to KAI Partners’ state clients. Denise lives in a 55-acre walnut orchard and enjoys the early morning hours when wildlife is stirring and the many birds are chirping. Since working from home as of recent, Denise has found she enjoys that extra cup of AM coffee without the commute…just her and nature.

Software Development: The Ever-Changing World of Waterfalls, Sticky Notes, and Sharpies

Agile, Design Thinking, Digital Transformation, Information Technology, Innovation, Innovation in the Public Sector, IT Modernization, Learning, Organizational Change Management (OCM), Project Management, Project Management Professional (PMP), Public Sector, Scrum, Software Development, Technology, Waterfall

By Sid Richardson, PMP

Raise your hand if you’ve run a software project using the Agile Methodology and have run a software project using the more traditional waterfall project management methodology? I’m sure there are many of you!

Having worked in project management for nearly 30 years, I have run software projects using a variety of different methodologies and I can certainly appreciate the benefits that they all bring to the table.

One true constant in life—and in software development—is change, and I’ve seen my fair share. Here’s what I’ve learned along the way.

The ‘80s were RAD

In the mid-1980s, a software development methodology called Rapid Application Development (RAD) began to take off.

James Martin developed the RAD approach at IBM and formalized it in 1991 by publishing a book called Rapid Application Development. The RAD approach was based on working closely with the customer and prototyping solutions quickly to deliver a final product. The intention was that there would be less effort placed on the planning aspects and more on the customer collaboration aspects.

While RAD was not necessarily a true project methodology for software development, I believe it led to an easier buy-in to the Agile project methodology many of us use now.

Meeting the Requirements

When I was working in Europe in the early-to-mid 1990s, there was a heavy emphasis on formal approaches to project management and software projects. This may sound strange—or it may provide flash-backs for some of you!—but I remember a time when absolutely no analysis or design work was allowed to begin until the user requirements (typically volumes of paper in large bound files) were received in hardcopy form with sign-off by senior company executives.

Can you imagine working in that type of environment?

The traditional waterfall approach to software development projects was rather rigid, but I can understand the reasoning—the leadership wanted to have a high level of confidence in what would be delivered.

Fragile Agile

Fast forward to almost 20 years ago and many organizations encountered internal pushback and some challenges with the adoption of Agile as a software development methodology. The common joke thrown around in the middle of an Agile rollout was that it was “Fragile.”

Since the requirements in an Agile methodology are more dynamic, things eventually settled down and as someone said to me recently, “I guess we’ve come into an age of sticky notes and Sharpies.”

Design on My Mind

At KAI Partners, we have recently started using Design Thinking. Design Thinking provides a creative, solution-based approach to solving problems and is also sometimes known as human-centered design or user-centered design. It’s on the side of creative problem solving, which—being a creative type of guy—is why I gravitate toward it.

Design Thinking encourages organizations to focus on the people or the customer—and it’s the people-centered focus that leads to better products, services, and processes.

While it’s not a software development methodology, Design Thinking can be used as a problem-solving tool to accompany almost any software development methodology you choose to use.

Is there a Perfect Approach?

So, with all these different methodologies, is one better than another? Well, it depends on the project at hand!

One of the common drawbacks to the RAD approach of the 1980s was the lack of scalability. RAD typically focused on small to medium-sized projects and teams. Then Agile came along in the early 2000s and, as a lean philosophy, could certainly be applied at an enterprise level.

What I think works best is a blended methodology that combines the best features of a variety of different approaches.

If the last 30 years in project management and software development have taught me anything, it’s that there are components and approaches of many different methodologies that—when combined—can make a robust and flexible way to deliver high-quality, timely products to the customer.

And, considering that a new methodology will likely make its way to the surface soon, we can’t get too comfortable. Luckily, as project managers and agents of change, we are used to the continual cycle of change and it will be up to us learn the new methodology, prepare our teams, and adapt our work accordingly.

Need support on your next project? KAI Partners can help your organization implement the software development methodology that works best for you and your needs!

About the Author: Mr. Richardson’s passion is Data Warehousing, Business Intelligence, Master Data Management and Data Architectures. He has helped Fortune 500 companies in the US, Europe, Canada, and Australia lead large-scale corporate system and data initiatives and teams to success. His experience spans 30 years in the Information Technology space, specifically with experience in data warehousing, business intelligence, information management, data migrations, converged infrastructures and recently Big Data. Mr. Richardson’s industry experience includes: Finance and Banking, government, utilities, insurance, retail, manufacturing, telecommunications, healthcare, large-scale engineering and transportation sectors.

When is Project Management not Project Management?

Continuous Improvement, Corporate Training, Design Sprints, Design Thinking, Digital Transformation, Government, Information Technology, Innovation, Innovation in the Public Sector, IT Modernization, Learning, Project Management, Project Management Professional (PMP), Public Sector, Sacramento, Technology, Training, UX / UI

By Tammy Debord, MBA, PMP, PMI-ACP, CDAP, SAFe Agilist & Scrum Master, CSM

Luckily, this isn’t a trick question. Have you ever heard the phrase, “It’s more of an art than a science.”? This holds true for many different endeavors in life and business, including Project Management.

The Way we Approach Problems is Changing

As a Project Management Professional (PMP)® for over 12 years, here is what I’ve learned—think of it as two different buckets of knowledge.

Let’s call Bucket A: “The Science.” This may include:

  1. Project Management Certifications (PMP, CSM, SSM)
  2. Project Management Frameworks (PMI, SAFe, Disciplined Agile, FLEX)
  3. Project Management Process and Artifacts (Project Charters, Agile Release Trains, Six Sigma Flow Chart)

Bucket B: “The Art” includes things like:

  1. Building psychological safety
  2. Driving innovation
  3. Empowering self-organizing teams to deliver valuable solutions

While the science is absolutely needed, without the art, we have to ask: Would we still consider it a successful endeavor?

I have witnessed a shift from only defining success through costs, dates, and deliverables to instead broadening the definition to include delighting our customers, building a high-performing team culture, and criteria that includes more items from Bucket B.

Design Sprints to the Rescue

Intrigued by this shift and how it relates to my work as consultant, I recently signed up for a Masterclass by Jake Knapp called The Design Sprint.

Design Sprints, born out of Google Ventures, is now practiced across the globe as a proven method for problem-solving and launching innovative solutions.

A Design Sprint traditionally runs four to five full consecutive days with a set number of team members who are pulled together to focus on a core problem. The structure follows the path of Design Thinking, which includes: Empathize, Define, Ideate, Prototype, and Test.

At its core, Design Thinking is user-centered and focuses on rapid learning based on human interactions driven through a tailored process that drives to solutions.

5 Design Sprint Tips

  1. Show, don’t tell. Facilitators encourage visuals like sketches, prototypes, and dot-voting over traditional meetings where participants typically just talk about ideas. Having a dialogue using an interactive medium helps to eliminate assumptions when people only describe what they mean.
  2. Put people first. People oftentimes drive your greatest outcomes or are your biggest barriers. Projects are not inanimate things to manage.
  3. Frame and re-frame. How you frame a problem allows you to find the right challenge to tackle. “How might we…?” problem statements allow participants to try many different lenses to a particular challenge.
  4. Embrace ambiguity. Sometimes situations won’t be clear and your cheese will be moved—when that happens, stay the course and push through with your team.
  5. Context matters. Whether you are in a new organization or another country, every ecosystem has their own culture, language, and norms to which you should recalibrate.

While I did earn a certification to add to my collection (think Bucket A: The Science), what I take with me is that the “art” of running a successful Design Sprint is the same “art” as running a successful project.

It takes a different part of the skills in your toolbox to master both—the best consultants I know have the best toolbox to pull from.

Put Your Skills into Action

A couple of ideas from the Masterclass that I have been able to use immediately in my current higher education consulting work are:

  1. Re-framing the problem
  2. Understanding context

For example, when developing an application, it is easy to believe the end goal is simply ‘completed functionality.’

By reframing the problem with the user in mind, i.e., “How might we ensure a student is able to combine and transfer their units online between campuses?”, we ensure that what is developed meets the needs of a solution beyond working code.

This could mean ensuring the underlying data needs to be revisited or that a mobile-first user experience better serves the population using the application.

By understanding context, we may discover we need to know more about the upstream or downstream applications that units are coming from or feed into so that the student has a tool that can meet their needs.

By reframing the problem and understanding context, we refocus using an empathetic lens through a technology solution.

These are just a few ways I’ve started using Design Sprint concepts in my work—do you use the Design Sprints or Design Thinking concepts? Let us know some success stories or problem areas—maybe we can help!

About the Author: Tammy Debord, MBA, PMP, PMI-ACP, CDAP, SAFe Agilist, SAFe Scrum Master, CSM started her career in gaming at Sony PlayStation and has worked in several fields including Solar, Higher Education, and Finance in Silicon Valley. Currently she is an Executive Consultant with KAI Partners, working with a public sector higher education client. While not collecting letters behind her name as part of her love of life-long learning, she enjoys watching boxing and following the Marvel Universe of films.