IbmDesign

October 20, 2017

IBM Design Thinking Workshop – October 26th, 2017 at Goto10

mats Conferences, Design Portfolio, Design-Workshops, IBM Design Conferences, IbmDesign

Exploring Big Ideas

We generated a Big Idea idea about the design of what to do when public transportation is canceled and people are stuck in the center of Stockholm.

Stakeholder Maps

We generated a Stakeholder Map from the Big Idea.

Officials and Data providers

City officials, public departments, police, public transport companies, maintenance managers, and engineers working on broken infrastructure. They all have information to share about the situation, recommendations on what to do, and the plans when it will be fixed.

Alternative transporters

Drivers, Taxis, Pooling, Bike rentals, and kind people can help citizens to get from Stockholm city to their homes or other destinations.

Citizens

Going from a commonplace A to their destinations
Going from A to a common destination B

Businesses and Developers

Businesses that want to use this event to generate business and deliver services

We voted for building empathy for Bob running a Bike Rental and John a Police officer at the scene in Stockholm.

Empathy Maps

The workshop explored the empathy map for Bob. An empathy map structures what Bob ‘Say’, ‘Feels’, ‘Thinks’ and ‘Does’.Bob, owning a bike rental business, THINKS this is a great opportunity. “How much can I earn?.” He thinks about the situation and his capacity to deliver his service.

Empathy Map for Bob at the Bike Rental

“Do I have enough bikes, locks, helmets?”. “How should my customer pay?”.

But at the moment he FEELS happy and a bit stressed. He needs help to pull this off. And he feels good about helping people.

He SAYS – “I love SL and the business it brings me” and asks “Where should I keep my bikes to be ready?”.

He bumps up the price of rentals and calls in help from his friends using SMSs.

Empathy Map for John the Police

John THINKS, and fears, that crimes were committed and hopes that no one is hurt. He assesses where dangerous situations may occur. He needs to work overtime.

He FEELS stressed and disappointed. Oh, no, not again. He needs to stay focused and realize he just missed his ‘fika’-break 🙁

He SAYS – “How can I help” and “Keep CALM”. He instructs on routes to exit out of Stockholm city.

He gives directions and advice. He sizes the situation, reports on needs, and calls in for assistance. He provides assistance to people with special needs.

Needs Statements

We ended the workshop by calling out the needs of Bob and John.

Needs statements for Bob the Bike Rental.

Needs statements for John the Police.

Based on the needs statement, we find the following design opportunities

Transportation

Need directions on where to go – hotel, restaurant, or another meet-up place
Need options on transportation – car, bus, bike?
Need clarity on schedules – when leaving from where?
Need pricing information – do I have the money?

Finding contacts

Need to find a friend
Need to find a guide
Need to find a local

“Very useful and inspiring”

IBM Design Thinking: Deliver Breakthrough User-Centric Solutions
Learn more about the IBM Design Thinking workshop.

Download the workshop presentation

Learn more about IBM Design and IBM Design Thinking on ibm.com/design

September 21, 2017

IBM Design Thinking Workshop – September 21st, 2017 at Goto10

mats Design-Workshops, Workshops IbmDesign, Workshops

Exploring Big Ideas

We generated Big Ideas in three areas

Travel
Process
Communities

This emerged to a design around the big idea of a tourist arriving in Stockholm.

A chatbot for tourists in Stockholm that helps with finding and sharing information
Growing a personal network by meeting new people
A structured network to connect people

Stakeholder Maps

We generated a Stakeholder Map from this Big Idea.

Tourists – Arriving in Stockholm city as first-time visitors with an interest in experiencing the best activities and Swedish culture.
Locals – Loves meeting new people and showing them around the city. Want to learn and improve their language skills.
Officials – Want invest and be efficient to provide the best information and experience for visitors
Guides and Agents – Travel agents and street artists that want to know where crowds are
Businesses and Developers – Build client solutions and businesses¨¨

We voted for building empathy for Texas a Tourist and Lisa a Local.

Empathy Maps

We generated an empathy map for Texas, the tourist. The An Empathy map structures what Texas ‘Say’, ‘Feels’, ‘Thinks’ and ‘Does’.

The workshop practiced on Playbacks.
A playbacks is a safe environment to share ideas. Playbacks ensure the progression of the delivery of the outcome.

Empathy Map for Texas, the Tourist

Texas, the tourist, THINKS he needs to get to a hotel and connect to wifi, so he can get information on what to do this evening. He is quite a good tango dancer and wants to see suggestions based on this interest.

But as the moment he FEELS lost, lonely, hungry, stressed. But also energized to learn more about Stockholm.

He SAYS – “Where are the locals?” and asks “Can you show me…?” and “How do I get to…?”.

He has been walking for hours and finally gets to his hotel. He spends hours on Google trying to find information.

Empathy Map for Lisa the Local

We generated an empathy map for Lisa the local. We found that…

Lisa thinks that she has so much to show. She is willing to set a day aside for such activities. She thinks that she may get tips like 10 SEK for every tourist that she is helping out. But she is a bit nervous and wonders how to call for help in case of dangerous situations.

She feels she might be lacking sufficient language skills. She might be annoyed by tourists are not behaving.

She tries to connect with some tourists to join her for a football match or dinner at a new restaurant she just heard about.

She works as a shop assistant and puts her name upon a contact list at work.

goto10sep21-lisa-local

Needs Statements

We ended the workshop by calling out the needs for Texas and Lisa.

Based on the needs statement, we find the following design opportunities

Location and routing

How to best get into the Stockholm city area
Where to meet up guides, and pick up tourists
Identification, who is a guide and who is a tourist

Allocation and Scheduling

Who to go with who
Optimize groupings from pick up, route, and drop off

Trust, safety, and pay

Only pick up people with good references
Emergency calling
Pre-agreed price. Simple pre-pay methods

“Today I had a very amazing opportunity to be a part of a workshop called “IBM Design Thinking: Deliver Breakthrough User-centric Solutions”: I learned so much in such a short time and met a lot of amazing people. But before that, I was hesitating to go because I didn’t know anyone there and the thought of being embarrassed scared me. If I had let my fears decide for me then I wouldn’t have had one of the best experiences in my UX career.”

“Thank to all of you from IBM for a great workshop”

“Workshop experience and following discussions were very interesting. A lot of inspiration, thanks to the organizers”

IBM Design Thinking: Deliver Breakthrough User-Centric Solutions
Learn more about the IBM Design Thinking workshop.

Download the workshop presentation

Learn more about IBM Design and IBM Design Thinking on ibm.com/design

September 21, 2017

IBM Design Thinking: Deliver Breakthrough User-Centric Solutions

mats Design Portfolio, Design-Workshops, IBM Design, Workshops IbmDesign, Workshops

IBM Design Thinking Workshop

Are you building a business with user-centric solutions? How well do you know your users today? Are you really solving your users’ actual problems and creating the best possible value for them? With IBM Design Thinking you will view a business idea and solution from the users’ perspective. Only then can one ensure that the actual user pain points are targeted.

This practical workshop invites you who want to learn a powerful methodology that can be used to develop your business idea into a user-centric one.

goto10

During this three-hour workshop, you will learn about the IBM Design Thinking framework and get practical experience on how to use it. IBM Design Thinking includes a number of tools and practices that help companies deliver breakthrough solutions that fulfill their users’ actual needs. It is a human-centric methodology that focuses on creating innovative solutions with high user experiences.

goto10-designthinking

Design in the intent behind an outcome

Before we begin, let’s make sure everyone understands what we mean when we say “design”. Design is the purpose, planning, and intent behind an action, fact, or material object. In other words: Design is the intent behind an outcome. Nothing more, nothing less.

The focus on a desirable outcome is not in conflict with agile practices. Agile practices sets focus on achieving a predictable and repeatable heartbeat of delivering the solution. The content of each delivery will be scoped to what can be contained with quality in each sprint. Lean takes a focus on optimizing the process to achieve a deliverable, and only required tasks should be included. Both these methods let the mechanisms of delivery take precedence over the content delivered. With design thinking, we complement the agile methods with the focus on the desirable outcome. Design Thinking hence adds the purpose and intent and ensures that the user is at the center of the outcome.

Good design is good business

Good design is good business. This statement by Thomas Watson is well known and often quoted. It captures the importance and uniqueness of design at IBM in the 50s. Today, good design and Design thinking is mainstream. Good design much table stake and mainstream. Design thinking is widespread. So, what is different in IBM’s version of Design Thinking?

Mission: Create a sustainable culture of Design at IBM

The IBM Design program started small in 2013 with a mission to hire 100 formally trained designers and kickstart 7 hallmark projects across IBM. Across different BUs, different products, and different project objectives.

We emphasize the parts that drive

differentiated delightful outcomes
business value and leading business strategy
the elements that delivered @scale and speed for distributes and complex teams

Today, we are now 4 years into the program with over 400 projects, 1,000’s of designers, and IBM’ers trained on Design Thinking across Development, Offering Management, Sales, and Services. Design is touching almost every IBMer and every project in the labs and in the field. And it inspires other innovative practices, like the IBM Cloud Garage Method.

IBM Studios

The Design Studios are the centers of the design culture. They are a key enabler for the way of working with multi-discipline teams and reaching out to our global organization. Studios are built out across the IBM labs. Design studios are open and movable. Workspaces change the shape as the purpose over time.

Solving complex problems requires us to work together across differences

The question remains “What is different with IBM Design Thinking”. With the size of 350k employees at IBM, with geographically distributed teams, offering management, design, development, sales, and services across the globe we need a design model that scales. Four key aspects of IBM Design Thinking enable that scaling.

Users
Hills
Playbacks
Multi-disciplined teams

Users

The users are our clients. Their success is our success. They are the judge of the value we bring. And it’s their experience we have is given the privilege to host. Our designs must be based on their needs or pain points. Our design must be driven from an empty with the users. They must be our North Star.

We ensure that we put users first by recruiting Sponsor Users of the design. We ground the intent to their needs.

Hills

Hills gets us aligned. Hills are captured by a WHO, a WHAT, and a WOW. A hill is a clear statement of the intended user, the WHO. It is a clear statement of intent on the outcome, the WHAT. And, it is a clear statement of the differentiator compared to competitors, the WOW.

The hill provides clarity and frames the problem – in simple words; aligns the understanding across team members. And reaches out and aligns stakeholders (executives, marketing, sales), clients, and ecosystems. But it does not prescribe an implementation.

Playbacks

Playbacks help us stay aligned. Playback is a safe environment to share work. They ensure the progression of the delivery to a successful outcome.

Playbacks can be run anytime and may take different shapes and purposes. For example,

Hills playback – Confirm that stakeholders agree with the outcome
Playback Zero – Align teams on Concepts, UX, and plan.
Delivery playback – On milestones
User / Client – Playbacks for stakeholders

The workshops include practical sessions where we explore stakeholder maps, empathy maps, and needs statements. We also practice on playbacks.

Multi-Disciplinary Teams

IBM Design is not an agency – taking and delivering an awesome design. And we are not alone in solving a problem. In a multi-disciplined team, design work shoulder-to-shoulder with offering management and development, throughout sprints, milestones, and releases. Empowered teams can rapidly, generate ideas, reject or commit to them, and collaborate.

goto10-playbacks

goto10-ideation2

“Today I had a very amazing opportunity to be a part of a workshop called “IBM Design Thinking: Deliver Breakthrough User-centric Solutions”: I learned so much in such a short time and met a lot of amazing people. But before that, I was hesitating to go because I didn’t know anyone there and the thought of being embarrassed cared me. If I had let my fears decide for me then I wouldn’t have had one of the best experiences in my UX career.”

“Well thought out and structured presentation and Workshop”

“Thank to all of you from IBM for a great workshop”

“Workshop experience and following discussion were very interesting. A lot of inspiration, thanks to the organizers”

“Very useful and inspiring”

March 27, 2017

Adopting IBM Design Thinking for Solution Development

mats Design Portfolio, IBM Design IbmDesign

IBM Design Methods

Adopting IBM Design Thinking for Solution Development

This blog share some of our latest experiences from the Product Line Engineering (PLE) delivery team in adopting these processes and the way we started applying IBM design thinking to our solution development supporting businesses that include embedded software development.

Last year, AmyS blogged on the progress defining our internal Continuous Delivery process. To follow up on those concepts, I would like to share some of our latest experiences from the Product Line Engineering (PLE) delivery team in adopting these processes and the way we started applying IBM design thinking to our solution development supporting businesses that include embedded software development.

Design is good business!

IBM recognizes that good design is good business. And there is a long tradition to back up that statement. Lately, IBM Design Thinking has gathered design practices to identify and ideate on the aspects that makes a solution desirable to its users; the Who, the What and the Wow! These aspects become the mission for release(s) and the business requirements for the solution. Amy identifies these as the business planning artifacts at the top of the planning taxonomy. We call these Release Hills.

Cross-SolutionPlanningTaxonomy

Figure 1. Cross-Solution Planning Taxonomy.

The use of Hills to capture the WOW’s

For delivery of improved capabilities for product line engineering, the team has focused on three Hills to drive innovation, to drive our work, and to organize and track our activities. Our first Hill ‘Work in configurations with artifacts and links’ focuses on core capabilities introduced in our solution on configuration management, with streams and baselines of engineering artifacts. The second Hill ‘Create and use product definitions’ extends the value of the first Hill with more targeted support for advanced product line engineering practices and use-cases. Our third Hill ‘Track and report on configurations of engineering artifacts’ is orthogonal to the first two and adds complementary capabilities to the solution with dashboards, queries and reports. To refine our mission to a focused and executable level we have also defined sub-hills that narrow-in scope and prioritize sets of features.

Organizing our solution artifacts by Hills

At the next level in the planning taxonomy we use the Hills as our primary organizational item for solution artifacts. At this level we use Rational Team Concert work items to capture our Epics and Features. And we use Categories to represent the Hills. This makes the process of classifying new capabilities simple by just using the Filed Against field when assigning Epics and Features to a Hill. We refine Hills into Epics to represent our sub hills. Features then become children under their parent Epics to further refine the capabilities into work that we can execute on within a single release cycle.

Our solution features are to be delivered by the impacted products, e.g. Rational Team Concert, Rational Quality Manager, Rational Doors Next Generation and Rhapsody Design Manager product development teams. Any enhancements to products are planned using Plan Items and Stories in each impacted product backlog respectively. To manage relations between solution features and application plan items we use cross-project Tracks links. This linking provides transparency to commitment and plan of delivery. It also provides transparency to progress on work and in-context collaboration.

Artifactsusedforsolutionandproductplanning

Figure 2. Artifacts used for solution and product planning.

Using scenarios and playbacks to explore and validating our design

Scenarios are a key concept in our design thinking. They ensure that we can deliver our features in a coherent, usable and desirable solution. Scenarios also support our activities on innovation, exploration and validation. Much like a movie script we let our personas act out in the scenes using scripted steps. Hence, each scenario Act is decomposed into Scenes where the scenario personas act through Steps interacting with the tools and collaborating in context of a configuration of engineering artifacts. As indicated in Figure 2 above, our scenarios are linked to the features used in each scene using an Implements relation. Using these links in figure 2 we can report on important delivery metrics. As a few examples, lately we have been using the Rational Engineering Lifecycle Manager (RELM) product and the Lifecycle Query Engine (LQE) to index our solution artifacts and provide traceability reports that outline the dependencies and coverage of Plan Items to Features, Epics, Scenes and Hills. This creates a great overview of the design artifacts. On our delivery dashboard we use the artifacts to present key design metrics like; ‘Scenarios with no features’, ‘Features with no scenarios’, ‘Features with no Tracks’.

For our PLE scenario we use a storyline on ‘Fixing a defect in a product variant’. This scenario is exploring in the first act how the scenario personas will initially ‘reproduce the defect’ using the engineering artifacts in the released baseline configuration. In the second act the team will ‘create a new delivery configuration’ with updated engineering artifacts resolving the defect. In the third act the team explores the opportunities for reusing the fix when ‘delivering and baselining a fix to the product line’. Our personas acting in the scenario are the Product Line Manager, the Project manager responsible for product line delivery, the Development lead responsible for platform component delivery, the Configuration lead, a Systems engineer, a Embedded SW Developer and a Tester. To show progress on the solution delivery we conduct frequent playbacks of the scenarios using initially low fidelity mockups and prototypes. Over time we converge to more stabile high fidelity wireframes and working code by milestone.

Exploring design options and usability

Lately we have been using playbacks to explore design options and usability aspects on how the scenario personas are interacting with the configuration management application when creating streams and baselines of configurations. Using a scenario and playback design approach helps us in clarifying implications to usability and consistency across the solution.

Download article

View article on IBM DeveloperWorks

Learn more about IBM Design and IBM Design Thinking on ibm.com/design

January 25, 2017

Using Design Scenarios

mats Design Portfolio, Design-Methods IbmDesign, Methods

The scenario is a key artifact in our design. It ties together the personas and their objectives with their workflows and pain points. It forms the basis we derive solution requirements, like release hills. And the way we validate our design using playbacks.

There is a large variability in how I have used scenarios across Green Threads, GDD, CLM, SLM, PLE, and IoT projects. A few examples are given below. All scenarios use a visual representation of the scenario flow as Acts and Scenes.

Scenarios always benefit from a context or a story. It builds on the personas and provides an organizational context to the individuals. For example, in the scenario for Global Development and Delivery (GDD) we tell the story of a global organization sourcing work to near-shore and off-shore teams.

In the Story below I describe the personas, their objectives, and hint at their geographical distribution.

ScenarioOverview1

Then, on the Solution, I discuss more their responsibilities and activities. And I indicate the application artifacts and tools each of the personas is interacting with. The relation between the personas and the artifacts is key in the Application Lifecycle Management (ALM) scenarios. Note that colors also give hints on their geographical distribution and artifact ownership.

ScenarioOverview2

I find it valuable to have a single page outlining the overview of the scenario. It becomes a great image to present the high-level objective and flow of a scenario and its personas. Two examples below from initial GDD scenarios. And later scenarios for ALM.

GDALMSceanrio

EnterpriseALMScenario

I use scenarios to report on solution gaps and user pain points as we declare state our as-is and to-be products. Two examples below from capturing tool gaps and user pain points.

ScenarioDashbaord

ScenarioDashbaord2

A final example from the design of First-day productivity for the Systems and Software Engineering solution. The scenario outlines the discover-try-buy scenario, the personas, and their interactions in exploring and adopting the solution in a project.

Day1Productivity

Learn more about IBM Design and IBM Design Thinking on ibm.com/design

January 25, 2017

Integrating Design Thinking and Agile Development

mats Design Portfolio, Design-Methods, IBM Design IbmDesign, Methods

Stages of Concept Design and Development

The Watson IoT Platform team is using an agile way of working to design, develop and deliver new capabilities for the IoT Platform service in Bluemix. Such new major capabilities are identified as market or customer need, specified as requirements using Rational Doors NG, and managed as a ranked backlog. The team is delivering the backlog using an agile 3-week sprint heartbeat.

The sprint objectives and the outcome is varying depending on the phase in the design – develop – deliver lifecycle for a new capability. The initial phase defines the concepts and scope of the design. Later phases harden the UX design and deliver front-end and back-end implementations of the design.

A key success factor is the teaming across the disciplines across offering management, design, and development. And the right-sizing and right-staffing of the sprint teams. The concern and issues addressed by this practice is to ensure that the teams are engaged, right-staffed, and committed to the delivery. It avoided a situation where design is executed in a planning vacuum with major trash and rework as the development teams get engaged.

Let’s start and explore the expectations, inputs, and outcomes of each sprint type and the team personas participating. The phases, roles, dependencies, and outcomes in figure 1 below are discussed.

Stages of Concept Design and Development.

Concept and Plan

The first stage is a Concept and Plan sprint focusing on the product definition. A sprint team is formed by the design lead(s), Architect(s,) and Offering Manager(s).

The concept and plan sprint requires strong offering management and design lead participation. To ground the concept in the existing solution architecture there is a requirement of lead architect participation. A core team is formed that is responsible for defining and delivering the concept and the delivery sprint plan. The playback of the outcome is a driver and a forcing function by schedule to get early agreement on the concept scope and objective. The core team stays as a governance body for the later phases to manage and approve changes to the concept and plan.

For this concept and plan stage the inputs are:

High-level market and product requirements on the new capability
Design Thinking user research artifacts, e.g. stakeholders, and stakeholder needs
Existing Hills where the new capability may be a new sub-hill

The outcome of this concept and plan stage is:

An approved set of requirements capturing the Minimal Viable Product, MVP.
Hills defines the user value through statements of Who, What, and WOW.
The Epics that will deliver the hills. The hill is complete when the epics are delivered.
The Stories that deliver the Epics. A story is delivered in one sprint.
An end-to-end high-level scenario that can be played back as a statement of the hills

UX and APIs

The second stage is focusing on exploring the User Experience and the APIs for the new capability. The objective is to harden the MVP by validating the concept in the context of the IoT Platform.

For this stage, a sprint team is formed with UX Designer(s) and Architect(s). UX playbacks are demonstrating the capability experience. Any updates and additions required to the solution architecture are identified. The stories in the plan and broken down into actionable tasks.

The outcome of this state is:

Validation that requirements can be met
Elaboration of the Stories and breakdown into actionable RTC work items or GitHub issues.
UX designs (LoFi) for the scenarios

UX, Front-End, and Back-End development

The following stages are focused on delivering one or more stories in each sprint. UX design is leading and handed off to front-end and back-end development. The sprint teams are formed with UX and Visual designer(s), Front-End and Back-End developer(s).

The outcome of this sprint is:

Completed work items or issues
Completed UX designs (HiFi)
Playbacks of UX designs or running code

Summary and Conclusions

The Watson IoT Platform team is using an agile way of working to design, develop and deliver new capabilities for the IoT Platform service in Bluemix. The benefits are:

Embedding design thinking practices into the agile development process
Cross-discipline teaming
Right-timing, Right-sizing, and Right-staffing the agile sprint teams
Early delivery and hardening of design concepts

The workflow has been successfully established and used for the design of new Watson IoT Platform capabilities, like design and delivery of Risk and Security Management and Information Management.

Learn more about IBM Design and IBM Design Thinking on ibm.com/design

January 25, 2017

Applying IBM Design Thinking

mats Design Portfolio, Design-Methods, IBM Design IbmDesign, Methods

Workshops

Working with a group of users is an effective way to make progress on conceptual and detailed design. Such workshops run from 2h to 6h using the Stakeholder Map, Empathy Map, Prioritisation, and Experience Map tools. Workshops quickly bring together teams and team members in a creative environment.

Workshops

InnerCircle

Design Studios

At IBM conferences like Innovate, Interconnect, and Insight we often get the opportunity to run design labs. These labs can support the design lifecycle we use both at early phases of Understanding, as well as later phases where we Prototype or Evaluate. The example below is from the three design studio labs in 2014 where we researched the PLE solution.

DesignStudio

View the material from Designing User Experience Concepts in the Multi-Stream Configuration Management lab at Interconnect 2015.

1-1 Interviews

Sitting down with a client in a 1-1 interview will generate essential research information. Shadowing a user is another way to observe the as-is workflows and pain points.

I favor a style of dialog using a whiteboard to capture workflows and artifacts. This benefits my graphical way of thinking and engages the client. The sketches can easily be an overview where pain points can be identified. What works really well (tagged green), and what does not work that well (tagged orange/red).

1-1

Stakeholder Maps

Stakeholder maps are a great way to get started with a new group of clients, or a client team. It makes attendees start standing, ideating, talking, and telling. It generates a holistic view of the solution space and its stakeholders. It provides a mechanism to discuss and establish priorities and scope.

StakeholderMap

Empathy Maps

I use Empathy maps to capture the details of Stakeholders and transform them into Personas. An Empathy map is a great tool to capture how clients interact with a solution and their expectations as it captures what a persona Says, Thinks, Feels, and Does.

Sally1

Personas

Empathy maps become the source for persona definitions. I often come across stakeholder that becomes variants of our more general personas. In such cases, I document this using “Also know as…”. It’s an act of balance in capturing important differences in personas and keeping a generalized level to make personas applicable across the solution and across industries.

Sally2

Personas documented in the Requirement Management solution.

Susan

Sometimes we want to generate a bit of external nterest for personas. This is a cool set of trading cards we created for the Innovate conference using the Product Line Engineering (PLE) personas. These giveaways generate interest and conversations.

TradingCards

Experience Maps

Experience maps are a tool to outline a scenario. It captures the major and minor steps as the personas interact with the solution to achieve an objective. The example below is an experience map from PLE design on the steps to create a global configuration baseline. The experience map was created by the InnerCircle members across multiple industries at the IBM Innovate conference.

ExperienceMap

Example of Experience Maps for an Operator persona managing maintenance of assets in the Natural Resource industry.

Learn more about IBM Design and IBM Design Thinking on ibm.com/design

January 24, 2017

IBM Rational Green Threads

mats Design Portfolio, Design-Methods, IBM Design IbmDesign, Methods

IBM Rational Green Threads

Green Threads was an early precursor to many of the outside-in design principles we see in IBM today. It captured user design scenarios across a set of products that solve a customer problem. It moved our organization beyond product thinking.

I was a part of the IBM Rational Green Threads team from 2005 to 2012 and its merger into the IBM Rational Design Factory team.

GreenTread-1024x89

Green Thread Goals

Cross-product solution team moving our organization beyond point product thinking
Deliver solutions that really work to solve real-world customer problems
Build virtual teams across subject matter experts, product teams, and solution architects to define solution scenario
Identify and prioritize key issues and roadblocks to product development
Work with point product teams on ownership and prioritization
Provide guidance and recommendations for product use
Identifying progress measurements and indicators

Definition

Workflow across a set of products to solve a complex customer problem
End-to-end workflow a customer might follow to accomplish a particular goal or handle a specific situation/event
Reflects real-world usage and scenarios
Demonstrates an optimal workflow
Document the “As Is” flow – Define a “To Be” flow
Try to match green threads to Rational market strategy (solutions & segments)

Scope

Multiple green threads, each with a different focus, for example, Business-Driven Development, System in Trouble, Deployment, Software Development Governance, Solution Delivery and Management, Global Development and Delivery, Systems Development, SOA Deployment, Collaborative Application Lifecycle Management, Agility at Scale.
Span relevant products from Rational, Tivoli, WebSphere, Lotus, DB2
Continuously updated for new product releases
Each GT reflects a specific usage scenario, not all possible scenarios
Current threads started after products were delivered. Over time, they will catch up and get ahead of product schedules (e.g., feed Drake concept)

Way of Working

The Green thread method follows a set of steps to define the as-is solution scenarios, the longer-term vision. and the improvements steps, to get to that solution vision.

The individual steps are:

Identify and Prioritise Scenarios – Goals, and Scope
Detail and Document Tasks – As-Is flow
Walkthru / Execute Scenario
Identify Issues and Product Requirements
Provide tactical recommendations
Guidance and artifacts for field engagements
Long-term Vision – To-Be flow
Incremental Product Improvements
RFEs and defects to product teams
Milestone Assessments

The Green thread method uses a standard overview of the solution scenario. The overview outlines the personas, the actions performed, the flow of events, and the offerings or tools in the solution used for the actions. The solution improvements in the to-be vision are tracked by tool and by solution release. Examples of green thread outcomes are shown below.