TopPodcast.com
Menu
  • Home
  • Top Charts
  • Top Networks
  • Top Apps
  • Top Independents
  • Top Podfluencers
  • Top Picks
    • Top Business Podcasts
    • Top True Crime Podcasts
    • Top Finance Podcasts
    • Top Comedy Podcasts
    • Top Music Podcasts
    • Top Womens Podcasts
    • Top Kids Podcasts
    • Top Sports Podcasts
    • Top News Podcasts
    • Top Tech Podcasts
    • Top Crypto Podcasts
    • Top Entrepreneurial Podcasts
    • Top Fantasy Sports Podcasts
    • Top Political Podcasts
    • Top Science Podcasts
    • Top Self Help Podcasts
    • Top Sports Betting Podcasts
    • Top Stocks Podcasts
  • Podcast News
  • About Us
  • Podcast Advertising
  • Contact
Not in our directory?
Add Show Here
Podcast Equipment
Center

toppodcastlogoOur TOPPODCAST Picks

  • Comedy
  • Crypto
  • Sports
  • News
  • Politics
  • True Crime
  • Business
  • Finance

Follow Us

toppodcastlogoStay Connected

    View Top 200 Chart
    Back to Rankings Page
    Education

    Mastering Business Analysis

    Your key to advancing your career as a Business Analyst and beyond

    Advertise

    Copyright: © MasterClass 247 LLC

    • Apple Podcasts
    • Google Play
    • Spotify

    Latest Episodes:
    MBA086: DocOps – Keep Your Documentation Agile Aug 23, 2016
    Show notes

    In this episode, Mary Connor shows us the power of DocOps; an approach to delivering documentation as lean and as fast as possible.

    

    After listening to this episode, you'll understand:

    • What DocOps is and how it differs from DevOps
    • Three principles behind DocOps
    • How DocOps can address documentation bottlenecks
    • Why DocOps helps you create higher quality documents faster
    

    Show Notes

    The DocOps approach allows you to be as lean and as fast as possible. It’s basic survival for today’s lean agile environment and puts those who create content in line with the way we develop code.

    DocOps includes three key principles:

    • Collaborative Authoring: Requires a fast, collaborative environment tied into a process for continuous updates.
    • Aggregation from Multiple Sources: Instead of content maintained in different places and in silos, everything comes together in one place
    • Customer Integration: Includes a mechanism for customers to provide feedback related to the content. This allows you to quickly update and deploy changes.

    Why DocOps?

    Software releases are getting faster and faster and the drive toward adaptability is becoming more critical. DocOps is about automating absolutely everything outside of the creative, judgment driven part of content creation that only a human being can do.

    This frees you up to take on more or to focus more on the critical pieces that require your expertise. Automating some of the steps also leads to less mistakes.

    DocOps is also critical for accelerating common bottlenecks such as legal reviews and translation of content. Through collaborative authoring and developing in small iterations, you reduce the amount of content to be addressed all at once. From there, a majority of reviews will only be on the minor changes as you iterate and the review process flow can be automated.

    Steps Toward DocOps

    Start by finding out what tools already exist in your organization. The IT department may already have some of the tools you can use to implement DocOps. Some tools, while not specifically developed for DocOps, can be leveraged for use.

    Additionally, some of the software engineers may be knowledgeable in DevOps and related approaches and may have ideas on how to automate some of the documentation processes.

    Try first working with what you have instead of looking for and purchasing new tools.

    DocOps Isn’t Just for Agile

    The underlying principles of DocOps are applicable in any environment, not just agile. Collaborative authoring of documents, breaking down silos, and rapid customer feedback are powerful approaches in any environment. They’re also approaches you can use for your requirements documentation.

    Imagine documenting requirements and allowing your stakeholders to see the changes immediately while allowing them to provide feedback. They can also contribute to the creation of requirements because of the shared environment.

    DocOps can lead to better accuracy of documentation as well as faster generation and better responsiveness to change.

    Listen to the full episode to hear all of Mary’s advice on how to apply DocOps to your work.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA086.mp3

    Z

    Your Homework

    If you have a process to produce customer facing documentation, find a way to automate it. You want the focus to be on the content creation, not on babysitting the process. Start with simple approaches to automation such as batch files, scripts, and a scheduler to pull the document together and move it into a production environment where it’s available to the customer.

    Links mentioned in this episode:

    • Mary’s Website Cleverhamster.com
    • Mary’s Presentation from Keep Austin Agile 2016
    • Win a ticket to BA World Chicago 2016
    • Get 25% off training from ASPE
    Mary Connor

    Mary Connor

    Lead Technical Content Developer at Caringo

    Since bailing on her PhD in English and a life grading papers 20 years ago, Mary has been designing technical documentation in high-tech, focusing on Agile documentation since 2008. Currently the lone writer for Caringo, Mary has created developer documentation for cloud-based API services at Telogis and several generations of web service products at Advanced Solutions. She is all about building authoring environments that free Agile teams to write and diagram information as easily as they code.

    • LinkedIn

    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.

    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.

    The post MBA086: DocOps – Keep Your Documentation Agile appeared first on Mastering Business Analysis.


    MBA085: From Models to Stories Aug 16, 2016
    Show notes

    In this episode, Candase Hokanson helps to understand how to use visual models to not only create a shared understanding, but also to identify user stories and prioritize your backlog.

    

    After listening to this episode, you'll understand:

    • How to use models to create a shared understanding, even with teams that aren’t co-located
    • The five recommended models to use for your next project
    • How to use models to identify user stories and prioritize your backlog
    • Why models are great at identifying missing requirements
    

    Show Notes

    A visual model is a visual representation of a more complex concept. We use models because they’re easy to change and collaborate on. Visual models create a shared understanding and they can also help you build and prioritize your backlog.

    Typically, you’ll use 3-5 models in a project to discover requirements. You don’t need to do all of the models upfront. You can (and should) build models iteratively and incrementally, but models aren’t just for agile projects.

    The five models Candase recommends cover project objectives, project features, the systems, the people, and the data.

    RECOMMENDED MODELS

    Business Objectives Model: This model helps us to understand why are we doing this project. It helps us get to the root cause and address the right thing. Additionally, the Business Objectives Model helps with backlog prioritization.

    Feature Tree: This model lists the project features organized in a tree format similar to a fishbone diagram. Feature Trees help you see what’s missing and creates a clear hierarchy. For further clarity, you can color code feature into phases or sprints.

    Ecosystem Map: This model is similar to a context diagram. It shows what systems and teams are involved and can be used to identify dependencies.

    Process Flow: This model maps out the process and can be decomposed into many levels. Level 1 shows the high level end-to-end process in 5-9 steps. Breaking each step down from there is the Level 2 process flow where we see more of the detail. The Level 2 process flow is the source of most of our user stories because each process flow step becomes one or more user stories.

    Early on, you can develop the Level 1 process flow. At Level 1, you may identify epics and features for the product backlog. Over time, you can break down each step in the Level 1 flow into a Level 2 or 3 process flow just in time and identify related user stories.

    Business Data Diagram: This model grounds your project from the data side. It’s more about how the customer thinks of data and includes data elements such as customer account, addresses, orders, etc. You can continue to add data as you find it in the system.

    The Business Data Diagram can help you identify the business rules or acceptance criteria for your user stories. It can also help you to identify missing user stories.

    You can use the other models to help prioritize the epics, features, and user stories in your backlog so you can identify which you should decompose and deliver first.

    TRACEABILITY

    Using these models creates traceability. Your user stories tie back to steps in your process and include acceptance criteria derived from the Business Data Diagram. Those process steps tie back to features in your feature tree, which trace to business objectives.

    Listen to the full episode for more advice on what models to use and how models can help you identify missing requirements.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA085.mp3

    Z

    Your Homework

    Look at your project to understand where visual models can help and figure out which one you want to use. If it’s a customer facing process, a process flow is often an easy way to understand the steps and identfity user stories associated with those steps. If your project doesn’t have a customer facing component, the Business Objectives model is a great way to understand the objectives and business need and can help with backlog prioritization.

    Links mentioned in this episode:

    • Sielevel website seilevel.com
    • Candase’s presentation from Keep Austin Agile
    • Whitepaper on Visual Models from Candase
    • Business Analyst World Chicago – Win a free ticket!
    Candase Hokanson

    Candase Hokanson

    Senior Product Manager at Seilevel

    Candase is a PMI-Agile Certified Practitioner who trains and coaches Product Owners, Scrum Masters and Business Analysts on agile approaches as well as championing products in those roles for clients. She works with teams to unite every team member around the common end goal of delivered business value to save up to millions of dollars in development costs for features that won’t be used or don’t contribute to the anticipated business value.

    • X
    • LinkedIn

    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.

    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.

    The post MBA085: From Models to Stories appeared first on Mastering Business Analysis.


    MBA084: Agile Modeling with Scott Ambler Aug 09, 2016
    Show notes

    In this episode, Scott Ambler helps us to understand the power of using models and how to use models in an agile environment.

    

    After listening to this episode, you'll understand:

    • Why you should use models in agile
    • What models to use in a given context
    • How to keep models lightweight
    • The link between models and Test Driven Development
    

    Show Notes

    Written documentation is the least effective form of communication to create a shared understanding. We create models to understand, to collaborate, and to work through and explore a design or architecture.

    Ideally, you want to co-create models with the team and stakeholders. Be sure to keep your modeling as lightweight and collaborative as possible. Do just enough modeling and defer commitment until the last responsible moment.

    This allows you to focus on what you know now and what needs to be done now. Later, you will know more and will be able to ask better questions, which will allow you to dive deeper into other areas of the model and iterate.

    How much modeling is just enough? “Just enough” is in the eye of the beholder. It really depends on the context and the situation. Do enough modeling to get everyone on the same page and understand what to do next.

    Models will evolve over time. Some may disappear if they are no longer needed, some may grow and become more detailed, and some new models may appear.

    Common Agile Models

    Any model can be done in an agile manner. Ideally, you would work together collaboratively and do just enough modeling to answer the questions you need answered right now.

    As an example, if you’re building a website, you might use User Stories, use cases, personas, user interface models, prototypes, data models, and network diagrams. The models you choose to create will depend on your situation and context.

    Choosing the right model for the purpose comes from experience. Having many models in your toolkit allows you to be effective in a variety of contexts.

    For business application development projects, there are a few commonly used models including User Stories, User Story maps, UI / sketches, business process models (including flowcharts or activity diagrams), and lightweight data models.

    Yes; user stories can be considered models. A model is an abstraction and a user story represents something more complex.

    Test Driven Development

    Models can be used as a step towards Test Driven Development (TDD). TDD in its simplest form is a process of developing software in which you write tests first, run the test (which should fail), write just enough code for the test to pass, and then refactor the code.

    Modeling is good at thinking things through and understanding, but they’re not very good at providing detail. On the other hand, tests are very good at providing detail, but are bad for high level thinking.

    Use each for their strength. Use models to create a higher level understanding and then use tests to fill in the detail. Modeling first helps everyone to get alignment on the big picture, which can prevent rework after testing.

    Listen to the full episode to hear all of Scott’s advice on agile modeling including how models scale and fit in at the enterprise level.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA084.mp3

    Z

    Your Homework

    Build agile modeling rooms. Create a room or space where you can model and collaborate. This can mean having whiteboards, painting walls with whiteboard paint, using flip charts, etc. This allows you to work through problems and collaborate on solutions.

    Links mentioned in this episode:

    • Scott’s website ScottAmbler.com
    • Disciplined Agile Delivery website
    • Agile Modeling website
    • Win a ticket to BA World Chicago
    Scott Ambler

    Scott Ambler

    Senior Consulting Partner of Scott Ambler + Associates

    Scott works with organizations around the world to help them to improve their software processes. He provides training, coaching, and mentoring in disciplined agile and lean strategies at both the project and organizational level. Scott is the founder of the Agile Modeling, Agile Data, Disciplined Agile, and Enterprise Unified Process methodologies. He is the (co-)author of several books, including Disciplined Agile Delivery, Refactoring Databases, Agile Modeling, Agile Database Techniques, and The Enterprise Unified Process.

    • X
    • LinkedIn

    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.

    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.

    The post MBA084: Agile Modeling with Scott Ambler appeared first on Mastering Business Analysis.


    MBA083: The BA Core Concept Model Aug 02, 2016
    Show notes

    In this episode, we’ll explore the BA Core Concept Model and Julian Sammy will help us to understand how the model can help you and your organization.

    

    After listening to this episode, you'll understand:

    • What the BA Core Concept Model (BACCM) is
    • How to use the BACCM to see the big picture
    • How the BACCM can help you understand stakeholder motivations
    

    Show Notes

    Business Analysis Core Concept Model™ is a conceptual framework comprised of six core concepts critical to the business analysis profession. Understanding how each core concept relates to the other five core concepts will help you to see the system as a whole, know what questions to ask, and understand stakeholder motivations.

    The six core concepts are:

    Change: Transforming from one state to another. Your goal is to prevent harmful change and promote potentially beneficial change.

    Need: Something of potential value to an organization. A need might not be actionable until it becomes a requirement. A requirement is a usable representation of a need.

    Solution: A solution might exist but not be identified or implemented. A design is a usable representation of a solution.

    Stakeholders: Someone who has a relationship with the change or any of the other core concepts. They can be involved at many different levels. A good practice is to think about stakeholders in relation to value. The triangle of Value, Change, and Stakeholder allows you to integrate loss aversion and prospect theory to better understand stakeholder motivation.

    Value: Value is a much deeper concept than most people think. It goes beyond money. Isolate and explore what you mean by “value” and what the money will be used for.

    Context: The background and environment in which you’re functioning. The context influences the other concept items.

    BA Core Concept Model

    Listen to the full episode to understand how to use the BA Core Concept Model.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA083.mp3

    The Business Analysis Core Concept Model is a trademark of the International Institute for Business Analysis.

    Z

    Your Homework

    Ask what value actually means. Is it something tangible or intangible? Understanding what value means to your stakeholders will help you understand their motivations and deliver on expectations.

    Links mentioned in this episode:

    • Julian’s website Change.Fail
    Julian Sammy

    Julian Sammy

    Co-Founder, Thinky Person

    Julian Sammy is a thought leader in the business analysis community and has written and spoken extensively on business analysis and business value through keynote presentations, webinars, consultations, articles, blogs, and books.

    Julian was the Head of Research and Innovation for the IIBA and a major contributor in the development of the Business Analysis Core Concept Model — a work central to business analysis and the BABOK® Guide.

    • X
    • LinkedIn

    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.

    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.

    The post MBA083: The BA Core Concept Model appeared first on Mastering Business Analysis.


    MBA082: Addressing Bottlenecks with Theory of Constraints Jul 26, 2016
    Show notes

    In this episode, we’ll explore how to address bottlenecks and optimize the system using the Theory of Constraints.

    

    After listening to this episode, you'll understand:

    • Why local optimization doesn’t work
    • How to identify bottlenecks
    • How to apply the Five Focusing Steps to address bottlenecks
    • Why hiring more people may not be the answer
    

    Show Notes

    The Theory of Constraints is an approach to improving organizational performance created by Dr. Eli Goldratt and is explained in his book, The Goal. The thought behind Theory of Constraints is that in every organizational system, there is one constraint that limits the flow of value.

    It explains why local optimization doesn’t help and that we need to use systems thinking. Similar to the weakest link in a chain, improvements to the rest of the chain don’t make it stronger. Only by improving that weakest link can we improve the strength of the chain.

    In addition to some tools and practices, the Theory of Constraints uses what Dr. Goldratt refers to as the Five Focusing Steps for optimizing systems. This approach allows you to address constraints is the simplest way possible.

    Step 0: Define the Goal

    Each system has a goal. What is it you want to achieve and how will you know when you’ve reached the goal? To determine the goal, need to understand who uses the output of the System and what’s valuable to them. After you understand that, find metrics to measure the throughput, or amount of value produced by the system.

    Understanding the goal is often the most difficult step in the process. Finding the right goal and the right metrics to measure progress toward that goal will be critical to your success.

    Step 1: Identify the Bottleneck

    Each system has one constraint that determines the throughput of the entire system. The constraint can be a person, a team, a physical machine, one organizational rule, or anything else that limits the speed at which value flows through the system. The constraint is often called a bottleneck.

    At its core, the Theory of Constraints provides an approach to finding the bottleneck and taking action to improve throughput of the system as a whole.

    As mentioned earlier, making improvements anywhere but the bottleneck will not improve the throughput of the system and it can even have a negative effect.

    How do you recognize a bottleneck? If the bottleneck is a person, team, department, or piece of equipment, work piles up in front of them and people downstream of the bottleneck are idle some of the time.

    To help identify the bottleneck, you can use tools like flow charts, swim lane diagrams, root cause analysis, Pareto charts, or queuing models. Remember that a system can only have one constraint at a time.

    It’s important to understand that being a bottleneck doesn’t mean a person or team is bad at what they do or that they’re doing anything wrong. Being the bottleneck is neither good nor bad; it’s just a fact of the system. There’s always one constraint.

    Now that we’ve identified the bottleneck, what can we do to improve throughput?

    Step 2: Exploit the Bottleneck

    The first way to try to address the bottleneck is to “exploit” it. Exploiting the bottleneck isn’t what it sounds like. “Exploiting” means that we’re ensuring that the bottleneck isn’t distracted by non-throughput producing work.

    If you think about it, the flow of value through the system is determined by a single constraint. Therefore, any work done by the bottleneck that doesn’t contribute toward the goal is waste and results in less throughput.

    You can exploit the bottleneck by ensuring that the bottleneck always works on the highest priority, highest value work that contributes to the goal. You can also:

    • Make sure the bottleneck works on only one thing at a time. We want to get to done; stop starting and start finishing.
    • Remove any non-throughput producing work from the bottleneck.
    • Shield the bottleneck from interruptions and quickly remove impediments, but don’t shield them from important information like customer input and feedback.
    • Make sure that the bottleneck is never idle or waiting for information, equipment, or materials. This type of waste reduces the value producing work that the bottleneck can do.

    You may want to use techniques such as brainstorming to identify possible experiments you can try to exploit the bottleneck and improve the system. After you implement the exploit experiment, measure the impact to see if it made a positive change.

    Make sure you only change one thing at a time. If you make multiple changes, you can’t tell if some changes had a positive effect and some had a negative effect.

    After each change, you’ll also want to go back to the beginning to make sure the goal hasn’t changed. You’ll also need to make sure that the bottleneck hasn’t moved.

    Through your improvements, it’s quite possible that the original constraint is no longer the system constraint. You may have improved the bottleneck to a point where they’re no longer the constraint and any additional improvements to the original bottleneck won’t improve the system. That’s why you go back to the first step after each change.

    Start by exploiting the bottleneck because it requires the lowest investment. It only affects the single bottleneck and it doesn’t require additional time or money, but results in higher throughput.

    Step 3: Subordinate Decisions to the Bottleneck

    After you’ve exhausted what you can do through exploiting the bottleneck, the next step is to subordinate decisions to the bottleneck. Subordinating decisions means the rest of the system works to help the bottleneck produce maximum value.

    That’s because people other than the bottleneck have some slack. If everyone is working toward the same goal, anyone working beyond the pace of the bottleneck is not increasing the throughput of the system.

    Instead of working at what they do faster, they can work to the pace of the bottleneck and use their extra capacity to support the bottleneck.

    Some approaches you can use are:

    • Ensure that the work, information, and materials received by the bottleneck as an input to their work is of the highest quality.
    • Have everyone work to the pace of the bottleneck (no faster or slower).
    • Someone else may be able to take some non-specialized tasks from the bottleneck. At this stage, only have someone take on tasks if it doesn’t require a large investment in time or money.

    Subordinating decisions to the bottleneck is done after the exploit step because there’s a slightly higher investment needed, but it’s still relatively easy. Subordination only impacts a few resources and requires little investment.

    As with the exploit step, find a subordination experiment, implement it, and measure the result. Afterwards, go back to the beginning. Has the goal changed? Has the bottleneck changed?

    If not and after you exhausted what you can do to subordinate decisions to the bottleneck, the next step is to elevate the bottleneck.

    Step 4: Elevate the Bottleneck

    After doing what you can to exploit and subordinate, you can elevate the performance of the bottleneck. Elevating the bottleneck requires time and money, so it’s done only after exploiting and subordinating.

    You can elevate the bottleneck and improve performance by:

    • Get more people that can do the same work as the bottleneck.
    • Buy more or faster machines
    • Give people training and better tools
    • Coach for individual improvement
    • Improve the workspace
    • Change organizational policies

    Often we jump right directly to elevating by adding people, getting training, buying equipment and tools. These changes can be expensive and it takes time to get a positive impact on throughput. They could even have a negative effect in the short term.

    Elevate as a last resort when you can’t find any more ways to exploit or subordinate.

    Step 5: Repeat

    Every time you find a potential improvement, implement it, measure the results and go back to the beginning. Make sure the goal is still valid and see if the constraint has moved.

    Theory of Constraints

    The key is to see the system as a whole, understand what’s valuable, and recognize the constraint. After that, make small changes one at a time starting with the easiest and cheapest to implement and measure the results.

    Listen to the full episode to learn how to apply the Theory of Constraints to your process.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA082.mp3

    Z

    Your Homework

    Work with your team to make sure the goal is clearly understood. Without a shared understanding of the goal, you can’t optimize the system. From there, you can identify the constraint and implement one experiment to improve throughput.

    Links mentioned in this episode:

    • Dr. Eli Goldratt’s book, The Goal

    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.

    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.

    The post MBA082: Addressing Bottlenecks with Theory of Constraints appeared first on Mastering Business Analysis.


    MBA081: User Story Mapping with David Hussman Jul 19, 2016
    Show notes

    In this episode, David Hussman walks us through creating a user story map and helps us to understand how to use story maps effectively.

    

    After listening to this episode, you'll understand:

    • Why story maps are a powerful tool
    • How to create a user story map
    • What to do with the story map
    • How to avoid building solutions people don’t want
    

    Show Notes

    A narrative is more powerful than the written form. Applying user stories can be a powerful approach for creating a shared understanding and gaining customer empathy.

    But user stories aren’t just a pile of things to do. There’s an underlying structure that helps you see the big picture from the customer’s point of view.

    By organizing the story cards into a map, we can better understand the customer journey and identify small slices of value to deliver.

    User Story Maps are an arrangement in which story cards from left to right follows people’s interaction with the system and top to bottom to decompose that interaction.

    User story maps are a metaphor for a customer journey. That means you’re taking people somewhere instead of just getting things done.

    Building a User Story Map

    A map is simply a collection of information with orientation.

    Start your story map by understanding who you’re going to impact. This is different from identifying the users because that mindset boxes you in and limits your thinking.

    Once you identify who you’re talking about, find out more about them in the context of your project. Work to understand what their goals are.

    Next, identify a starting point. If no one has any idea where to start, maybe you shouldn’t start. It might be a good idea to start with an area that’s ambiguous, where you have something to learn, or with something that’s really valuable to that person.

    Once you have your starting point, begin with an obvious example. This is basically a simple use case or scenario. Follow the obvious example with a complex one and then an example somewhere in between.

    Discussing a range of examples helps you to discover the range of issues that the person may face.

    At this point, walk a day in the life of this person. Get people to stop writing stories and promote storytelling.

    As you start to understand what the person does first and next using the obvious example, begin building out your story map left to right with cards on a wall or an electronic system.

    Add variations and details top to bottom in your map. Then identify other users and scenarios and add more detail top to bottom.

    Build your map as a grid and you’ll begin to see paths through the map. You’ve created a set of experiences that flow left to right and a decomposition top to bottom.

    You can now find paths to go through, choose one journey. Build a prototype or solution, and learn so we can adjust future development. We want to create opportunities for Minimum Viable Learning.

    Here’s a summary of David’s story mapping steps:

    1. Identify who you’re talking about
    2. Identify their goals
    3. Find an obvious example and begin mapping the experience left to right; include decomposition of items top to bottom
    4. Explore the map
      • Looking at more complex examples
      • Exploring what happens if someone else does it (another user)
      • Exploring what happens if something goes wrong
    5. As you find variations, continue to build your map out top to bottom
    6. Identify a customer journey through the map, build something, get feedback, and adapt future journeys

    Maps produce a visualization and create a segmentation to narrow your choices while retaining the big picture. This allows you to produce small pieces, get feedback, and apply what you’ve learned.

    Listen to the full episode to hear all of David’s tips and advice for effectively using story maps.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA081.mp3

    Z

    Your Homework

    When you decide to take on a user story or requirement, understand how you’ll measure the impact, not just how you’ll get it done. Stories need to include analytics. That helps you build less of the wrong thing by measuring the impact.

    Links mentioned in this episode:

    • DevJam website
    • Story Mapping tool Cardboard
    • Products Over Progress
    David Hussman

    David Hussman

    Founder, DevJam Studios

    As founder of DevJam Studios, David leads a team of producers, makers and coaches working in small and large companies around the world. His DevJammers focus on using agile methods to help people and companies improve their product learning through faster deliver cycles and responsive engineering.

    Along with coaching, David speaks and teaches at a wide variety of global conferences and companies. He has also contributed to several books “Managing Agile Projects” and “Agile in the Large”.

    • X
    • LinkedIn

    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.

    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.

    The post MBA081: User Story Mapping with David Hussman appeared first on Mastering Business Analysis.


    MBA080: Think Like a Freak Jul 12, 2016
    Show notes

    In this episode, Faye Thompson helps us to solve problems by thinking like freaks and takes us from scribe to trusted adviser.

    

    After listening to this episode, you'll understand:

    • Why good business analysts think like freaks
    • How to dig deeper when someone provides an answer
    • What to do when you’re handed a solution to implement
    • How to go from scribe to trusted adviser
    

    Show Notes

    Great business analysts think differently.

    They don’t take the first answer at face value. They dig deeper to find the root cause, break down a problem into small pieces, and find multiple potential solution options. They then guide the team to finding the best solution among the possible options.

    Thinking Framework

    I encourage you to think like a child; examine every problem in the simplest form. Don’t overlook possibilities because they seem obvious or too simple.

    Be relentlessly curious and wildly unbiased.

    Step back and allow yourself to brainstorm and consider all possibilities without constraints. Later, you can narrow down the solutions for feasibility and appropriateness.

    It’s common for us to ask a question and stop right there. We don’t dig deeper to get to the root cause. Using 5 whys or Ishikawa (fishbone) diagrams can help you find the root cause and come up with an action plan

    Often, there may be multiple root causes. A great BA will help develop options and help the team select actions that will have the greatest positive impact.

    What’s freaky about it?

    The freaky part of thinking is being dissatisfied with the first answer you get. We should be asking a lot of questions and digging deeper. Don’t stop at the first answer we come to. This allows you to find connections and causes others may have missed.

    Great BAs aren’t scribes or note takers. Scribes don’t think like freaks.

    Businesses are looking for change agents who can recognize opportunities for positive change, present solution opportunities, and guide the organization to selecting the right actions and help implement those solutions.

    Great BAs solve the right problem with the right solution among multiple possible options. We’re able to see work that may need to be done before other work and see things that shouldn’t be done at all.

    The Problem with Solutions

    Often we may be handed a solution to implement. When handed a solution, we need to dig deeper and ask questions about the problem the organization is trying to solve.

    We need to ask the tough questions to determine whether or not the solution is solving the right problem the right way. Digging deeper also allows us to use systems thinking to understand the impacts the solution may have on the rest of the system.

    When examining a solution, ignore boundaries and false constraints. These limit possibilities.

    Take a step back and make sure team is not adhering to false constraints, is focusing on the right problem, and everyone understands the business value of the solution

    The Challenge of Being a Freak

    It can be difficult to stand up and show the organization that they’re not doing the right thing or that the solution doesn’t solve the right problem. It’s challenging to slow things down to make sure your team is doing the right thing to achieve the business value.

    As Great (freaky) Business Analysts, we need to step up, think differently, and dig deeper to be the guardians of business value.

    Listen to the full episode to hear all of Faye’s advice on thinking differently and becoming a trusted adviser.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA080.mp3

    Your Homework

    Learn to say “I don’t know enough yet”. While we want to move projects forward quickly, get comfortable with the need to go back and investigate more to ensure you have a solid understanding of the problem you’re solving and the intended value.

    Adopt a servant leadership mindset and put the team’s and organization’s needs first.

    Links mentioned in this episode:

    • BA World Chicago (use promo code AB-DS and save money)
    Faye Thompson

    Faye Thompson

    Sr. Agile Consultant, CareWorks Tech

    Faye is a senior agile consultant with more than eighteen years of project delivery experience. Focusing on agile methodologies and continuous improvement, she has had a positive impact in the financial services, healthcare, advertising, and automotive industries. She enjoys serving on the board of directors for the Central Ohio Agile Association and is a frequent speaker at industry conferences.

    • X
    • LinkedIn

    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.

    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.

    The post MBA080: Think Like a Freak appeared first on Mastering Business Analysis.


    MBA079: Effective Collaboration Jul 05, 2016
    Show notes

    In this episode, Paula Bell shares her thoughts on effective collaboration; why it’s important and the eight factors for building a collaborative environment.

    

    After listening to this episode, you'll understand:

    • How collaboration differs from teamwork
    • Eight factors that help teams to collaborate
    • What you can do to collaborate better
    • How to measure the collaboration in your team
    

    Show Notes

    Collaboration is working together to realize shared goals. This is different than teamwork where individuals on the team can be focused on different goals.

    Many people use the word collaboration a lot, but aren’t effective at it. To be effective at collaboration, you need to understand the other people, know each other’s strengths, personalities, areas of opportunity, and capitalize on that knowledge for the good of the group.

    Collaboration isn’t a dictatorship. It requires interpersonal and relationship building as well as a clear understanding of the shared goal.

    Collaboration Under Pressure

    It can be challenging to effectively collaborate under the pressure of deadlines. It’s worth taking the time to get to know one another and do some team building. The investment in team building will pay off in better collaboration and productivity.

    Team building and developing relationships doesn’t have to take a lot on time or effort. Simply meeting for coffee once in a while can help you better understand each other and build bonds that will improve your working relationship.

    Relationship is iterative and incremental. You will likely need to continue to build relationships throughout the project.

    Barriers to Effective Collaboration

    You may be faced with some challenges when trying to collaborate with others.

    Perhaps some people in the group just don’t want to collaborate at all. Some may prefer just to be told what to do instead of working together on the solution.

    This is where relationship building and truly understanding each other helps. It will help you to understand the other person and why they interact the way they do.

    Another barrier may be that people don’t really understand what collaboration is or don’t have a clear understanding of the goal.

    Making sure the goal is understood and achieved is everyone’s responsibility.

    Eight Factors for Effective Collaboration

    An article in the Harvard Business Review highlighted eight factors that lead to successful collaboration.

    1. Investing in signature relationship practices: Encourage collaborative behavior through processes and environments such as open floor plans.
    2. Modeling collaborative behavior: Executives demonstrate the collaborative behaviors they’d like to see in their teams.
    3. Creating a “gift culture”: Mentoring and coaching become part of the organization’s DNA.
    4. Ensuring the requisite skills: Provide training and skillset development
    5. Supporting a strong sense of community: Create an environment and opportunities for people to come together as a community.
    6. Assigning team leaders that are both task and relationship oriented: Both a task and relationship focus are needed for team leads to build collaborative teams.
    7. Building on heritage relationships: Work with teams of people who already know each other is effective in creating a collaborative environment.
    8. Understanding role clarity and task ambiguity: Make sure there’s a clear understanding of what everyone’s role is.

    You can help create a collaborative culture by modeling collaborative behavior yourself. Helping the team by sharing knowledge and helping each other to get better at what they do is another great way to encourage positive collaboration.

    Effective collaboration leads to better customer satisfaction, employee satisfaction, delivery speed, and quality.

    Listen to the full episode to get more tips on effective collaboration and how to measure it.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA079.mp3

    Z

    Your Homework

    Start building relationships. Whether it’s a coffee break, lunch, or a walk around the building with someone, take time to learn about the people on your team. Building relationships creates a better understanding and increases collaboration.

    Links mentioned in this episode:

    • Paula’s Website: paulaabell.com
    • HBR article on building collaborative teams
    Paula Bell

    Paula Bell

    Paula Bell is a Business Analyst, consultant, mentor, author, and speaker known for providing guidance to aspiring business analysts. She’s held just about every role in a RACI matrix including business analyst, technical writer, project manager, developer, test lead, and product owner.

    • X

    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.

    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.

    The post MBA079: Effective Collaboration appeared first on Mastering Business Analysis.


    MBA078: Design Sprints Jun 28, 2016
    Show notes

    In this episode, C. Todd Lombardo shares his approach to Design Sprints, a one-week exercise to discover and test the right solution.

    

    After listening to this episode, you'll understand:

    • How design sprints can help your team discover the right solution
    • The five parts of a design sprint
    • What makes these sprints so powerful
    • How to get started
    

    Show Notes

    A Design Sprint is a mixture of the design process, the scientific method, and agile philosophy. It’s a process that walks you through problem solving using elements of these three approaches to gain clarity.

    The design process involves being empathic and having a human centered focus to solve problems. The scientific method is rigorous and experimental, allowing you to test a hypothesis. When combined with agile philosophy and its fast feedback loops, you can test a solution and understand the results over the course of five days.

    The Five Steps

    Typically, a design sprint takes five days with one day allocated to each of five phases.

    Day 1: Understand – Unpack and understand the problem, the context, and the user journey. By the end of this step, you will have a clear problem statement.

    Day 2: Diverge – This is the ideation/brainstorming phase which allows you to identify options for solving the problem. Go for quantity, not quality in this phase.

    Day 3: Selection – During this phase, you will review the solution options from the Diverge phase to rank and decide on a solution to test.

    Day 4: Prototype – During this phase, you will build out a solution in one day. This is your minimum viable concept; something that can be tested and not necessarily something you would put into production. The prototype can be high or low fidelity.

    Day 5: Test – During the Test phase, you get your prototype into the hands of people who would actually use a working solution to get their feedback. Your goal is to develop a better understanding of your customers and possible solutions to the problem.

    Note that you spend three days just focusing on the problem and potential solutions. Identifying the right problem and solutions to test your hypothesis is critical.

    When you build and test a solution, you might not get the answer you’re expecting. Think of the Design Sprint as a way to test a hypothesis and learn something from your customers without creating a lot of waste.

    When to use Design Sprints

    You can use a Design Sprint when you need to gain clarity about something or when there’s ambiguity. Design Sprints are great when there are questions that need answering.

    It allows you to find out if you’re right or wrong before spending too much time on what could be the wrong solution.

    So often, we’re handed a solution instead of a problem to solve. The Understand phase allows you to make sure you’re identifying assumptions and solving the right problem for the right customer.

    Listen to the full episode to find out how to use design sprints to discover the right solution.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA078.mp3

    Z

    Your Homework

    Use assumption storming. Write down all of the assumptions you’re making about a project. Stepping back and looking at all of your assumptions may allow you to jump to a better solution.

    Links mentioned in this episode:

    • C. Todd’s Website: http://ctodd.com/
    • Fresh Tilled Soil website
    • Design Sprint book on publisher site and on Amazon
    C. Todd Lombrdo

    C. Todd Lombrdo

    Chief Design Strategist at Fresh Tilled Soil

    C. Todd Lombardo is an author, designer, scientist, speaker, and a Design Strategist. He is a co-author of the book, Design Sprint. C. Todd focuses on building and mentoring teams in areas of user experience design, data visualization, and product strategy. He also serves on the adjunct faculty at Madrid’s IE Business School where he teaches courses in design, innovation, and data visualization.

    • X
    • LinkedIn

    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.

    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.

    The post MBA078: Design Sprints appeared first on Mastering Business Analysis.


    MBA077: Preparing for the Future of Business Analysis Jun 21, 2016
    Show notes

    In this episode, Kevin Brennan shares his views on what the future holds for business analysis and what you can do to prepare for that future.

    

    After listening to this episode, you'll understand:

    • The effect agile has had on the BA role
    • How Business Architecture fits with BA skills
    • What to do to prepare for future changes to the BA role
    

    Show Notes

    What does the future hold for the business analysis profession?

    There are a lot of changes taking place in the industry right now. A big shift is transition to agile. Some business analysts, project managers, and other project professionals may be concerned with the move towards an agile delivery model and wonder how they fit in this new world.

    A lot of those concerns are based on the belief that the tasks you’re doing today are who you are and what you do instead of thinking about whether this type of skill is needed and valuable whether you’re using waterfall of agile.

    There is still a place for business analysis in agile. Perhaps what you’re analyzing may be somewhat different. Analyzing how business processes work and how the organization generates value will be critical to your ability to be successful.

    Part of your role might be focusing on what the business is doing and working with the development team to figure out how the systems support and respond to what the business does.

    There could also be a division in the role between people who are pure systems analysts who are experts on the commercial systems and those who are business analysts focusing more on the business side with process improvements and helping the business adapt to changes.

    The Impact of Business Architecture

    With the increasing complexity of today’s business environment, there is an increasing need for a business focused architecture. People performing business architecture activities look at how the business operates and figures out how all of the pieces work together to achieve a positive result.

    They’ll look at business processes and organizational capabilities and work to understand how to realize benefits and cost savings by seeing the enterprise as a whole.

    We’ll likely see some business analysts moving up the enterprise chain and getting into the business architecture space.

    The Shift from Project to Product

    There is a shift in the industry to move from a project focus to a product focus. This means that we need to see the bigger picture and expand beyond being an in-project resource.

    We will need to be able to develop roadmaps and take a longer term view. We’ll also need to integrate ideas and needs from different sides of the business. The project will become more of a delivery vehicle.

    With this shift, we see more people transitioning to product owner or product manager role. Product roles fundamentally do business analysis work and map closely to what BAs do (with a few exceptions).

    Listen to the full episode to hear all of Kevin’s advice on what you can do to prepare for future changes in business analysis.

    http://traffic.libsyn.com/masteringbusinessanalysis/MBA077.mp3

    Z

    Your Homework

    Make sure you have some kind of benefits realization map or objectives that you periodically tie back to. This allows you to see if what you’re doing links back to the original goal to make sure you’re doing the right things.

    Links mentioned in this episode:

    • Change Fail Podcast: Change.Fail
    Kevin Brennan, CBAP

    Kevin Brennan, CBAP

    Kevin Brennan is an association executive and business transformation architect, and works as an independent consultant based in Toronto, Canada. He has been a leader in the business analysis community for over a decade, as a member of IIBA’s board and executive team and shepherding the BABOK Guide through three major releases. Kevin has led organizations through strategic and business unit planning and execution, played a leadership role in enterprise change, developed and launched multiple products for a global audience, and managed a product portfolio through the entire product lifecycle.

    • X
    • LinkedIn

    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.

    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.

    The post MBA077: Preparing for the Future of Business Analysis appeared first on Mastering Business Analysis.


    Previous 1 18 19 20 21 22 28 Next

    Related Podcasts

    Making Sense with Sam Harris

    1

    Making Sense with Sam Harris Education
    Grammar Girl

    2

    Grammar Girl Education
    Good Life Project

    3

    Good Life Project Education
    Explain It to Me

    4

    Explain It to Me Education
    Team Never Quit

    5

    Team Never Quit Comedy
    Optimal Living Daily – Personal Development and Self-Improvement

    6

    Optimal Living Daily – Personal Development and Self-Improvement Alternative Health
    footer-logo

    Contact Us

    Toll Free: 844-670-7747

    Links

    • Home
    • Top Charts
    • Networks
    • Apps
    • Independents Podcasts
    • Podcast Advertising
    • Podcast News
    • Contact Us
    • About Us
    • Analytics & Insights

    Stay Connected

      Privacy, Terms of Use & Our Code of Ethics Protecting Content Creators Copyrights