MBA196: Customer Journey Treasure Hunting
Sep 24, 2019
Show notes
Vince Mirabelli shares some practical, how-to approaches to developing empathy, mapping the customer journey, and finding business process improvement opportunities along the way.
Show Notes
An Empathy Map is a tool you can use to understand who your
customer is, their pain points, and what they think and feel about the problem
you’re trying to solve. Ultimately, it
helps us understand what customers want from us.
Empathy Maps give us insight into who and the why. Who are our customers, what do they need and
why is it important to them?
Once you understand your customer and their needs, you can
move on to a Customer Journey Map.
You can think of a Customer Journey Map as an outside in process
map. It’s a process map from the
customer’s perspective.
You can use a Customer Journey Map to better understand the
customer’s interactions with your organization and make working with you
easier. It can also help you to
understand high and low interaction points to discover ways to improve.
Armed with the information from your Empathy Map and Journey
Map, you can now prioritize opportunities to benefit your customers.
Listen to the full episode to understand how to use these
tools and more to find the right opportunities to bring more value to your
customers.
Customer Journey Treasure Hunting with Vince MirabelliUse coupon Code MBABBC to save 15%
Your Homework
Understand who your customer is and go and talk to them. Find out what it is that they need and why it’s important. Be on the lookout for both stated needs and unstated needs.
Vincent Mirabelli Vince is a leader in the fields of Business Process Improvement, Business Analysis and Lean Six Sigma, is a frequent speaker and workshop facilitator, and host of the podcast, “In Process”. He is a certified Project Management Professional (PMP®), Certified Business Analysis Professional (CBAP®), Certified Customer Experience Professional (CCXP), and a Lean Six Sigma Master Black Belt.
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
Kent McDonald shares his thoughts about what you need to know about Agile and how to use Example Mapping; a technique to create a shared understanding.
Show Notes
In addition to participating on the Product Ownership Panel
during the Building Business Capability conference, Kent is also leading a
workshop, 7 Things You Need to Know About Agile.
One of the big challenges in organizations transforming to
Agile ways of working is shifting from doing Agile (following certain practices
and events) and bring Agile (adopting an Agile mindset and living the values).
Without the right mindset, your team and organization will
never reap all of the benefits of Agile.
In addition to dispelling some of the myths and
misconceptions about Agile, Kent will share a great technique in his session, How
to Build Shared Understanding with Example Mapping.
Example mapping is a great way to structure a conversation
in a way that people with diverse knowledge can develop a shared understanding.
You can use this powerful approach
before you build anything; when you’re fleshing out features and stories.
Example Mapping: Create a shared understandingUse coupon Code MBABBC to save 15%
Your Homework
Tip #1: If you have the chance to work with a UX person, take advantage of that opportunity as much as possible. You’ll improve the discovery and elicitation process as well as learn new things. Tip #2: If you need to understand the business rules that apply to your project, don’t ask stakeholders for the business rules. Instead, ask them to provide some examples. From those examples, you can infer the business rules and get feedback from the stakeholder.
Kent McDonald writes about and practices software product management. He has IT and product development experience in a variety of industries. Kent currently practices his craft for a leading agriscience company and provides just in time resources for product owners and business analysts at KBP.media and Product Collective.
Kent is writing a new book: How to be an Agile Business Analyst. A pre-publication version is available for sale on Leanpub, and if you buy it now, you’ll get the current version and all subsequent updates. Podcast listeners can get the book for the special price of $15.99 (normally $29.99) and this special price will be good until the start of BBC (November 10): https://leanpub.com/agile-business-analyst/c/mba
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
MBA194: Start Your Project Off Right
Sep 10, 2019
Show notes
In this episode, Adrian Reed shares his advice for successfully initiating projects and stakeholder management. Show Notes If you’ve ever been thrown into a messy project where the goal and scope aren’t well defined, Adrian Reed’s session at this year’s BBC conference can help. In Navigating the Mess, Adrian blends some traditional business analysis techniques with systems thinking approaches. In addition to helping you sort out the mess and gail clarity and alignment on your project, Adrian will take you beyond stakeholder engagement. The typical two-by-two influence and impact grid for stakeholder analysis leads to under representation of key stakeholders. Often, these are ghe people who will be using your solution. Listen to the full episode to get more information about engaging with the right stakeholders and starting your project the right way. Start your project the right way – with Adrian Reed Use coupon Code MBABBC to save 15% on your conference registration. Your HomeworkDon’t be surprised by an unknown or underrepresented stakeholder. On your next project, reflect on the following question.Who is the stakeholder that we’re missing? Who’s voice isn’t being heard?Make sure everyone who needs to have a voice has one. Links Mentioned in this Episode Adrian’s Blog: http://www.adrianreed.co.uk Blackmetric WebinarsBBC – the Building Business Capability Conference Adrian Reed Adrian is a Principal Consultant and Director at Blackmetric Business Solutions where he provides business analysis consultancy and training solutions. He also speaks internationally on topics relating to business analysis and business change. Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. Latest Posts MBA228: Software Development Pearls MBA227: The Minimum Viable Business MBALC: Elon Musk’s 5-Step Design Process MBA226: The FOCCCUS Formula MBA225: The Value of Business Models MBA224: Corkscrew Thinking MBA223: The Human Work Machine MBA222: Testing Your Business Ideas MBA221: Systems Thinking and Business Agility MBA220: Thoughtless Design with Karl Wiegers MBA219: How To Be an Agile Business Analyst BA Toolbox – A3 Report MBA218: Customer-Centric Transformation Lightning Cast: Agile Planning MBA217: Objectives and Key Results Lightning Cast: POWER Start for Your Meetings MBA216: Outcome Based Change Lightning Cast: Resistance to Change MBA215: The Challenges with Leading in Product Management MBA214: The BA Success Path MBA213: Applying Theory of Constraints MBA212: Transforming Your Work with Modern Agile MBA211: Adaptive Leadership MBA210: Vital Communication MBA209: Visual Thinking MBA208: Facilitative Leadership MBA207: Bad Behaviors in the Workplace MBA206: Succeeding with Analytics Lightning Cast: BA Goals Revisited MBA205: Beyond Data Literacy MBA204: Top Skills for 2020 MBA203: Career Insurance Yes, Virginia, There Are BAs in Agile Lightning Cast: Failure to Launch (a new product) MBA202: Business Value Analysis MBA201: Tips From an Accidental Product Owner MBA200: Take Action! The Best Advice from Over 200 Episodes MBA199: The Future of the BA Profession MBA198: DevOps – What it Means for BAs MBA197: Making Change Fun MBA196: Customer Journey Treasure Hunting MBA195: Example Mapping MBA194: Start Your Project Off Right MBA193: About Your Career Lightning Cast: Story Estimation – What’s the Point? Lightning Cast: Requirements Rot MBA192: The Blight of Product Debt Lightning Cast: The Power to Get Things Done MBA191: Use Cases in Agile Lightning Cast: AI – Can you be replaced by a machine? MBA190: Business Data Analytics Lightning Cast: You Are a Facilitator MBA189: Adventures in Product Ownership Lightning Cast: Simplified Value Stream Mapping MBA188: The Four Ps of Product Ownership Lightning Cast: Product Debt MBA187: Transitioning to a Scrum Master Role Lightning Cast: Business Agility MBA186: Exploring Product Ownership Lightning Cast: Don’t Throw it Over the Wall MBA185: Business Analysis in Agile Lightning Cast: Non-Functional Requirements in Agile MBA184: Discover What Customers Want with JTBD Lightning Cast: We Are the Business MBA183: The BA Role on a Scrum Team MBA182: BA in the Service Industry Lightning Cast: Death, Taxes, and Missed Requirements MBA181: The Three BA Archetypes MBA180: Socratic Questioning Lightning Cast: BA Performance Goals MBA179: The Power of Prototyping MBA178: Career Options for BAs MBA177: Product Backlog Refinement MBA176: Predictions for 2019 Lightning Cast: A Visit From the Business Analyst MBA175: Product Management is the New Business Analysis – Part 2 MBA174: Product Management is the New Business Analysis MBA173: Avoiding the Build Trap MBA172: Decide Smarter Faster with Kupe Kupersmith MBA171: Your Questions Answered – Listener Mailbag MBA170: Persuasion – Get Buy-In for Your Ideas Lightning Cast: Big Design Up Front MBA169: Digital Business Analyst Competencies MBA168: Exploring the BA Career Path MBA167: The Power of Storytelling MBA166: Mastering the Art of Feedback Special Message MBA165: Remembering Jerry Weinberg Lightning Cast: Think as a Customer MBA164: The Agile Analysis Certification MBA163: Lean Six Sigma – What You Should Know Lightning Cast: Moving to a BA Role MBA162: The Business Analyst Role and its Real Value MBA161: Evolution of the BA Role Lightning Cast: Dude’s Law MBA160: The Art of Better Business Requirements Lightning Cast: Business Agility MBA159: Experiment Driven Development MBA158: Agile Requirements MBA157: The Importance of Good Data Analysis Lightning Cast: Symptoms of Success MBA156: The Power of Mentoring MBA155: Hiring BAs and PMs MBA154: Change Leadership Lightning Cast: BA on a Scrum Team MBA153: Trends in Business Analysis Lightning Cast: Powerful Questions MBA152: Finding the Right Project Lightning Cast: Order your Backlog MBA151: Your Consulting Practice – with Karl Wiegers Lightning Cast: Which Communications Channel Should You Use? MBA150: A High Five for Business Analysts Lightning Cast: Common Issues Facing Business Analysts Today MBA149: The Power of EQ Lightning Cast: The Business Alchemist MBA148: 7 Keys to Succeeding with Agile Lightning Cast: Trust – The One Thing that Changes Everything MBA147: The Business Agility Manifesto MBA146: The Full Stack Business Analyst MBA145: Predictions for 2018 Lightning Cast: Confessions of a Recovering Perfectionist MBA144: The 12 Days of the Project Lightning Cast: Stepping Up to Product Ownership MBA143: Imposter Syndrome – Banishing Your Inner Critic Lightning Cast: Root Cause Analysis Lightning Cast: Using Competency Models MBA142: Lean Startup for the Enterprise MBA141: Digital Transformation – What is Means for BAs MBA140: Improve Influence with NLP Lightning Cast: Better Communication Using the DiSC Model MBA139: Thin Slicing Problem Analysis Lightning Cast: The Many Uses of a SIPOC MBA138: Building a Believable Business Case Lightning Cast: Stay in Your Lane MBA137: Challenges with User Stories – with Mike Cohn MBA136: What the IIBA Can Do for You – Part2 MBA135: What the IIBA Can Do for You Lightning Cast: Flip the Script in Your Job Search MBA134: Distinguishing Yourself in Your Career Lightning Cast: Brainstorming – You’re Doing It Wrong! MBA133: What BAs Need to Know About Agile Lightning Cast: Requirements Quality MBA132: Next Generation Competencies Lightning Cast: The Agile Business Analyst Mindset MBA131: Interviewing for a Business Analyst Position Lightning Cast: The Business Analyst Career Path MBA130: Exploring Requirements with Jerry Weinberg MBA129: Real Life Agile, UX, and Design Thinking MBA128: Where Should the Business Analyst Reside? MBA127: Guiding Principles for the Business Analyst – part 2 MBA126: Guiding Principles for the Business Analyst MBA125: Become the Conscience of the Business MBA124: Business Analyst in an Agile Environment MBA123: The 21st Century Business Analyst MBA122: Driving Real Value Through Business Analysis MBA121: Mastering Product Ownership MBA120: Jobs to be Done Theory MBA119: What’s in Your Backlog? MBA118: Virtual Leadership MBA117: Getting Requirements Right MBA116: Implementing Solutions vs Problem Solving MBA115: Political Martial Arts – Navigating Office Politics MBA114: Value Proposition of the BA Role MBA113: Problem Solving – The RIGHT Stuff MBA112: User Centered Design MBA111: Design Thinking IS Good Business Analysis MBA110: Managing Ambiguous Requirements MBA109: Foundations in Business Analysis MBA108: Prioritizing with the MVP MBA107: Backlog Refinement – From Misunderstanding to Collaborative Discovery MBA106: Rapid Requirements Gathering MBA105: The Best Advice I Ever Received MBA104: Predictions for 2017 MBA103: How Mr. Finch Stole the Project MBA102: Product Management – Build the Right Thing MBA101: Split Your Stories! MBA100: My Biggest Mistake MBA099: Assumptions Mapping MBA098: The Art and Science of Influence MBA097: Partnership Between the PM and BA MBA096: The Standard for Business Analysis MBA095: Lean Change Management MBA094: Perspectives in Business Analysis MBA093: Beyond Project Risk MBA092: Reducing the Risk of Missing Non-Functional Requirements MBA091: Going from Order Taker to Trusted Advisor MBA090: BABOK 3.0 with Richard Larson MBA089: Agile Manifesto – What it Means to Business Analysts MBA088: Effective Requirements Workshops MBA087: Replaced by a Robot – Interview with Kupe Kupersmith MBA086: DocOps – Keep Your Documentation Agile MBA085: From Models to Stories MBA084: Agile Modeling with Scott Ambler MBA083: The BA Core Concept Model MBA082: Addressing Bottlenecks with Theory of Constraints MBA081: User Story Mapping with David Hussman MBA080: Think Like a Freak MBA079: Effective Collaboration MBA078: Design Sprints MBA077: Preparing for the Future of Business Analysis MBA076: Product Strategy MBA075: Slices of Big Truths MBA074: Lean Business Analysis MBA073: Agile Requirements – What’s Different MBA072: Improve Your Facilitation MBA071: The Essence of Business Analysis MBA070: Better BA and PM Collaboration MBA069: Business Rules – What You Need to Know MBA068: Realities of Being a Product Owner MBA067: All About the PMI-PBA Certification MBA066: Starting a BA Community of Practice MBA065: The Value of Business Analysis MBA064: Transitioning to a Product Owner Role MBA063: Starting a Career in Business Analysis MBA062: Peer Reviews for Better Requirements MBA061: Overcoming Roadblocks to Success on Complex Projects MBA060: Business Architecture and Business Analysis MBA059: Problem Solving for Business Analysts MBA058: Reusable Discovery Testing MBA057: The 6 Stakeholders You’ll Meet in Project Hell MBA056: Design Thinking for Better Business Analysis MBA055: The Agile BA – Interview with Ryland Leyton MBA054: Strategy and its Role in Business Analysis MBA053: Use Cases and Beyond – with Ivar Jacobson MBA052: Portfolio Management & The Agile Extension MBA051: A Visit From the Business Analyst MBA050: The T-Shaped Business Analyst MBA049: The First Line of Defense Against a Security Breach MBA048: Finding the Minimum Viable Product MBA047: The DNA of a Great Agile Business Analyst MBA046: The Product Owner / Business Analyst Relationship MBA045: The Agile BA – Myths and Misconceptions MBA044: Business Process Automation MBA043: Abuser Stories – Think Like a Bad Guy MBA042: Stop Using User Stories – Interview with Jim Benson MBA041: What’s the Second Best User Story? MBA040: User Stories – Are You Ready? MBA039: The Big Deal with Big Data MBA038: Use Cases, CX, and UX: Putting it all together MBA037: The Key to Better Collaboration MBA036: Psychology of Leadership – Interview with Cillín Hearns MBA035: Active Listening – The Most Important Skill MBA034: Use Case 2.0 – Interview with Ian Spence MBA033: Landing and Succeeding in Your First BA Role – Interview with Alex Papworth MBA032: Systems Thinking – Interview with Paula Bell MBA031: UX – Are you Experienced? Interview with Neil Turner MBA030: Myths and Patterns of Organizational Change – Interview with Linda Rising MBA029: Business Process Improvement – Keep it Simple – Interview with Brian Hunt MBA028: Talking Techie and Presenting Complex Ideas with Melissa Marshall MBA027: Elicit User Requirements with Legos – Interview with Ellen Grove MBA026: Guarding Against Scope Creep MBA025: Don’t Just Make Software, Make an Impact – Interview with Gojko Adzic MBA024: Lead with the Power of a Jedi – Interview with Heather Mylan-Mains MBA023: Using Behavior Driven Development for Better User Stories – Interview with Jeffrey Davidson MBA022: How to Know Where to Focus Your Efforts – Interview with Chris Matts MBA021: Is the Business Analyst Role Just Overhead? Interview with John Sextro MBA020: The Value of Certifications – Interview with David Mantica MBA019: Why Start with Why? Interview with Stephen Shedletzky MBA018: Step Up to Leadership with the Five-Rule Framework – Interview with Scott Stribrny MBA017: Does Your Communications Engine Need a Tune-Up? Interview with David Barrett MBA016: User Story Mapping with Jeff Patton MBA015: Promise Theory for Team Cooperation – Interview with Mark Burgess MBA014: The Future of Business Analysis – Interview with David Mantica MBA013: Trust is the New Workplace Currency – Interview with Nan Russell MBA012: Beyond Requirements – Interview with Kent McDonald MBA011: Make Your Waterfall Projects More Agile MBA010: Make Virtual Meetings More Effective – Interview with Angela Wick MBA009: Exploring the 7 Product Dimensions for Better Requirements Discovery – Interview with Mary Gorman MBA008: How to Discover Product Requirements – Interview with Ellen Gottesdiener MBA007: How to be a Badass Business Analyst – Interview with Bob Prentiss MBA006: The Business Analyst Career Path – Interview with David DeWitt MBA005: Interview with Len Lagestee – How can a BA deliver value to an Agile Team? MBA004: Defeat the Meeting Super Villians MBA003: How can introverts work well on agile teams – Interview with Ken Howard MBA002: How to Elicit Non-Functional Requirements – Interview with Roxanne Miller MBA001: Introduction to the Mastering Business Analysis Podcast The post MBA194: Start Your Project Off Right appeared first on Mastering Business Analysis.
Lightning Cast: Story Estimation – What’s the Point?
Aug 27, 2019
Show notes
In this episode, we explore the use (and misuse) of story point estimation.
Lightning Casts are shorter episodes, sharing valuable information in 8 minutes or less.
Show Notes
Many Agile teams estimate their User Stories using story
points. When using this approach, many
teams also apply story points incorrectly.
A story point is a relative estimation of effort and
complexity. Story points have no
correlation to hours, days, or and other time measurement. Instead, it’s a tool in which you estimate
based on a comparison to other User Stories.
Some Scrum teams use story points for planning by
calculating the average number of story points completed in the last few iterations
(velocity) and pulling about that many story points worth of stories for the
next iteration.
While velocity can be a useful heuristic, always validate the
team’s confidence level in their ability to complete the planned backlog items.
The more powerful use of story points is in creating a
shared understanding through a discussion.
Below are some dos and don’ts for story point estimation.
Do
Estimate as a team by providing all estimates at
the same time. This helps eliminate bias
and influence of other votes.
Estimate the effort and complexity of the entire
story (coding and testing).
Discuss the differences in votes to develop a
shared understanding of the effort and complexity.
Identify and use reference stories; backlog items
with which the team is familiar to relatively size against.
Estimate stories during backlog refinement.
Don’t
Use story points or velocity to compare teams.
Average the team’s story points to size a story.
Argue against someone’s sizing. Instead, have a discussion about why everyone
voted the way they did.
Size coding and testing efforts separately.
Have the team share their estimations one at a
time. This leads to influencing other
team members and less discussion.
Size during Sprint Planning.
Listen to the full episode to discover how to properly use
story point estimation.
Estimating User Stories with Story Points
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
Lightning Cast: Requirements Rot
Aug 13, 2019
Show notes
Requirements decay over time. Here’s how to prevent Requirements Rot.
Show Notes
Has your organization experienced requirements rot?
A common term in software development is code rot.
Code rot is a slow degradation of the performance of a software
application that will eventually make it unusable. While the software doesn’t
physically decay, this ever-diminishing performance is a result of not being
updated to adapt to the changing environment.
Like code rot, requirements decay over time until they’re
unusable.
When we talk about gathering requirements, imagine gathering
ripe berries along a path. Those small,
valuable pieces of fruit are perfect when we pick them and are best when they’re
consumed soon after they’re picked. That’s
when they’re the freshest.
If we don’t eat those berries soon after they’re picked,
they’ll continue to ripen, then soften, and start to decay until you can no
longer eat them. Requirements are the
same way.
In a typical waterfall project, we’ll spend several weeks or
months eliciting, analyzing, and documenting requirements. After that, the team will likely spend
several more months writing tech specs, coding, and testing. When the project is put into production 6-12
months later, the business environment and customer needs may have changed.
You’ve served rotten requirements.
Even in Agile
People often make the same mistake using an Agile
approach. They create a backlog and then
code and test in small chunks, get feedback, and adapt. That sounds like a good way to prevent
requirements rot.
The problems occur when people do “sort of” Agile. This Wagile or WaterScrumFall approach leads
to waste and requirements rot when we dive too deep into detailed, ready User
Stories too soon.
Do you try to decompose an entire project or epic all up front? Is your product backlog made up of only User Stories that are ready or near ready? Does your team wait for a detailed design before they begin development?
If so, you’ll likely experience requirements rot.
By breaking down a project all up front, we’re wasting effort. As we create something and get feedback, it’s likely that our requirements, User Stories, and approach may change. Many of the User Stories you created will need to change or will no longer be valid.
In addition, the delays waiting for a detailed design makes
it difficult to quickly adapt to changing customer needs. We’re delaying getting something in the hands
of our customers, lengthening the feedback loops, and slowing our
responsiveness to changing market conditions.
Avoid Requirements
Rot
Going back to the analogy of picking ripe berries, if you
wanted to prevent them from rotting you’d pick only enough berries that you
would eat within a few days. As you go
back later to pick more berries, you’ll find more berries have grown and ripened
and you can pick those.
You can do the same with your requirements. Understand the high level view of your
project or epic, perhaps from a workflow or customer experience perspective and
using a story map.
Once you understand the high level, you can determine which
small slices or journeys to prioritize and go into just enough detail on
those. Build something, get feedback,
and adapt.
Continue this process of doing just enough analysis just in
time based on prioritized slices until you have achieved enough value from the
project or initiative and decide to move on to something else.
Remember that lower priority requirements likely have
diminishing returns. It may cost more to
fulfil a requirement that the value it will bring. Try to maximize the amount of work you don’t
do looking critically at the value of some of the slices or requirements.
The real question is “What are you NOT going to do today?”
MBA192: The Blight of Product Debt
Aug 06, 2019
Show notes
In this episode, you’ll discover what Product Debt is and the impact it can have on your product and your organization. You’ll also find out how to address Product Debt and ensure you are delivering valuable solutions quickly.
Show Notes
Debt is what you owe because you borrowed from tomorrow for
something today. This debt needs to be
repaid, often with interest.
Product debt is similar to financial debt. You’re racking up debt related to the design
and features of your product. If you
don’t pay down this debt and the related interest, delivery will slow, you
won’t maximize perceived customer value, and you’ll be unable to innovate.
The Three Types of Product Debt
There are three main types of product debt: feature bloat,
low value features, and poor user experience.
Feature bloat occurs when we add more and more
features. These new features add
complexity to our product and make it more difficult and more expensive to
maintain.
A related type of product debt is adding low value
features. If we focus on implementing
features instead of solving a real and valuable customer problem, we’ll add low
value features.
These two types of product debt are a drag on
organizations. In 2014, The Standish
Group performed an analysis of feature and function usage. They determined that 50% of features are
hardly ever used. An additional 30% are
infrequently used.
Think of the time and money wasted on creating all of those
infrequently or hardly ever used features.
The third type of product debt is a bad user experience. This occurs when we create solutions in silos
or rush to get new features out the door.
The result is a product without a cohesive experience. Because the experience of each features is
different of too many items are added to a tab or new page, it’s difficult for
customers to learn and use.
“Product Debt comes from making rush decisions. It comes from lazy product thinking and design. It comes from the hope that adding just one more feature will solve all of your problems. It comes from wanting to push features as quickly as possible.” – Ben Yoskovitz
What to Do About Product Debt
To address feature bloat, we need to focus on solving
problems, not implementing features. We
also need to ensure that there’s a good problem/solution fit and good product/market
fit. Do your features align to your
product and organizational goals and vision?
Remember that each line of code we write is another line of
code we need to maintain. Be relentless
in keeping everything simple and writing as few lines of code as possible.
If you want to address low value features, ensure you have a
meaningful product vision in place and a goal-oriented roadmap. Those will keep the team focused on
delivering functionality aligned to the product and organization.
You can also use Hypothesis Driven Development, define
success metrics, and test often to ensure your feature solves the right problem
and achieves the right outcomes.
To address debt related to your customer experience, ensure
you perform usability testing. How
quickly and easily can users achieve the goal that the feature was intended to
support.
Prototyping and frequent workflow reviews with experienced
user experience professionals will help you identify and reduce this type of
debt.
Learn to Build
Common thinking is to build something, measure the results,
and learn from those measurements before we build the next iteration. To do this, we often create a Minimum Viable
Product (MVP) to ensure we’ve created something valuable.
The problem is that building an MVP is that it could take
weeks or months. Building an MVP in this
way means that you’re experimenting in one of the more expensive and time
consuming ways possible.
Instead, let’s flip the build-measure-learn cycle.
Let’s first figure out what we need to learn; our
assumptions and hypotheses that we need to validate or invalidate. Next, determine how we can measure that
learning. Finally, build the simplest
possible thing that can give you the needed measurements.
Instead of a Minimum Viable Product, build a Minimum Viable
Prototype. We want to learn and adapt as
quickly and cheaply as possible.
Pay it Down
To reduce product debt, you’ll need to dedicate time to
identify and pay down existing debt.
You’ll also need to ensure that you’re not adding more product debt.
By working to reduce the complexity of new features, asking ‘why’, and testing early and often, you can help your organization regain speed of delivery, boost customer value, and innovate.
Listen to the full episode to understand the root cause of these types of product debt, what to do about it, and discover when product debt is actually a good thing.
The Blight of Product Debt
Your Homework Before you start your next project, ask questions. Work to understand the problem that the feature or project is intended to solve, validate that it’s the right problem to solve, and experiment and prototype to ensure your team can deliver the most customer value as simply as possible.
Lightning Cast: The Power to Get Things Done
Jul 30, 2019
Show notes
In this episode, we’ll discuss the different kinds of power you can use to get things done within your team or across your organization.
Show Notes
Have you ever been frustrated because things aren’t getting
done? Are others failing to do their
part to move your project along?
If you’ve ever wished you had the power to influence others
to take action, this episode is for you.
For larger, more complex initiatives (those we can’t do on our own), we need other people. We may sometimes think that projects would be much easier if it weren’t for the people. But we need others to get things done.
Types of Power
A while back, I heard an episode of the Manager Tools podcast in which they discuss three types of power people use to get things done. Those types of power are role, expertise, and relationships.
Each of these types of power allows you to influence others
to take a specific action.
With role power, you use your positional authority to get
things done. Using role power, you cause
the people who report to you to take action.
This can range from coercion and ordering people around to leading
through setting a compelling vision.
People do as you ask because you’re their boss and you have
the ability to affect their career.
With expertise power, people look to you for answers because
you’re seen as an expert or authority in a specific area. This type of power grows as your knowledge
grows.
People do as you ask because you are an expert.
The third type of power is relationship power. This type of power is built up over time and you
build trust with others in your organization.
Relationships and trust are like a bank account that grows as you invest
time and invest in listening to others.
With relationship power, people do as you ask because you’ve
build trust and they believe in you.
Appropriate Use of Power
Many of us may not have the role power to command
others. But if you do, there are
specific context in which it may be appropriate to use role power.
If there is an emergency or safety is at risk, role power
can be used to ensure things get done quickly or avoid certain types of
risk. However, this should only be the
case in rare exceptions.
Expertise power may be used if you have deep, specific
knowledge in the subject matter. When
using expertise power, help people to understand the ‘why’ behind your
direction so they can make better decisions themselves.
In most situations, relationship power is the most powerful
and sustaining approach. Building
relationships with others creates a collaborative, open environment of
trust. People may reprioritize other work
if you have a strong relationship you ask them for help.
Building and maintaining relationships helps your ability to
influence and get things done.
What relationships do you need to build in your
organization?
The Power to Get Things Done
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
MBA191: Use Cases in Agile
Jul 23, 2019
Show notes
In this episode, Ivar Jacobson shows us how to apply Use Cases in an Agile context and helps us discover how a Use Case approach addresses some of the problems with User Stories.
Show Notes
You may have used Use Cases in a waterfall environment, but can this technique work in Agile?
The most common technique in Agile is User Stories. However, there are a few challenges associated with User Stories.
The big picture is often missed with User Stories because they’re so small. In addition, we may need hundreds of stories for a large initiative.
User Stories also cause us to lose customer focus at times. Even though User Stories are intended to focus on the customer, people often lose that focus given the small size of stories.
Listen to the full episode to understand how to use Use Cases in Agile and the advantages over User Stories.
Use Cases in Agile – Fill in the gap left by User Stories
Your Homework
Wherever you are on your next initiative, ensure you and the team have a good understanding of the big picture as well as the customer needs and goals.
Dr. Ivar Jacobson is a father of use cases, the Unified Modeling Language, and the Rational Unified Process. He is the principal author of seven influential and best-selling books including Business Process Reengineering with Objects, Object Oriented Software Engineering: A Use Case Driven Approach, and Aspect-Oriented Software Development with Use Cases.
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
Lightning Cast: AI – Can you be replaced by a machine?
Jul 16, 2019
Show notes
A Gartner study predicts that 80% of Project Management tasks will be performed by Artificial Intelligence by 2030. Will you lose your job to a machine?
Lightning Casts are shorter episodes, sharing valuable information in 8 minutes or less.
Show Notes
Last year, CIO magazine ran an article with the title How AI Could Revolutionize Project Management. In the article, they describe how automation
can make projects more successful by reducing cost, analyzing risks, making project
work more efficient, and keeping project on time and on budget.
In addition, Gartner published a study earlier this year indicating that 80% of Project Management tasks may be eliminated by 2030. Instead of those tasks being done by Project Managers, Gartner suggests that Artificial Intelligence will perform that work.
This means that Project Management functions such as data
collection, tracking, reporting, forecasting, risk identification, and resource
management may be performed by machines.
Even process improvement initiatives may be better served
through machine learning and Artificial Intelligence.
The problem with machines managing the work is that it
misses the people side; human interaction.
Machines can assign the right resources, but when we see people as
resources or cogs in a machine, we don’t get the benefit of their brains . . .
their creativity . . . their whole
self. Instead, we get a pair of hands
that are told what to do.
Can Machines Elicit Requirements?
For repeatable, “keep the lights on” projects, I could
foresee machines with the ability to product requirements and even future state
diagrams and tech specs.
What about in a future where stakeholders can input what
they want, their “requirements”, and the system spits out working, high quality
code? This isn’t fantasy. There are systems today that can do this to a
small degree, so it’s certainly something we could see in the next 10-20 years.
That process could work for simple or complicated
initiatives, where cause and effect are well understood. But what about complex initiatives where the cause
and effect relationship is only visible in hindsight? Where we need to probe, sense and respond? This is the realm of new product development
and disruptive technology.
Remember that AI needs data from which to learn. But there is little or no past data for most
new product discovery work. I doubt AI
could have come up with the iPad or Netflix streaming video.
If keep the lights on and simple initiatives are eventually
automated, I say that’s good. Then we
can focus on areas that will bring the most value to our customers and to our
organizations. Let’s use our creativity
to shape the future and make our customers awesome.
AI is coming. Will you be replaced?
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
Our TOPPODCAST Picks 
Stay Connected
