Agile Design Methods
  • Blog
  • Methods
  • Resources
    • Online Course
    • Mobile App
    • Public Course
  • Contact Chuck
  • Search

The Greatest Book on Design Ever Written

4/29/2018

3 Comments

 
I've heard it said, "To learn a new truth read an old book." Today I want to tell you about a conversational skill that I learned from an out-of-print book that I absorbed many years ago. What I learned positively impacts my design leadership work to this day.

The skill described in this book is a proven game-changer for me as I face the predictable challenges that occur in leading groups of people on the journey of product and solution design. It also measurably improves my ability to connect with people in my personal life.

Anyone can learn this skill. Mastering it is a lifelong and worthy pursuit. It provides a clearer understanding of issues and what to do about them. As a result, design conversations stay on track when issues occur. They get identified with greater understanding...and they get resolved.

If you want more confidence in how to handle issues when they occur, the life skill taught in an out-of-print book, and that I introduce in this video, will absolutely help you in your work and throughout your life.
The big takeaways
  • A proven technique for handling issues that surface in conversations and in life
  • The five things to be aware of when identifying and resolving any issue
  • How to develop trust and connection when working with people
  • Techniques for moving the conversation towards designing the resolution

Resources
  • Straight Talk - Interpersonal communication book (out of print, but still available)
  • The I-Skills Zone - Business communication learning resources (currently available)
3 Comments

Agile Design Methods: Design the What

3/29/2018

1 Comment

 
Design work is enabled by conversation with various stakeholders. Agile design methods focus on discussing and describing WHAT is to be produced before describing HOW it is to be developed. 

Here is a quick primer on agile design methods, where they fit in solution development lifecycle and how they differ from agile development methods like Scrum.
The big takeaways:
  • Design requires a conversation with stakeholders
  • Agile design methods engage owner/user stakeholders to design the WHAT
  • Agile development methods engage delivery stakeholders to design the HOW

Resources:
  • Agile Design Methods: A Conversational Approach - In-depth blog post

Picture
1 Comment

Facilitating Learning and Discovery Conversations

2/12/2018

0 Comments

 
Good design conversations don't happen by accident. Facilitators who understand where people are coming from and where they are taking them have a markedly improved chance of getting great contributions and producing good conceptual design work.
​

Here are a few ideas to help facilitate learning and discovery design conversations with busy people.
The big takeaways:
  • The difference between normal conversation and learning/discovery conversation.
  • A conversational pitfall that contributes to poor design quality.
  • One key technique to facilitate learning and discovery in a conversation. 

Resources:
  • BoxofCrayons.com: The Coaching Habit - Great open-ended questions
0 Comments

How to Get the Design Flywheel Spinning

1/23/2018

0 Comments

 
Good design conversations don't happen by accident.

They are started and sustained by capturing ideas in the moment and in a way that people can perceive.

Here are some ideas to help you lead the design conversation and to capture the learning and discovery that occurs in a collaborative meeting.
The big takeaways:
  • ​My technique for igniting the design conversation in a group and sustaining it.
  • A pitfall that causes meetings to quickly run off the rails.
  • How to develop trust and direct ownership of the design conversation to the group.
  • Techniques for capturing and organizing content captured from the conversation.

Resources referenced:
  • BoxofCrayons.com: The Coaching Habit - Great open-ended questions
  • Grove Tools - Excellent visual planning templates 
  • Circle of Interaction™ (COIN) - My simple and engaging way to produce a future-state design quickly and with a high degree of clarity
0 Comments

How to Set the Environment for Creative Collaboration

1/21/2018

2 Comments

 
​Getting people to collaborate creatively in meetings is easier and more effective when it is done in a pleasurable, fun and trusting environment.

​I know from experience how hard this can be.

So here are a few tips for leading a creative, collaborative meeting...
The big takeaways:
  • ​My technique for building trust with participants before they even enter the meeting.
  • How to shift the external environment so that the participants are relaxed and pleased to be in the meeting.
  • An effective way to spark the creation of ideas without saying a word.
  • How to overcome a huge unseen barrier that is causing people to hold back and not contribute.
2 Comments

Collaboration is the Shock Absorber for Inadequate Documentation

11/8/2017

0 Comments

 
Picture
Jonathan Velasquez
In the product development lifecycle, there comes a point in time when we must write down what is needed. We refer to this documentation by a variety of names:
  • Requirements
  • User stories
  • Feature lists
  • Use cases
  • Design specifications
  • Supplemental specifications
  • Success criteria
These artifacts represent our attempt to completely capture what the user needs. We fill out forms and declare that our work at capturing what is needed is complete. Milestone achieved. Check the box. Move forward in building the product.

Not so fast. Documentation by itself is inadequate.

It is in adequate because it represents a one-size-fits-all approach for connecting what is needed to the person or team who will be responsible for designing and building it.

A sage friend of mine recently opined, "It is a rare person who can look at a list of requirements and fully understand the context of the user."

Think about how commonplace it is to misunderstand someone else's words or intentions in our daily lives and interactions with people. This reality is also true in the world of product design and development.

Thus, the necessity of collaborative conversation reintroduces itself into our product management reality. When solution designers and architects begin to consume these documents, they rarely seek more specificity, Rather, they almost always seek increased understanding and clarity regarding the context of the person experiencing the problem.

That clarity comes most efficiently and effectively through collaborative dialog, a series of questions raised by designers and architects who have consumed the documentation and the people who have the answers. Only when an adequate level of understanding is obtained can they proceed with confidence with their product design and development activities.

By way of example, Scrum (the agile development framework) recognizes that a critical function that a Product Owner performs is to answer questions that Developers have regarding user stories. In other words, Scrum assumes that it is normal for requirements to not be fully understood by those who read them.

The handoff between those writing documentation of needs and those consuming them represents a predictable speed bump in the process of designing and developing solutions. The shock absorber that is best suited to absorb that bump is a collaborative conversation between those in the know and those who need to know in order to proceed.
0 Comments

What's the Problem? Exactly.

10/13/2017

0 Comments

 
Picture
A problem statement depicts the moment of opportunity when a transformational solution would make all the difference in a particular person's quality of life.
As a solution designer or marketer, tuning into the context and experience of a person in a predicament is fundamental. There is no side-stepping around these questions:

  • Who is experiencing the problem?
  • ​When and under what circumstances does the problem happen?
  • How would they describe it in their own words?     (super important)
  • How does it make them feel?     (also super important)
  • How does it affect their quality of life?

​A cogent, well-crafted problem statement answers these questions and provides clarity of context to solution designers and product marketers.

Why a Problem Statement Is Important

A problem involves a person in the context of a specific predicament. The problem is the raison d'être for any solution under consideration and, by extension, the gold for which the solution designer is mining.

A person experiencing a problem expresses it through emotion. Describing the circumstances causing their feelings in their words, however strong or subtle, provides a foundation of empathy to design an ideal solution. It is essential to recognize the emotion because it produces the personal resonance of the problem context, effectively influencing the thinking about the solution design.

​A problem statement depicts the moment of opportunity when a transformational solution would make all the difference in a person's quality of life.

Problems Lead to Solutions

From a marketing perspective, borrowing a concept from Pragmatic Institute, a “market” is a group of people who share the same problem. Therefore, observing, understanding, and clearly describing a problem with resonance is the cornerstone of any solution, making a highly refined problem statement, or set of statements, all the more valuable.

Who needs or uses problem statements?
  • Solution designers and architects
    They need to understand the context under which a problem occurs. The more empathy the designer or architect has for the person's experience with the problem, the better.
  • A product manager 
    ​
    They need to identify which problems are urgent and pervasive. That subset of problem statements represents the high-potential candidate problems to research, assess, verify, and build a business case for solving.

How To Create a Problem Statement

Here is an effective way to create a statement that expresses an understanding of the context and the problem so that it informs and influences solution designers and architects. 
A problem statement is a sentence or a small set of sentences that includes these descriptive elements:
  1. A description of the person 
    Name or describe the contextual role of the person.
  2. When or under what conditions the problem occurs
    Describe the goal they are trying to achieve or when the problem happens.
  3. An emotion they experience
    Describe this in words they would use or that you have observed to establish an empathetic connection with the person experiencing the problem.
  4. A description of the effect the problem has on their quality of life
    ​
    Use wording that the person would use in their business or life context.​​
​
​Actual Statements and Mad-Lib Styled Templates
You may be fortunate and can describe the problem statement by simply transcribing what you have observed people say in the context of experiencing an issue. That's a preferable way in which to produce a problem statement.

But, if you don't have that form of recall handy or need some help constructing a statement, then some fill-in-the-blank templates help demonstrate what this looks like.​

To that end, here are some Mad-Lib-styled templates:​
​
  • As a       (1)      , when       (2)      , I am       (3)        because       (4)      .

  • As a       (1)      , I am       (2)      , when       (3)        because       (4)      .

​Examples
Here are two examples of problems statements based on conversations I've had and observations I've had in just the past day:
  • As an iPhone user, when I can't find my AirPods case, I panic and scramble, looking all over the place, retracing my steps because the darned thing is so easy to lose and would cost me a fortune for me to have to replace.
  • As a coach, in a live practice or game setting, when tensions are already high, to begin with, someone lets something denigrating fly out of their mouth to one of the players. At that moment, I’m flustered because I’m supposed to lead here, and I draw a blank on what to say or do. I’m unsure of what to do in response because I’m not experienced in how to handle something like this. Over the long haul, letting this kind of communication go unchallenged affects the team, our institution, our relationships, and our friendships.

Best Practices and Pitfalls to Avoid
  • Do use the first person.
  • Do use descriptive statements that you have actually observed people saying.
  • Do create multiple statements rather than trying to blend various problems into one.
  • Do not describe the solution or use solution jargon.
  • Do not embellish using false emotion or projection (do keep your BS detector on).

How To Create an Ideal Solution Statement

A common pitfall when designing a solution is rushing too quickly into describing how providers should implement the solution. A way to avoid that pitfall is to describe the solution's effect on the person instead of explaining how to solve the problem. 

An ideal solution statement avoids this pitfall by informing and influencing solution designers and architects on what is needed while respecting their role in designing how to solve the solution.​

​An ideal solution statement is a sentence or two that:
  • Begins with the phrase, "The ideal solution would..."
  • May contain the phrase "so that" or "the ability to"

​Examples
Here are ideal solution statements based on the aforementioned problem statements:
  • The ideal solution would provide me the ability to know where my AirPod case is located right now so that I can find it easily.
  • The ideal solution would give me the know-how and confidence to respond appropriately in the moment and over the long haul so that values of personal respect and dignity are established and reinforced in our team and in our institution.

​Best Practices to Use and Pitfalls to Avoid
  • Do use the first person.
  • Do describe the business or quality-of-life improvement delivered.
  • Do write the first draft of the statement soon after producing the problem statement because it so naturally flows afterward.
  • Do create one ideal solution statement per problem statement.
  • Do not describe components of the solution or use solution jargon.

Practical Application

​An ideal solution statement can easily feed into agile development practices in the form of a user story. Developers use user stories in agile solution development to create a backlog for product development.

The user story that is widely practiced in agile communities reads like this:

  • As a              I want              so that             .

Here is how our example ideal solution statements can be transformed into a user story that can be used by an agile development team:

  • As an AirPods user, I want to know where my AirPods case is right now so that I can find it easily.
  • As a sports coach, I want the know-how and confidence to respond appropriately in the moment and over the long haul so that values of personal respect and dignity are established and reinforced in our team and our institution.

In addition to user stories, the problem statement described herein offers a richer contextual insight for solution designers to understand how their envisioned solution user experiences the problem.​

Combining a problem statement with the ideal solution statement increases the potential for designers and architects to empathize with the problem. This insight improves their ability to design a solution that resonates with the intended user.

​It also enhances the ability of a product manager to strategically position the solution in the market, communicating with resonance through marketing channels and sales efforts.

Want More?

​Subscribe to my free blog updates to receive content that vividly describes the techniques and leadership skills that embody the practice of agile design methods. The blog contains not only my ideas on the topic but the insight of others who actively work and thrive wholeheartedly in the realms of collaborative creativity and solution design.
0 Comments

Introductions: Capturing Critical Context in the First Few Minutes

9/29/2017

0 Comments

 
Picture
”Tell us a little about yourself and what your organization does in the overall process.”
It passes so quickly that you’ll miss the opportunity if you’re not paying attention.

It’s that initial moment in the process when a person introduces themselves, shares who they are and what and their organization does.

That moment is rich with potential and it goes by quickly.

What To Listen For

Be prepared for the moment in advance by having your co-facilitor serve as a scribe, recording the person’s name on a single sheet of paper or in a note-taking tool like Evernote.

Then your scribe should listen for and record any of the following items that the person mentions:

​Nouns
  • Their name
  • Their organizational role name
  • Workproducts (things they or their organization produce or services they deliver)
  • Collaborators (people they work with or interact with to get things done or do things for)
  • Systems or applications they use to help them
  • Things they respond to

Verbs
  • What they do or produce
  • ​When they do it
  • Triggering business events that they respond to

Pain Points / Opportunities
  • ​Problems they describe​

Example

“I’m Juanita and I work for the Finance Department. We use Dynamics to produce final paychecks when an employee departs and work with Legal and Procurement and Travel to ensure that any garnishments are taken out prior to their final paycheck and that any reimbursements for travel expenses are also included in their last paycheck. We also produce W-2s for departed employees at the end of the year. It’s a challenge and a very manual process to get all of this done thoroughly in a short timeframe, particularly when an employee departure occurs quickly.”

Nouns
  • ​Juanita
  • Finance Department
  • Final paycheck
  • Expense reports (travel expenses)
  • Reimbursements
  • Garnishments
  • W-2
  • Legal Department
  • Procurement Department
  • Travel Department
  • Dynamics application

Verbs
  • When employee departs: Produce final paycheck
  • At year-end: Produce W-2 for employee

Pain Points / Opportunities
  • ​Getting the final paycheck done thoroughly in a short timeframe is a highly manual process.​

What To Do With This

Hold on to them. They will come in handy in the structured conversation that will unfold in the hours and days that lie ahead.

Nearly every one of these nouns are added to a Glossary. Many of them will eventually be placed around a Circle of Interaction (COIN) diagram that clearly summarizes the process, collaborators and deliverables on a single page.

Why This Matters

When it comes to facilitating and producing a clear understanding of a domain under discussion, if it hasn’t been written then it hasn’t been said. To say it another way, if it’s been said, but hasn’t been recorded, then it will not have the potential to be added to design documentation.
Anticipating this rich time of sharing that naturally occurs at the onset of a structured conversation helps you to seize the moment as a facilitator.
When it comes to facilitating and producing a clear understanding of a domain under discussion, if it hasn’t been written then it hasn’t been said.
Being intentional to listen for and record things that a stakeholder mentions serves the stakeholder and the conversational process well. It keeps things agile. It serves the stakeholder well by respecting their contribution to the conversation. It serves the process by maintaining velocity, by creating a corporate memory of what was mentioned and by listening for those things which will be part of the future-state design documentation.

Want More?

Subscribe to my free blog updates to receive content that vividly describes the techniques and leadership skills that embody the practice of agile design methods. The blog contains not only my ideas on the topic, but the insight of others who actively work and thrive wholeheartedly in the realms of collaborative creativity.

Join us.
0 Comments

Disaffected Boredom

9/15/2017

1 Comment

 

The Office - Clip from season 4 ep 3, score added from Raj Ramaya MUS 270 on Vimeo.


​I love this classic scene from The Office where the office staff are called into a compulsory meeting to hear the latest blah, blah, blah..

Nobody is paying attention to what is being said. Everybody is so disaffected and bored by these meetings that they gamify them by intently watching the DVD screen saver, all the while anticipating it's perfect landing in one of the corners.

As meeting facilitators, the obligation and challenge is on us to create meetings that are purposeful, well-directed and worthy of the engagement and attention of the attendees.

For further suggestions on effectively scheduling meetings, consider Meyer's Rules of Order
1 Comment

Agile Design Notions

9/1/2017

2 Comments

 
Agile design methods make process design conversations flow with better collaboration and results.

Making this happen requires intentionality. Here are some notions that influence how to lead and facilitate a group of people using agile design methods.
  • Design "What" before designing "How".
  • Describe "What" using only domain terminology not solution terminology.
  • Defer designing the "How" to solution designers and architects.*
  • Never call a meeting without defining an objective and deliverables.
  • Leave your organizational hat at the door in design meetings.
  • Make design meetings collaborative, kinesthetic, non-digital and visual.
  • We make progress as we write things down. 
  • An idea not captured is an idea lost.
  • Having multiple whiteboards in a meeting room enhances flow.
  • Your smartphone camera is your friend for capturing whiteboard work and moving forward.
  • When the hive stops buzzing, it is time to take a break.****
  • Trust is an accelerator. Fear is an inhibitor.
  • Trust modeled by leaders begets trust in the meeting room.
  • A conversational framework is more important to have during design meetings than a having solution framework.
  • It takes less time to be approximately right than it does to be precisely wrong.
  • Friends develop solutions. Enemies only deliver documentation.*
  • "Tell me more" is a magic phrase that leads to the discovery of real issues/problems.*
  • A market problem always has a significant emotional component to address.*
  • Never ask a question with the answer in mind.
  • As a facilitator, stating what you see is as effective as asking a question of the group.
  • "I don't know" is a safe first response that ultimately must be assigned and answered.
  • Always have a scribe working in the room.
  • People routinely fail at following a process. However almost anyone can immediately perceive when something is out of alignment.**
  • Confusion is costly.***
  • Clarity puts a stop to confusion.

* Pragmatic Marketing
** Paraphrase inspired by Alistair Cockburn
*** Jeff Jones of Bild
**** Gary Evans of Evanetics
2 Comments
<<Previous

    Learn the Art of
    ​Successful Agile Design

    Picture

    About Chuck Boudreau

    (boo'-dro) - I help people design solutions collaboratively using agile design methods. I have 30+ years of experience in designing software solutions and business processes, leading cross-functional process improvement teams as a business analyst, and helping product managers define and position products using Pragmatic Marketing. I am passionate about user experience design, dog training, beating drums in musical ensembles and collaboratively creating solutions with people.

    Chuck's Resume
    File Size: 67 kb
    File Type: pdf
    Download File



    Archives

    April 2018
    March 2018
    February 2018
    January 2018
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    June 2017
    May 2017

    Categories

    All
    Agile Design
    Boredom
    Collaboration
    Connecteness
    Conversational Framework
    Design Insights
    Design Specification
    Design The "What"
    Documentation
    Empathy
    Environment
    Facilitation
    Feature Lists
    Future State Design
    Glossary
    Ideal Solution Statement
    Leadership
    Learning And Discovery
    Marketing
    Meetings
    Observation
    Pitfalls
    Problem Statement
    Requirements
    Scribe
    Solution Design
    Solution Designers
    Solution Development
    Solution Marketers
    Success Criteria
    Tips And Techniques
    Trust
    Use Cases
    Users
    User Stories
    Velocity

    RSS Feed

© 2016-2023 Chuck Boudreau | Privacy Policy

Photo used under Creative Commons from Sasquatch I
  • Blog
  • Methods
  • Resources
    • Online Course
    • Mobile App
    • Public Course
  • Contact Chuck
  • Search