integrating design thinking principles into agile · agile is about delivering design solutions by...

Integrating Design Thinking Principles into Agile

Integrating Design Thinking Principles into Agile

W H I T E PA P E R

500 S. KRAEMER BOULEVARD, SUITE 301, BREA, CA 92821 (714) 579-7979 NISUM.COMPG. 2

Table of Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Similarities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Why Use Design Thinking & Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

How to Combine Agile and Design Thinking . . . . . . . . . . . . . . . . . . . . . . . . 4

The Power of Paper Prototyping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Build the Right Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Creating Behavior Driven Development (BDD) User Stroies . . . . . . . . . . . . . . . 9

Design Thinking centric Retrospectives . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Who We Are . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

500 S. KRAEMER BOULEVARD, SUITE 301, BREA, CA 92821 (714) 579-7979 NISUM.COM

IntroductionIn the article, The blurring between Design Thinking and Agile, Matt Cooper-Wright,

Senior Design Lead at IDEO states that “…Design Thinking lives in the strategic world

where we use design methods to find the right question and begin to answer it . Agile

lives in the software world where once a question is asked teams iterate toward a

solution .”1 Thus, in order for teams to produce cutting edge high quality products

and services, they need to live in both the strategic and software world . This is often

a difficult task for teams especially when it comes time to start thinking about coding .

The purpose of this paper is to provide practical solutions for development teams to

incorporate Design Thinking principles into different phases of the Agile Software

Development Lifecycle (SDLC) .

SimilaritiesEmphasis on CollaborationDesign Thinking and Agile place emphasis on collaboration and people over processes .

In Agile, this is executed through ceremonies such as stand-ups, retrospectives and

planning . In Design Thinking, collaboration is achieved by bringing groups of people

with different backgrounds and specializations together to resolve a problem .2

Iterative or Ongoing RefinementBoth practices focus on iterative or ongoing refinement and development via feedback

loops and channels . In Agile, this is done via development iterations, delivering the

Minimum Viable Product (MVP) . In Design Thinking this is done through the creation

of feedback loops throughout the discovery or design SDLC phases .3

Focus on EmpathyThe Agile Manifesto puts emphasis on “individuals and interactions over processes

and tools” .4 “Empathy is a psychological trait in which one possesses the ability to

understand and share the feelings of another” .5 In Agile, empathy is not just essential

to ensure a good team environment, but it is also essential to ensuring that the team

is truly building a product end users will want . In Design Thinking, activities such

as empathy mapping, user journeys, and rapid prototyping are used to ensure that

human-centric products are designed .

PG. 3


DifferencesDegree of AgilityDesign Thinking tends to favor a fail fast approach . Since Design Thinking principles are often executed in earlier phases of SDLC processes it is much easier for teams to adopt or shift gears based on feedback . In Agile, learnings and feedback received during the previous iteration are often not implemented until the next iteration, therefore, it is common for requirements or information to be gathered and then, at most, be placed in the backlog .

Process ManagementDesign is often treated like a separate project process that has its own beginning, middle, and end, outside of the Agile software development process . In Agile, software can be deployed at any point and thus is often released in alpha, beta, or GA (general availability) stages . As a result, there are more opportunities to receive and implement feedback .6

Why Use Design Thinking & AgileDesign Thinking is about discovering users needs and determining or creating a solution to address them . It’s different then just “Design” because it’s focused on exploration, creating concepts and ideas for both new and existing products and services . Design Thinking helps teams to better understand their end users by focusing on why they do what they do and how software can help them do it .7

Agile is about delivering design solutions by focusing on small incremental design decisions that can deliver the most value possible to the market quickly . It is also about taking information from market delivery and adapting the entire implementation process . Agile allows teams to make truly empowered design decisions based on market feedback .8

How to Combine Agile and Design ThinkingDesign Thinking can be implemented in various phases of the Agile SDLC process . Here are 5 proven tactical activities software development teams can use to implement these practices:


Empathy Mapping“Empathy mapping is a way to characterize your target users in order to make effective design decisions . It is really just a tool [used] to articulate what you know about a particular type of user - their needs, goals, expectations, behaviors, pain points, etc .” 9 Empathy mapping is usually completed as part of the Discovery or Inception Phase .

Follow the steps below to guide your team through an Empathy Mapping session:

What’s Needed? ▪ An Empathy Map Template ▪ The Product Owner, Development Team, and key stakeholders that understand the

end users needs

Steps

1. Facilitate a discussion by first introducing the persona that will be used during the session . Note that a session can include more than one persona if needed and that this step can be skipped if your team already has a persona .12

2. Continue the discussion by defining the situation or problem that needs to be explored . For example, is your team exploring the persona’s emotions towards you changing the UI design for a specific feature or is your team exploring how


the persona may act in a particular situation? Once this is determined, the collective assigns the personas a name and background, if not already given .12

3. Next, divide the team into groups . This is especially beneficial if there are multiple personas so groups can focus on one persona at a time . If there is only one persona, have each group focus on one of the areas on the empathy mapping template (e .g . Think & Feel, Hear, See, Say & Do) . It is recommended the groups think about:

▪ Why your products and/or services are used ▪ What they may feel or experience when they use your products

and/or services ▪ What, if any, external sources and influencers might impact them when

they use your products ▪ What are your users core values? What do your user stand for and why? 11

4. After, each group completes their persona or section of the persona, the collective team should regroup and present their findings .

5. (Optional) Take your Empathy Mapping session to the next level, by adding additional sub-sections “Pains” and “Gains” to the Think & Feel area on the Empathy Map template . The Pains subsection is used to allow teams to better understand what user fears, frustrations and anxieties are . The Gains subsection is used to allow the team to explore what the users hopes, dreams, and desires are .13

Empathy Mapping is a tool designed to help give teams better insight into what an end users’ expectations, desires, and fears are . By focusing on the end users via Empathy Mapping, teams can bridge the gap “between the virtual persona and the consumers’ real emotions and what they feel toward specific productions, situations, or services” .12 Overall, it’s a “short time investment with a huge impact on the innovation process as it contributes to achieve empathy in the final product .” 12

The Power of Paper PrototypingPaper Prototyping is not new but it has recently gained traction due to the increased use of Agile design methodologies and best practices which focus on human centric designs and principles . Paper Prototyping is a exploration method that allows the team to explore, visualize, test, and design ideas with very minimum time and cost .14 Similar to Empathy Mapping, Paper Prototyping is usually completed in the Discovery or Inception phase but it can also be used during the Development phase to design, visualize, and test technical designs .


There are several common approaches and tools that can be used to facilitate a paper prototyping session . This paper highlights how to use low fidelity sketches during the creation of the Technical Architecture Design . This a good exercise to do before replatforming, building out any new major features, or before starting a major UI/UX redesign . Low fidelity sketches are rough sketches usually completed on paper . These types of sketches are great for self brainstorming and internal team discussion .14

Follow the steps below to lead your team through a low-fidelity, high-level technical design session using paper prototyping:

What’s Needed? ▪ A few large sheets of paper (preferably poster size) ▪ Sharpies or markers (different colors) ▪ Post-its (any size)

1. Have the technical team draw out the current design on one of the sheets of paper . The design should be created with one of four architecture domains in mind . Pradhan best summarized the domains:

▪ Business Architecture (Why domain) represents the business-centric view of the enterprise from a functional perspective . Business processes, business services, and business rules are defined and designed along with the business operating model, business performance goals, and organizational structure . Architecture at any level, starts from this domain and cascades down to technology architecture . ▪ Information/Data Architecture (What domain) describes the data assets and

management resources, such as information catalogs, data models, data- flows, data quality, and data security, to support critical business functions and the governance models to share data across enterprise . ▪ Application/Service Architecture (How domain) provides the blueprint for

applications and services and their alignment with other business processes and services . Application architecture defines the logical and physical components, object models, process-flow, and cross-cutting concerns such as caching, validation, transaction etc . ▪ Technology/Technical Architecture (Where domain) addresses the

technology stack, data center, cloud delivery, network topology, and security architecture . The technology stack includes server, storage, virtualization, operating system, and middleware .” 16

2. Next, have the team discuss and identify the pain points in the current design . It is helpful to use a different color marker to circle the pain points .

3. Have the team discuss and identify the gains in the current design . What about the current design is helping the team deliver high quality products and services? What components or areas offer opportunities for future expansion or growth? It is also


a good idea to highlight or circle these areas .

4. On a new piece of paper, build a new diagram that takes into account and/or addresses the pain and gains area highlighted on the previous diagram .

Build the Right TeamIn Design Thinking, a good team should consist of a cross-functional and multi-functional team . There should be a mix of individuals that specialize in a variety of areas from technology to business to end users’ needs . Additionally, if possible, the team should contain individuals who have specialities “associated with problem areas contributing but not dominating the user’s journey” .17 These individuals often work in client or end user focused departments such as Customer Service . While these individuals might not be very technical, they are often impacted by technology decisions and can provide an outside perspective to the team during the development process . So, how do you know if you’ve built the right team? And how to do you know who, when, and where to involve different players throughout the SDLC process?

Stakeholder Mapping is a easy way for teams to “identify all of the players involved in complex interactions and to understand the means for which [the players] engage and communicate .” 18 It can also be used as a tool to determine when participation or input is needed from a particular set of stakeholders and to what degree .

To conduct your own Stakeholder Mapping session create the Stakeholder Mapping template (see below), form the development team, and designate the product owner .


1. As a team, create a comprehensive list of all stakeholders involved . When doing this, it is helpful to think in terms of both the technology and business partners . For instance, what individuals, groups, departments, internal and external systems or vendors would be impacted? 18 Who do you inform or involve through the SDLC process?

2. Use the Stakeholder Mapping template to determine which stakeholders have influence and interest in your product or project .

a. High Influence and High Interest: These are stakeholders that need to be fully engaged through the SDLC process . Examples of stakeholders that usually fall into this square are the Product Owner and the Development Team .b. High Influence and Low Interest: Stakeholders that fit into this category are usually executives that have set or defined the strategic initiatives, management, or planning for your product or projects . c. Low Influence and High Interest: Stakeholders that fall into this category are usually external development teams that you might have dependencies on, internal departments that will be using your products, or individuals that directly interface with your end users . These stakeholders need to be adequately informed to ensure that no major issues arise . If major issues do arise, these stakeholders often help with the resolution or mitigation of the issues .d. Low Influence and Low Interest: This group of stakeholders don’t need to be as informed as the groups highlighted above, however, occasional communication is required once any major milestones are achieved . Any feedback required from them should be monitored .19

3. Once, all stakeholders have been categorized, develop a communication plan for each stakeholder category . This communication plan can be as a simple as a Working Agreement that contains the following:

a. Type(s) of Communication Channel that will be used (e .g . email, Slack channel, JIRA tickets) to interface with each groupb. Frequency of communication and information format (e .g weekly status reports, sprint showcase, JIRA dashboard)c. How, when, and what type of feedback is collected, and by who

Creating Behavior Driven Development (BDD) User StoriesBehavior Driven Development (BDD) is a process that originates from Test Driven Development (TDD) . “BDD focuses on the behaviors of your system exhibits, rather


than the implementation details of it .” 22 BDD adds additional value to TDD tactics . By doing this BDD is able to:

▪ utilize the “Five Why’s” technique to ensure that each story’s purpose is clearly aligned with the expected business outcomes

▪ minimize waste by only implementing behaviors which contribute the most to the anticipated business outcomes

▪ describe behaviors in a way that both domain experts and development teams can understand

▪ focus on the business specifications as well as test cases 23

When creating BDD user stories, it’s helpful for your team to follow the format below:

▪ Title: The title should describe an activity and serve as a headline to describe what action needs to be taken by whom, and for what benefit .

▪ As a <end user> I need or want <feature or ability> so that <benefit>.▪ E .g . As a google .com user, I need the ability to see what links I’ve clicked on in the past while conducting previous searches so I can easily identify and access the links again, if needed .

▪ Background: The background should be a narrative written style section that at a high level explains the reasons (business case) the feature or ability is being requested . A good background will state:

▪ where the request came from,▪ what’s driving the request (e .g . did a specific event occur?),▪ what’s the impact of implementing the request (e .g . using the example above, users will save time when searching), and▪ what are the consequences of not implementing the request .

▪ Definition of Done (DOD): This section should define the high level acceptance criteria that needs to be completed in order for the product owner to sign off on the feature or ability .

▪ Scenario(s): Each story should contain at least 1 scenario in the Given-When-Then format . Scenarios are often best represented as a sequence of events and thus should be displayed in sequential order . You should be able to line up each scenario and understand the difference between each by the scenarios’ titles exclusively . These scenarios should serve as testing acceptance criteria . An ideal scenario format can be found below:

▪ Given <some context or a brief description > when <I do something> then <this happens> when <I do another thing> then <this new thing happens>.

▪ Continuing with the Google .com user example one scenario could be: ▪ searching from the search bar ▪ a web browser opens to the Google homepage ▪ the user enters “school” into the search bar


▪ previously clicked links related to ‘school” are shown on the results page in purple instead of blue

▪ Another scenario could be :▪ searching from the address bar ▪ a web browser is open and the browser setting is set to Google for search ▪ the user enters “school” into the address bar ▪ previously clicked links related to “school” are shown on the results page in purple instead of blue

Design Thinking Centric RetrospectivesDesign Thinking can also be easily integrated into a team’s retrospective ceremony . According to Breathe Agile’s article, How to make Retrospectives better with Design Thinking?, most Agile Retrospectives already align with Design Thinking process (see below)20 . The article highlights that both Agile retrospectives and Design Thinking have a similar objective, which is “to solve team problems” .20 By leading a team through a Retrospective that is focused on empathizing and defining critical problems, a team can better identify actions to test and implement to resolve problems .

Steps to Implement Design Thinking into Your Next Retrospective:

1. Empathize: As a team, brainstorm a list of problems or challenges that the team experienced while completing the sprint or release .

a. For example, did your team experience? Did your team run into any


communication breakdowns? Were roles and responsibilities not clearly defined, etc…Don’t be afraid, list them all out .

2. Define: Collaboratively choose the most important one for retrospective .

3. Ideate: Generate as many possible ideas to resolve the problem or challenge without judgement . There are no bad ideas .

a. For instance, using the communication breakdown example above, maybe the blueprint could be an actual list of Working Agreements the team would like to abide by .

4. Prototype: Pick 1 solution and spend some time discussing it . Create a solution blueprint .

a. For instance, using the communication breakdown example above, maybe the blueprint could be an actual list of Working Agreements the team would like to abide by .

5. Test & Implement: Come up with a test plan to test out your solution . Determine what necessary inputs are required to make your solution happen . The test plan should state when and how you plan to test or implement your blueprint .

a. Again, using the communication breakdown example, the test plan will contain information about when and how the team plans to test the Working Agreements before finalizing them and making them a permanent part of their development process . Ideally, in this example, the team should define a trial period of 1 to 2 sprints and then discuss how well the Working Agreements worked for them as part of their next retrospective .

Conclusion Design Thinking is a practical and creative way to problem solve quickly . It does this by guiding teams through a human-centric design process that allows for collaborative and iterative approaches . Having the ability to truly understand your end users’ needs does have a profound impact on a team’s ability to create high quality products and services that people will want to use .

Most problems and challenges that a team faces during the development process can quickly be identified and resolved during Design Thinking tools and practices . Design Thinking allows for teams to fail quickly in a safe environment ensuring that team evolves faster with low risks .

Design Thinking is not a framework that’s only effective during discovery or inception . Many Design Thinking practices and principles can be adapted and/or applied easily throughout the entire Agile SDLC . There are several different ways to integrate Design Thinking into the Agile Development process . The tactical activities mentioned in this white paper are only the tip of the iceberg .


References1 https://medium .com/front-line-interaction-design/the-blurring-between-design-thinking-and-

agile-ae59d14f28e32 https://www .linkedin .com/pulse/how-combine-design-thinking-agile-practice-tom-roach/ 3 https://medium .com/front-line-interaction-design/the-blurring-between-design-thinking-and-

agile-ae59d14f28e3 4 http://agilemanifesto .org/5 https://www .linkedin .com/pulse/empathy-agile-ricardo-vercesi-picoto/ 6 https://medium .com/front-line-interaction-design/the-blurring-between-design-thinking-and-

agile-ae59d14f28e37 http://www .thedesigngym .com/agile-design-thinking-competing-completing/8 http://www .thedesigngym .com/agile-design-thinking-competing-completing/9 https://medium .com/@harrybr/how-to-run-an-empathy-user-journey-mapping-workshop-

813f373706710 https://medium .com/@harrybr/how-to-run-an-empathy-user-journey-mapping-workshop-

813f373706711 https://www .absolute-design .co .uk/services/user-experience/user-journey-planning-what-is-an-

empathy-map/12 http://www .designorate .com/persona-empathy-mapping/13 https://medium .com/the-xplane-collection/updated-empathy-map-canvas-46df22df3c8a14 https://medium .com/digital-experience-design/a-guide-to-paper-prototyping-testing-for-web-

interfaces-49e542ba765f15 https://uxplanet .org/the-art-of-ux-sketching-and-paper-prototyping-5dae5a1efc7d16 https://www .infoq .com/articles/admit-architecture-framework17 https://www .interaction-design .org/literature/article/design-thinking-select-the-right-team-

members-and-start-facilitating18 https://static1 .squarespace .com/static/56982380cbced6aeb746c533/t/5723775b356fb098e46b5

2b8/1461942107575/ihdt_chewable-protocol_stakeholder-mapping_4-29-16 .pdf19 https://www .mindtools .com/pages/article/newPPM_07 .htm#Interactive20 https://breatheagile .net/better-retro-with-design-thinking/21 https://revelry .co/behavior-driven-development-bdd/22 https://www .linkedin .com/pulse/agile-development-difference-between-tddatddbdd-

komal-sureka/23 https://www .agilealliance .org/glossary/bdd/#q=~(filters~(postType~(~’page~’post~’aa_book~

’aa_event_session~’aa_experience_report~’aa_glossary~’aa_research_paper~’aa_

video)~tags~(~’bdd))~searchTerm~’~sort~false~sortDirection~’asc~page~1


Who We AreNisum enables transformation for industry-leading brands: we know how to build strong emotional bonds between B2C clients and their customers via smart technology solutions .

Nisum is a global consulting firm headquartered in Southern California . Founded in 2000 with the customer-centric motto, Building Success Together®, we’ve grown to comprise over 900 consultants and 8 offices across the United States, Chile, India, and Pakistan . Our philosophy and deep technical expertise result in integrated solutions that deliver real and measurable growth .

Whether you are a hot start-up or a major global brand, our approach is the same: forge the most powerful connection possible between people, processes and products to achieve unparalleled success . At the intersection of business and technology, Nisum has everything you need to grow your organization . From Strategic IT Planning, Agile Enablement and Business Process Engineering to Application Development, Test Automation and DevOps, Nisum has you covered . We specialize in building Adaptable Back-End systems such as Order Management, Inventory and eCommerce to facilitate true omni-channel success for our customers .

Nisum strongly believes in an organizational culture that is open, transparent and progressive . We encourage creativity and innovation and consciously maintain an environment that is conducive to positive employee growth, learning and performance .

Disclaimer: Nisum Technologies, Inc .’s white paper is made available for educational purposes only, as well as to give you general information and general understanding regarding Agile and Agile Next Door Models . The information herein is not advice and does not create any obligations, relationships or duties on the part of Nisum Technologies, Inc . This white paper is provided “as is” and with no guarantees, representations, undertakings or warranties whatsoever, including any warranty of merchantability, fitness for any particular purpose, or any warranty otherwise arising out of any proposal, specification or sample .

The contents of this white paper, the names Nisum Technologies, Inc . and Agile Next Door, the logos and artwork used herein, are protected by the copyright, trademark and intellectual property laws of the United States and other jurisdictions . No license, express or implied, to any intellectual property rights is granted or intended hereby . You may print a copy of any part of this white paper for your own use and reference, but you may not copy any part of this white paper for any other purpose, and you may not modify any part of this white paper . You may include any part of the content of this white paper in another work, whether printed or electronic, or other form, or include any part hereof in another web site by linking, framing, or otherwise only if you provide all proper credits and references to Nisum Technologies, Inc .

1.Empathize

Brainstorm

alistofproblemsthatyouexperiencedwhile

workingonthepreviousexercises.Didyourunoutmaterials

whileprototyping?Didyourteamrunintoany

communicationbreakdowns?etc…

DesignThinkingCentricRetrospective

Users

Activities

Milestones

2.Define

Collaborativelychoosethemostimportantproblem.

3.Ideate

Generateasm

anypossibleideastoresolvetheproblemyouselected.Ideasshouldbegeneratedwithoutanyjudgment.Filteringandpruningwillbedoneattheendofduring

Step4.

4.Prototype

Choose1solutionfromSection3.Createablueprintfor

thesolution.

5.Test&Implement

Comeupwithatestplantotestoutthesolution.

Determ

inewhatnecessaryinputsarerequiredtomake

yoursolutionhappen.

© 2

018

Nis

um T

echn

olog

ies,

Inc

integrating design thinking principles into agile · agile is about delivering design solutions by...

Documents