Mapping out all the steps a customer takes while interacting with my organization is a powerful way to improve the customer experience. Customer journey maps clarify what customers are trying to do, what barriers they face, and how they feel during each interaction with our program and service. 

Understanding customer personas,  such as how people join our learning program, complete online registration, or file a complaint, is what journey maps are known for. Many companies don’t realize that these maps can also help them identify broader business opportunities or challenges that customers face. For example, new learners do not know how to register for the education program. 

Have you walked into a store and seen empty shelves lately? You might have heard in the news that it could be related to a supply chain issue. Factors such as bottlenecks or constraints can impact product delivery and cause these issues. This workshop is for Scrum Masters, Agile Project Managers, and leaders who want to learn how to handle bottlenecks and/or constraints in their product delivery with a better Kanban board flow. The workshop will explore the Theory of Constraints (TOC) and Little’s Law theory to help participants manage the Kanban flow. Participants will examine the primary value stream and Kanban flow, identify the constraints or bottlenecks of product delivery, and apply the theory of rules with a better flow to deal with bottlenecks and/or constraints in their projects. We intend participants to use the same methods to deal with supply chain issues in manufacturing, services, IT, or any product industry and deliver products to their customers on time. 

While our program has grown up to have 16 teams, our Design Systems team still has the same amount of resources. We ran into a question - should we add more resources or find a better way to integrate SAFe (Scaling Agile Framework) along with the design process? Another concern is that the Design Systems team receives many ad hoc requests from different teams that are asking for the same prototype with a slightly different flavor. Our architects and designers are also not usually in sync of the UI/UX dynamics.

This workshop will present a 4-D (Discover, Define, Design, and Deliver) model to help the Design Systems team integrate with all development teams to plan wisely to avoid duplicates or last-minute requests. The 4-D model aims to follow Agile and Lean principles to promote increased collaboration and interaction among individuals and teams. The model uses Design Thinking and Lean Startup concepts to design the right systems to gain customer values. Most importantly, our Design Systems team can improve their stakeholder engagement with shorter planning of iteration where our development team can produce software faster. The 4-D model proves a better product performance that requires more collaborative and shared design work with frequent agile delivery of customer-valued products. We anticipate UI/UX designers, architects, portfolio managers, product owners, project managers, scrum masters, and agile coaches who want to learn how to collaborate SAFe and design for better product performance join this workshop and take away the technique to improve their enterprise level of design processes.

As companies continue to adopt agile and lean, they also need to use design thinking to help them build the right problem and connection to their users, not just the sponsors or customers. Developing the product to meet enterprise needs is the only way to sustain the business to gain marketing comparative. In this workshop, we will engage the audience to learn design thinking, lean’s test and learn, and review agile iterative and incremental development. Audiences will learn why we must marry lean, lean, and agile. They will take away all benefits statements. During the workshop, we present some case studies. We also encourage the audience to explore what problems they want to tackle by using the concepts.

When organizations are ready to adopt Agile at the enterprise level, people are resistant to organizational changes and have a fear of change due to loss. Use NLP and Logic Level to deal with the fear.

Agile commitment is different from time management which just fills in the request and schedule to deliver the request in a certain timeframe.

What is Agile commitment management? When product owner makes requests based on shared meaning, development team negotiates the request through planning and then keeps their commitment during execution. To keep their commitment, the development team continues negotiating their promises throughout the process until product owner acceptance the promise. It seems easy, but it is difficult to implement the Agile commitment model as shown in the graph. Some people have difficulties to make the right requests, so the wrong behavior simply goes on and on. Most people have difficulties to say NO. Therefore, they take risks not to keep their promises due to over- commitment.

When product owner can’t make good requests, in most cases, it must do with languages (or speech acts). There are three kinds of speech acts: assertion, assessments, and declarations. The product owner will determine when to use which speech act based on context which may include individual preference, relationships, or organizational culture. For example, the image is 600 pixels (assertion). Or the image is as clear as crystal (assessment). Or I like to have no image on all subpages (declaration).

People are afraid of saying “NO” for many reasons. It may be related job security (can’t say “NO” to the boss) or dignity (fear of losing personal power), or relationship (rejecting people). In fact, when we say No (or close the door) to one thing, it may say “YES” (or open the door) to many things. For example, if we say “NO” to many meaningful tasks, we can focus on the most valuable one.

(Note: The Agile Commitment Model is adopted from Source: SOAR training)

Most people have a fear of change. The organizational change could not take effect if management ignores people’s fear of change. The workshop proposes adopting attachment theory to ease people's fear when organizations are ready to adopt Agile at the enterprise level. Dr. Victoria Grady, a professor at George Mason University, said people usually are not resistant to change, but just express the feeling of future inconvenience. In general, human’s nature does not like change because of attachment theory, per Grady. The attachment theory is as simple as babies are attached to their mothers. People do not consciously resist changes but naturally, react to something of the loss of an attachment. For example, what would infants react when they are separated from their mothers? What would employees react when their organization is ready to use a new process?

What if we don’t deal with the loss of attachment, what are the impacts? Many lessons learned told us why scaling Agile failed, but it is not clear how organizations handle people’s fear during the organizational transition. The evidence also shows that 68% initiates failed because organizations do not understand attachment theory. For example, employees’ frustrations may decrease productivities. We certainly don’t want the organization to fail when transition to enterprise Agile. So, we will learn how we can ease people’s fear of organizational changes based on the theory. Once we understand what behaviors caused by the loss, we can seek solutions or mitigate the risks for a smoother transition. For example, the organization is under the functional organizational structure. Each team member has the same function, but now the organization requires cross-functional team structure. The solution would be to advocate employee engagement and leadership support.

How did you distribute your 168 hours a week? If you spent more than 42% at work, this is the
workshop for you. How often do you check your smartphone? If you check your phone every hour or less, you would be interested in learning how to deal with your stressful life. Do you spend your day of back‐to‐back meetings, a hundred or so emails, interminable conference calls, dozens of decisions, a contentious conversation or two, and a rough commute? When we are all busy at work or in our lives, have you thought about how you could make the impact to gain your happy work life?

This workshop is to help you through a mindfulness journey to identify what you can make a
difference or any alternative to organize your mindfulness game plan to stay on track with it. For
example, how could we manage our time better to get a beautiful mind?
This workshop is based on a book “Overworked and Overwhelmed” by Scott Eblin who
introduces the following three steps:

• Your best: You will organize the characteristics and behaviors that reflect how you are
  when you are showing up as the best version of yourself
• Your Routine: If you want to be in the certain way (excellence), you have to do things that
  reinforce that state.
• Outcomes: What difference do you want to make in your professional life, working
  environment, and community

You will determine your most important goals and sets you on a course to reach them. Get started by clarifying the core characteristic that represents you at your best when you feel most comfortable and productive. The routines in four domains could be physical, spiritual, mental, and relational that will reinforce peak performance. Through the reflection, we hope to care for the three main areas ‐ at your best, what the routines to make you at best, and what outcome would come in team, community, organization.

How many of you organize your daily activities by using a calendar? Do you have back-to-back meetings, endless reports, and unproductive conversations? After spending 12 hours a day, you might be happy that you have done everything you could to fill in the day. You are exhausted. However, the feeling of victory came very short after you realize you forgot someone’s birthday and that person is the most important one in your life. Or you forgot to do the most important thing that was not on your TO-DO list but could get you the best results. One day, you woke up and you realize that you want to do something differently and meaningful. You started to hate the unproductive meetings. You complained why you should do something that you do not want to do.  You were wondering how you could use your limited resources (time, money, mind, help from others) to do something that has actual value. The answer is Agile which helps you manage your commitments. Agile is a mindset that gets feedback and delivers value iteratively. 

How does Agile help commitment management? When product owner makes requests based on shared meaning, development team negotiates the request through planning and then keeps their commitment during execution. To maintain their promises, the development team continues negotiating their promises throughout the process until product owner acceptance the promise. Therefore, it is different from time management which just fills in the request and schedule to deliver the request in a specified timeframe.

It seems easy, but it 's hard to implement the Agile commitment model as shown in the graph. Some people have difficulties to make the right requests, so the inappropriate behavior only goes on and on. Most people have problems to say NO. Therefore, they take risks not to keep their promises due to over- commitment.

When product owner can’t make proper requests, in most cases, it must do with languages (or speech acts). There are three kinds of speech acts: assertion, assessments, and declarations. The product owner will determine when to use which speech act based on context which may include individual preference, relationships, or organizational culture. For example, the image is 600 pixels (assertion). Or the image is as clear as crystal (assessment). Or I like to have no image on all subpages (declaration).

People are afraid of saying “NO” for many reasons. It may be related job security (can’s say “NO” to the boss) or dignity (fear of losing personal power), or relationship (rejecting people). In fact, when we say No (or close the door) to one thing, it may mean “YES” (or open the door) to many things. For example, if we say “NO” to many essential tasks, we can focus on the most valuable one.

The purpose of Agile Commitment Model is to establish trusts, relationships, successes, and self-esteems. It is a win-win proposition to make both parties (requesters and committers) engaged. When the promise is unfilled, it is recommended using a useful tool called responsible complaint to seek minimizes resentment, to keep healthy relationships and to sustain collaboration.  The following are steps to make a responsible complaint.

1. Set up a SAFE context to ensure the conversation is for keeping moving on the completion of the request, not to blame.
2. Start with the fact that refers to the previous promise.
3. Share constructive feedback and find root causes
4. Modify the request or to make a new one if the old one is unsanctionable
5. Assess the level of complaint

It is not possible for us to keep 100% of the promises that we make, but it is possible to manage 100% of the commitments. The Agile Commitment Model is moving away from punishments, but effectively builds a culture of accountability by making valid requests and productive commitments.

 (Note: The Agile Commitment Model is adopted from Source: SOAR training)

 Dr. Saya Sone is a Professional Certified Coach (PCC), an Enterprise Agile Coach, a professor at VIU (Virginia International University), and Distinguished Toastmaster (DTM). Her passion is to help her clients such as CTO, CEO, Individuals, and teams to discover their new beliefs, thoughts, directions, or emotions that strengthen their capabilities to accomplish their priorities. Her happiness is to be a partner when her clients grown in their potentials.

When Dr. Sone enjoys delivering her speeches in schools, conferences, meetups, and organizations, her topics include motivations for behavioral changes, keeping balance for maximum growth, designing Lean Canvas to recognize MVP (Minimal Viable product), setting goals to achieve life potential and a variety of Agile and coaching related topics.

 Dr. Sone is a Doctor of Business Administration (DBA). She wrote two books Business Value of Agile Methods: Maximizing ROI with Just-in-Time Processes and Documentation” and Mapping Agile Practices to Project Management Challenges.

 The following is Dr. Sone’s presentation history.

• Distinguished Toastmasters, delivered 60+ public speeches (2008-Present)
• Drupal4Gov, Session Speaker, April 2015
• Drupal4Gov, Lightning Talk Speaker, November 2015
• Agile 2014, Lightning Talk Speaker, August 2014
• Agile 2015, Lightning Talk Speaker, August 2015
• Agile 2016, Session Speaker, July 2016
• Meetup at Arlington, Presenter, June 2015
• Meetup at Sterling, Presenter, September 2015
• Meetup at Sterling, Presenter, June 2016
• VIU Session Speaker, Faculty Development Meeting, August 2015 (Current: VIU Adjunct Faculty)
• VIU Lunch and Learn, Speaker, June 2016
• Agile Conference 2016, July 2016
• DHS Agile Community of Interest (COI), March 2017
• PMI Lunch Meeting at Sterling, April 2017
• PMI Lunch Meeting at Reston, May 2017
• DrupalGovConf, Session Speaker, July 2017

Let us admit it. Agile team often lives under a fast pace to deliver working software in a very short cycle. Some team members could not adopt agility and finally burst out that they started to dislike Agile. As a leader or an Agile coach, the major factor to success is to help teams keep a balance for maximum grow so team can engage in delivering software as expected.

The basic idea to maximize growth is to keep balanced amount of challenge and support as appropriate for your team. Just like when you are a little child, your parent give you challenge (”Here, kid, lace ‘em up!”) or support (”let me tie them for you…”). The imbalance could impact your team’s performance.  Too much support, your team will never really learn what they need to grow and develop, on the other hand, too much challenge, and the team will become frustrated and possibly quit trying. It is important for leaders and coaches to understand that team will accept challenge when they are ready. For example, introducing pair programming to your team when they are not ready to adopt the technique, the action would become a burden or an artificial for your team. They may just fake it out.

How does all of this relate to the Agile practices? The Agile experience is one of the greatest experiments of growth in testing team’s collaboration. For that growth to occur, each team member needs to be challenged (and supported) appropriately through a variety of experiences, both inside and out of the team environment. Some of these experiences may be unpleasant, like fixing your own defects. Challenge and support does not imply that the team member will never experience failure or negative consequences, but what it does imply is that when those consequences take place, there will be individuals and processes in place to support the team member as they learn from the Agile experience. Support comes from a lot of places, including management, organization, Agile coach, CEO, or colleagues. However, a major component of that support comes from the encouragement we all give to the team to keep trying and to ask for help with each other.

For many Agile teams, risk management practices are ad hoc or patchy. Admit it! We actually overlooked potential operational risk. The consequence is that we lost the opportunity to launch a product in production in time. We also ignored risk mitigation. We did not place the mitigation in our product backlog because we think risk is not a product feature. In this workshop, we want to introduce a butterfly risk model originated from Bowtie model to help us better manage our risk when working on Agile projects.

Butterfly Risk Model is used to map out the progression of a risk from underlying cause, to risk event, to consequence. The cause of the risk includes underlying factors and conditions. The consequences contains outcomes and impacts on objectives. After identifying the risk, we want to control risk with preventions and treatments. After the event triggered with potential objective, we need to have the mitigation capabilities.  

In order to integrate risk in the product backlog, we will assess the risk with the following formula, Probability x Impact = Expected Outcome Value. We will also use Fibonacci method to evaluate our efforts to mitigate the risk. We then use the same prioritization technique based on expected outcome value and efforts to identify the top risk item. We then integrate the risk in our product backlog.