Podcasts about validated learning

TUNE IN TO LEARN:    Can the principles that drive startup success also fuel your personal health journey?     Join me, Angela Sharina, as we unravel this fascinating question in the latest episode of Your Brain's Coach podcast.    Discover how the Lean Startup methodology, known for revolutionizing business strategies, can be seamlessly integrated into optimizing your nutrition and overall well-being.     We break down the complexities of meal planning and business initiatives, one simple change at a time, to achieve sustainable growth and better outcomes. I'll share insights from my own nutrition coaching and startup-building journey.    I explain why focusing on one variable at a time, just like running a controlled experiment, helps avoid wasteful learning and "strike of luck" kind of success, making the growth journey a more predictable pattern.    Tune in for a blend of entrepreneurial wisdom and nutritional coaching that promises to elevate both your business and personal health journeys.  Text Me Your Thoughts and IdeasSupport the Show. Brought to you by Angela Shurina EXECUTIVE HEALTH AND OPTIMAL PERFORMANCE COACH Change in days - not in years!

Esther Gons is the CEO and co-founder of GroundControl, a software platform that specializes in measuring and de-risking innovation. GroundControl has worked with companies like Colgate/Palmolive, Euler Hermes, DHL, Enexis, and ABN Amro. Esther's expertise extends beyond her role at GroundControl. She is also the co-author of the award-winning book, Innovation Accounting, which offers practical guidance on measuring a company's innovation ecosystem. She co-authored another influential book, The Corporate Startup: How Established Companies Can Develop Successful Innovation Ecosystems. Her expertise and thought leadership has made her an in-demand international speaker, sharing insights on various topics including corporate innovation, innovation accounting, entrepreneurship, startups, lean methodology, business models, and customer development. Esther has mentored hundreds of startups and has served as a lead mentor in prestigious programs such as the Rockstart Accelerator programs, Lean Startup Machine, and Evolv weekends.   Today, Esther and I discuss innovation and her work as an entrepreneur, international speaker, author, and founder of Ground Control. She shares her experience writing her two books, The Corporate Startup and Innovation Accounting. We discuss the maturing of corporate innovation and why it must now be taken seriously. Esther underscores how innovation is a learning process and how it is necessary to make mistakes to understand what works. We talk about why innovation should be treated as a discipline and why the input of specialists who have the necessary skills is crucial. Esther also emphasizes the importance of understanding innovation to succeed and shares some great insights as to why innovation labs are often stopped after only a few years.   “Corporate innovation is maturing. We can no longer play around with innovation. The trend is that people are saying, ‘No, we have to take this thing seriously.'” - Esther Gons   This week on Innovation Talks:   ●     An overview of ISO Standard Certification ●     Why companies are taking sustainability seriously in innovation ●     The benefits of innovation in business ●     The purpose and struggles of innovation labs ●     Challenges in innovation ●     The future of innovation maturity in corporations ●     The responsibility innovation labs hold ●     How open innovation affects corporate ecosystems ●     Esther's experience designing an online course   Resources Mentioned:   ●     Course on Validated Learning (https://togroundcontrol.com/lean-innovation-training-course/) ●     Innov8tors Conference (https://innov8rs.co/lisbon/) ●     Book: Open Innovation Works (https://openinnovation.works/)   Connect with Esther Gons:   ●     Esther Gons on LinkedIn (https://www.linkedin.com/in/esthergons/) ●     Book: Open Innovation Works (https://openinnovation.works/) ​ by Dr. Diana Joseph, Dan Toma, and Esther Gons ●     Book: Innovation Accounting: A Practical Guide for Measuring Your Innovation Ecosystem's Performance (https://innovationaccountingbook.com/)   This Podcast is brought to you by Sopheon   Thanks for tuning into this week's episode of Innovation Talks. If you enjoyed this episode, please subscribe and leave a review wherever you get your podcasts.   Apple Podcasts (https://podcasts.apple.com/us/podcast/innovation-talks/id1555857396) | TuneIn (https://tunein.com/podcasts/Technology-Podcasts/Innovation-Talks-p1412337/) | GooglePlay (https://www.google.com/podcasts?feed=aHR0cHM6Ly9pbm5vdmF0aW9udGFsa3MubGlic3luLmNvbS9yc3M%3D) | Stitcher (https://www.stitcher.com/s?fid=614195) | Spotify (https://open.spotify.com/show/1dX5b8tWI29YbgeMwZF5Uh) | iHeart (https://www.iheart.com/podcast/263-innovation-talks-82985745/)   Be sure to connect with us on Facebook (https://www.facebook.com/SopheonCorp/) , Twitter (https://twitter.com/sopheon) , and LinkedIn (https://www.linkedin.com/company/sopheon/) , and share your favorite episodes on social media to help us reach more listeners, like you.   For additional information around new product development or corporate innovation, sign up for Sopheon's newsletter where we share news and industry best practices monthly! The fastest way to do this is to go to sopheon.com (https://www.sopheon.com/) and click here (https://info.sopheon.com/subscribe) .

Esther Gons is the CEO and co-founder of GroundControl, a software platform that specializes in measuring and de-risking innovation. GroundControl has worked with companies like Colgate/Palmolive, Euler Hermes, DHL, Enexis, and ABN Amro. Esther's expertise extends beyond her role at GroundControl. She is also the co-author of the award-winning book, Innovation Accounting, which offers practical guidance on measuring a company's innovation ecosystem. She co-authored another influential book, The Corporate Startup: How Established Companies Can Develop Successful Innovation Ecosystems. Her expertise and thought leadership has made her an in-demand international speaker, sharing insights on various topics including corporate innovation, innovation accounting, entrepreneurship, startups, lean methodology, business models, and customer development. Esther has mentored hundreds of startups and has served as a lead mentor in prestigious programs such as the Rockstart Accelerator programs, Lean Startup Machine, and Evolv weekends. Today, Esther and I discuss innovation and her work as an entrepreneur, international speaker, author, and founder of Ground Control. She shares her experience writing her two books, The Corporate Startup and Innovation Accounting. We discuss the maturing of corporate innovation and why it must now be taken seriously. Esther underscores how innovation is a learning process and how it is necessary to make mistakes to understand what works. We talk about why innovation should be treated as a discipline and why the input of specialists who have the necessary skills is crucial. Esther also emphasizes the importance of understanding innovation to succeed and shares some great insights as to why innovation labs are often stopped after only a few years. “Corporate innovation is maturing. We can no longer play around with innovation. The trend is that people are saying, ‘No, we have to take this thing seriously.'” - Esther Gons This week on Innovation Talks: ●     An overview of ISO Standard Certification●     Why companies are taking sustainability seriously in innovation●     The benefits of innovation in business●     The purpose and struggles of innovation labs●     Challenges in innovation●     The future of innovation maturity in corporations●     The responsibility innovation labs hold●     How open innovation affects corporate ecosystems●     Esther's experience designing an online course Resources Mentioned: ●     Course on Validated Learning●     Innov8tors Conference●     Book: Open Innovation Works Connect with Esther Gons: ●     Esther Gons on LinkedIn●     Book: Open Innovation Works​ by Dr. Diana Joseph, Dan Toma, and Esther Gons●     Book: Innovation Accounting: A Practical Guide for Measuring Your Innovation Ecosystem's Performance This Podcast is brought to you by Sopheon Thanks for tuning into this week's episode of Innovation Talks. If you enjoyed this episode, please subscribe and leave a review wherever you get your podcasts. Apple Podcasts | TuneIn | GooglePlay | Stitcher | Spotify | iHeart Be sure to connect with us on Facebook, Twitter, and LinkedIn, and share your favorite episodes on social media to help us reach more listeners, like you. For additional information around new product development or corporate innovation, sign up for Sopheon's newsletter where we share news and industry best practices monthly! The fastest way to do this is to go to sopheon.com and click here.

hum Dekhenge ki hum Kam INVESTMENT ke business kaise start kar sakte hai:- Iske liye meine "VALIDATED LEARNING" ka example diya hai. ko ki LEAN STARTUP book me bhi mention hai. Agar aap apni market ko pehle test kar le aur apne product ke thode pieces ko sell karna start kare to aap fail hone ke chances bhut kam ho jaate hai. --- Send in a voice message: https://anchor.fm/greatideasgreatlife/message

“Your life can change in 10 seconds, and you have to decide what to do with that…” This is one episode that will leave you speechless and inspired. Venus Morris Griffin is an award-winning real estate agent, motivational speaker, and a mom to 7. Little did she know that her world would fall apart with a single phone call. Venus would have to quickly adapt to becoming the sole provider for her family while overcoming adversities haunting her from childhood and carrying into her fallen marriage. Through it all, she learns life lessons and is determined to help others by sharing her story. Be sure to check out her upcoming 2021 book Validated: Learning to Matter Through Breaking the Cycle of Abuse, where she reflects on her struggles and journey to where she is today in detail.  In this episode we discussed:  Resolve, Determination, Compassion, and Consistency Where she drew her strength from Not making someone else’s disease your own How to break the patterns The secret to success = keep it simple Choice is everything   Links:  https://www.venusmorrisgriffin.com/ @venusmorrisgriffin   Stay in Touch:  Website Instagram: @deepchatspodcast Watch our interviews recorded live on YouTube   About Leah & Jenn Leah Morris is a Life & Relationship Transition Coach, founder of Life Remade, published writer, and motivational speaker... She helps people to authentically process their feelings, thoughts, and emotions in order to give them a deeper understanding of themselves and others. Using a range of modalities including art, coaching,  guided visualization, and even her own story and experience of marriage, divorce, and finding herself again - Leah specializes in helping you gain a solid sense of Self Worth, develop unshakable Confidence, and heal after emotional Heartbreak. The biggest lesson she's learned in life thus far is that "there is no greater place to begin putting your life together than when it's been broken apart. Connect with Leah at www.LifeRemade.com or on Instagram @leahemorris   Jennifer Butler is a Love and Transformation Coach who is dedicated to helping women fall deeply in love with themselves and awaken to their own internal power to create joy, love, and freedom in their lives. Working with women in three areas: Conscious Uncoupling, Calling in “The One,” & Self-Discovery, Jennifer teaches clients to identify and transform internal obstacles and expand their capacity to love and be loved. Jennifer received her Masters in Clinical Social Work from New York University in 2002. After working as a trauma social worker in the hospital system, she took time off to become a mom and write a book. Jennifer authored Excerpts from the Heart of a Mom, inviting readers into her personal life and parenting journey, and sharing fundamental insights to a conscious approach to parenting. She also began “Live Through the Heart,” a blog that inspires readers to live more consciously in their daily lives. Connect with Jennifer at www.jennjoycoaching.com or on Instagram @jennjoybutler_lifecoach   Subscribe + Review Never miss an episode! Subscribe to the podcast!

Jain explains why and how to iteratively and incrementally build products that focus on customer value over viability.PEOPLEGuest: Piyush Jain, CEO & Founder, Simpalm and Cofounder, Ducknowl (Duck’n’Owl)Host: Anil Hemrajani, Founder of Startup SidekickTAKEAWAYSValue: Look at the “value” for your customer, not the “viability” of the MVP. For example, Instagram started with photo sharing to an entire platform.Design: Is crucial these days; if you have great features but not a functional and user friendly design, your product might not be successful.Learning: You need to constantly be learning and adapting, from the point you start with your MVP to building out the product; iterative and incremental building based on customer feedback, during the MVP and post-launch phases. Don’t be disheartened with setbacks — that’s what MVPs are intended for.TIMELINE01:38 – Overview of Simpalm and Ducknowl. Simpalm started in 2009 from Jain’s basement; now a full-stack software development. Ducknowl, a SaaS product, built in-house, launched in 2019, started with the same cofounder as Simpalm. Very hectic to screen candidates for hiring, no digitized platform. We’re getting interest from small and large companies.03:27 – What is an MVP? MVP should be Minimal “Value” (versus Viable) Product. Viability is something we (startups/founders) look for us (e.g. budget, timeline) but what gives value to the customer? For example, consider this: Zoom, Skype and others are all viable web meeting software but which gives you value? Try to deliver one or two minimal features that deliver value for customers. 05:55 – How big should an MVP be? It’s different for different companies, based on their size and stage but even for bigger projects, it shouldn’t be any more than six months. Get the product out there quickly to get customer feedback.07:30 – How do you know you have an MVP? It’s when your users are able to interact with your product and see some value by using it (e.g. downloading an app, logging into a website). Then, you 08:45 – What did the MVP look like for DuckNOwl? We had a basic feature in mind for our MVP; i.e. resume sorting and parsing. Resume screening, sorting and reading, since it’s a big issue for hiring managers. We went to recruiters and they loved it. We also only knew they needed things like video screening for assessing applicants. We wanted a lot but started smaller. 09:59 – Did you talk to customers or your own problems that made you launch Ducknowl? It started with our own problems (e.g. software developers, project managers) and it was taking time. We decided to build a product that digitizes the whole process. We’ve also done staff augmentation for clients, so we spoke with their recruiters and they liked it. So, we had our own company and customers (user base) to get initial interest and to test with.12:12 – How do you incorporate Lean Startup and Design Thinking best practices into MVP mindset? MVP is a core aspect of Lean Startup and Design Thinking is the first step. In the past, it was about code; nowadays, it’s more about design…something people will use. This is what we convey to our clients these days by educating them about the importance of design, using Design Thinking. You need wireframes and/or clickable designs. Create a focus group (e.g. customers) that can give you feedback.15:25 – What tools do you use? There are several tools but the three main tools we use for designing and design testing: InVision, Sketch and Figma.15:53 – How do you get stakeholders involved in MVP mindset? We ha

The Six Disciplines of Agile Marketing: Proven Practices for More Effective Marketing and Better Business Results by Jim Ewel Transform your organization using Agile principles with a proven framework.  The Six Disciplines of Agile Marketing provides a proven framework for applying Agile principles and processes to marketing. Written by celebrated consultant Jim Ewel, this book provides a concise, approachable, and adaptable strategy for the implementation of Agile in virtually any marketing organization.  The Six Disciplines of Agile Marketing discusses six key areas of practical concern to the marketer who hopes to adopt Agile practices in their organization. They include:  Aligning the team on common goals  Structuring the team for greater efficiency  Implementing processes like Scrum and Kanban in marketing  Validated Learning  Adapting to Change  Creating Remarkable Customer Experiences  The Six Disciplines of Agile Marketing also discusses four shifts in beliefs and behaviors necessary to achieve an Agile transformation in marketing organizations. They include:  A shift from a focus on outputs to one based on outcomes  A shift from a campaign mentality to one based on continuous improvement  A shift from an internal focus to a customer focus  A shift from top-down to decentralized decision-making Click here for this episode's website page with the links mentioned during the interview... https://www.salesartillery.com/marketing-book-podcast/six-disciplines-agile-marketing-jim-ewel

Caporale provides sage advice on how tech startups should acquire their first few customers using a focused approach.PEOPLEGuest: Franco Caporale, Founder & CEO, SaaSMQL (and Founder, DemandGen Cloud).Host: Anil Hemrajani, Founder of Startup SidekickTAKEAWAYSFocus on niche first; e.g. I want to help a certain group of people.Find the first customer — this will be the hardest part. Sell to them; do whatever it takes (e.g. free or heavy discount in exchange for a case study). Then, find the second one, another case study…repeat and scale. Map your lead flow, marketing and sales flow. Have a sales process on how to close leads.Find one or two good channels to match your business and then scale. You’ll have to invest in customer acquisition. Set a budget and goals. In the beginning, it might be bad till you can optimize.Be creative on the channel; don’t go where everyone else is going. You can also end up spending more money due to the competition.TIMELINE01:12 – Overview of SaaSMQL: We help SaaS companies scale their pipeline/demand generation, including account based integrated marketing.02:25 – What is your typical client? Startups looking to scale, typically series A-E companies, from 10 to 300, employees. Focus budget of marketing on targeted accounts using workflows and campaigns.03:25 – How early/late stage are your customers typically in? We work from later stage startups (e.g. ones with many customers but looking to scale) to very early stage startups (e.g. 5-8 customers, look for patterns in these, define unique value proposition). Very early stage startups tend to broadcast a very broad message (i.e. no product-market fit yet).05:12 – Can you share any stories or lessons learned about getting first customers? Try to sell to the first customer before even starting your startup, otherwise you’ll spend a lot of time and money or have to pivot multiple times, later. Founders start with the idea/technology and then try to figure out who to sell it to, instead of starting with the audience. Figure out what’s a must have versus nice to have. Interview a lot of customers.09:15 – Do you follow any methodology or process to discover what a startup needs? We are very targeted since we work with startups that already have a product-market fit and are trying to scale. Customer acquisition costs money, so we help them create a funnel that works (e.g. spend $1 to make $3) and a system.11:20 – What are some of the challenges you run into? The hardest is the first customer, through referral, discount, etc. Great case study from the first few customers. Then, start selling your case studies; they have to be good and exciting. Then, begin marketing your case studies. Keep adding more case studies. 13:00 – Repeatable Patterns – Come up with a hypothesis of the niche, find the solution and then work on how you’ll deliver the solution (it’ll change over time). Deliver on one or two things very well. Find one (maybe two) channel that works very well for you. Market your case studies. Start engaging them and create a funnel (e.g. lead, accounts), convert them and create a mapping system (e.g. database of prospects, marketing to sales workflow, sales process) — map the systems very early.14:45 – What techniques/channels do you use for you clients (e.g. inbound marketing, direct marketing)? We do enterprise marketing…account based marketing, start with target accounts to see how we can engage them, instead of starting with inbound marketing and converting them to leads. This works for high ticket products. We use LinkedIn

Sam Aparicio, a CEO and tech executive, discusses lessons learned from five years of trying to find the ideal product market fit in his now successful startup, Ring.io.PEOPLEGuest: Sam Aparicio, CEO of Ring.io a Power Dialer for Salesforce, Hubspot, Zoho, Pipedrive and DynamicsHost: Anil Hemrajani, Founder of Startup SidekickTAKEAWAYSStart a company in an industry where you have subject matter (business domain) expertiseYou will make mistakes; don’t try to perfect — iterate, improve, fail/succeed fast.Work closely with customers to test concepts, get feedback and find product market fit.TIMELINE01:20 Sam: Background (born, school)02:15 Sam: How he co-founded Ring.io and what’s unique about it05:25 Sam: What market need is (problem, solution, buyer)06:24 Sam: How startups find their market need 08:31 Sam: How Ring.io found their market need10:34 Sam: It took five years to find their product market fit11:26 Anil: Pivot in his former startup11:51 Sam: Advice/takeaways on defining market need

Anirban Chakrabarti, a tech serial entrepreneur, discusses five key dimensions to a successful product strategy.PEOPLEGuest: Anirban Chakrabarti, Serial EntrepreneurHost: Anil Hemrajani, Founder of Startup SidekickTAKEAWAYSFive key dimensions to a successful product strategy:Customer: Deliver value customer is willing to pay forCompetition: Understand what products your competition is building and serving marketTechnology: Entrepreneurs should look at disruptive technologies to provide unique solutionsChannels: Align your product to your distribution model (e.g. B2C/ecommerce, B2B/sales)Exit: Define potential acquirers and why they might be interested in you (ROI)TIMELINE00:22 Anil: Anirban’s bio00:58 Anirban: Background (born, school)02:18 Anirban: Overview of former startup, Nanoscale 05:50 Anirban: Definition of product strategy (customer, competition, tech, channel, exit)10:46 Anil: Discusses his former startup 11:16 Anirban: Giving structure to lower level decisions (e.g. tech)12:16 Anil: Similar experience with his former startup12:38 Anirban: Two stories of painful lessons learned about product misalignment to user experience15:30 Anil: Similar lessons learned with tech mistakes

Validated Learning was coined by a genius entrepreneur, Eric Ries. The definition that Eric gives is somewhat like “validated learning, is the unit of progress in a lean startup”. A lean startup, if you don't know, advocates that entrepreneurs should develop products that users want and that the market will exist as soon as the product is released. The difference between a lean startup and a traditional business is that a traditional business would wait for the product development to be completed and then look for customers. Another major difference is that a lean startup is experimental in its philosophy. Okay, coming back to validated learning. Validated learning is how we measure our progress. How do we know how much have we learned from our experiences? These days I say that I have learned a lot from my failed ventures. These days I say a lot that I am learning from failures. But how much of that is true? Cover Art by Yugantar Malhotra --- Send in a voice message: https://podcasters.spotify.com/pod/show/lfwithkunwar/message

In this episode, we discuss Eric Ries book The Lean Startup. There are many principles in this book that apply to technology professionals and that we should know. From MVP(Minimum Viable Product) to Validated Learning these are ideas we should have an understanding of. https://amzn.to/2PaStfu --- Support this podcast: https://anchor.fm/tom-henricksen/support

As entrepreneurs and fierce feminine leaders, making mistakes and facing failures can sometimes be excruciatingly painful. But in order to continue to learn, grow, and achieve the success we truly deserve, facing your fears and learning from your mistakes is critical for continuing to grow. Keep Reading >> If you’re not experimenting, making mistakes, and experiencing failure, then you’re not thinking big enough to break through the glass ceiling to achieve your next level of success.   On today’s episode, I share how making mistakes and experiencing failure encourages a growth mindset. I share why many fierce feminine leaders are afraid of experimenting, making mistakes, and experiencing failure and how this fear prevents them from achieving their success goals. I also explain why it’s critical to measure your success as a fierce business owner based on the validated learnings you have acquired and how it helps you make better decisions to move your business forward.     “When you acquire validated learnings - that is really the key to the kingdom.” - Eleanor Beaton       Today on the Fierce Feminine Leadership Podcast:   How avoiding mistakes and failures impacts your ability to learn and grow. Why mistakes and failures are critical for thinking bigger. The importance of taking risks and experimenting. The impact that internalized perfection can have on your growth as a female entrepreneur. What is validated learning? How measuring validated learning metrics impacts your ability to make smarter business decisions. The relationship between acquiring validated learnings and thinking in math, not in drama.     Fierce Leadership Quotes:   “If you are growing, and you are not making mistakes and experiencing the sharp pain of failure from time to time - you are in trouble.” - Eleanor Beaton “Learning is painful. It really can hurt sometimes - experimenting can hurt sometimes. Failure hurts - but it is so critical.” - Eleanor Beaton “The amount of validated learning you acquire needs to be one of your core metrics of success moving forward if you want to create long-term, sustainable success.” - Eleanor Beaton     Fierce Resources:   The Lean Startup by Eric Ries           Join the Exclusive Incubator Program!   Are you ready to build, leverage, and scale your business to the next level? Ready to maximize your leadership skills and grow your business to 7-figures and beyond? Join our Incubator Program - the 12-month high-octane program that blends leadership strategy, accountability, and business building support to help you propel your business to the next level and increase your earning power. Head over to EleanorBeaton.com to learn more about The Incubator Program and submit your application today!     Dial Up Your Impact, Influence, and Income in 2019    Are you ready to take your leadership and influence to the next level in 2019? Join the Impact & Influence Leadership Lab for Women with Eleanor Beaton – the world’s premier leadership training and implementation program designed specifically for female leaders! This is an 8-week mentoring program for professional, ambitious women in business who are ready to take their leadership skills to the next level and truly step into their power. Visit the Leadership Lab for Women website to see all of the amazing content, tools, and services you will receive by registering today to claim your seat at the table!     Love the show? Let us know! Are you a fan of the Fierce Feminine Leadership Podcast? If the tips and interviews we share in each episode have helped you gain the confidence and inspiration to become a better, more powerful leader, head on over to iTunes, subscribe to the show and leave your honest review to let us know! Each month, one lucky podcast reviewer will be selected to receive a free coaching session with me – Eleanor Beaton! What are you waiting for? Head on over to iTunes, subscribe and leave a review to enter your name into this month’s drawing!    And, if you really want to ramp up your fierceness… Reach out to us for a free 30-minute Bold Women in Business Makeover Session with me or one of the fabulous coaches on my team! Explore your path and discover how you can be the fiercest lady-boss possible. Visit EleanorBeaton.com/discover.    

In this Focus topic, Sjoerd meets with Product Owner Edwin Wopereis to discuss the Validated learning board. Edwin is responsible for the Kramp Webshop. Kramp is a technical wholesalerand one-stop supplier of spare parts, technical services and business solutions to more than 40.000 dealers worldwide. Edwin works with multiple developments teams – located in the Netherlands & India – […]

In this episode we meet with Product Owner Edwin Wopereis. Edwin is responsible for the Kramp Webshop. Kramp is a technical wholesaler and one-stop supplier of spare parts, technical services and business solutions to more than 40.000 dealers worldwide of agricultural machines, forest & grasscare machines, construction machines and in the OEM and MRO industry. Edwin […]

In this episode Squirrel and Jeffrey discuss the Second Agile Principle: ‘Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.’ We hear how the principle is closely related to Lean Startup and Minimal Viable Product, and how, at its core, it is about understanding and learning from one’s environment as quickly and as often as possible. This reminds Squirrel of the OODA loop, the decision cycle developed by military strategist and US Air Force Colonel John Boyd, and he tells us a story about fighter jet dogfights in the Korean War. Jeffrey also tells us a story, about a startup he started way way back in the first dotcom bubble in 1999, which brings to mind another military lesson that ‘no plan survives contact with the enemy.’. Finally, we hear examples of common errors witnessed over the years, such as refusals to fully embrace the Second Agile Principle in favour of misguided efficiency and an often irrational attachment a plan. *** SHOWNOTES: -The 12 Agile Principles: http://agilemanifesto.org/principles.html -The OODA Loop: https://en.wikipedia.org/wiki/OODA_loop -Lean Startup: https://en.wikipedia.org/wiki/Lean_startup *** We’d love to hear any thoughts, ideas or feedback you have regarding the episode (or regarding anything else, for that matter). You can email us, here: agile@troubleshootingagile.com Or send us a tweet, here: twitter.com/TShootingAgile Or you can find our website, here: http://troubleshootingagile.com/ Also, here is a link to our iTunes: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2 If you felt like liking, Sharing and/or Subscribing, we’d really appreciate it.

This episode features Cate Tolnai, academic technology specialist for Santa Clara County Office of Education in California. Take a listen as she describes how micro-credentials are helping improve her district’s culture of validated learning and educator recognition.

You want to be measuring always measuring. Patrick and Stephen take this episode to analyze the importance of analytics.

In this episode, you'll learn: How to use Six sigma to optimize your processes.How to use Validated Learning to develop what the customer truly wants.What Innovation Accounting is and why every start-up should use it.How to develop a minimum viable product, and push it out as soon as possible.Why you should always ask “Why” 5 times when your company faces a problem.Click here to get full access to our show notes.

Please checkout out this exciting interview with author of Essential Scrum, Ken Rubin. Ken is a distinguished author, speaker, and Agile instructor. He has worked with many of the nation's top companies, and he joins us in this episode to tackle some of the tough questions facing teams as they adopt Agile.If you haven't already read Ken's great book, please pick up a copy of Essential Scrum on Amazon today!  You can also read Ken's blog and learn more about his services through his website innolution.com.I hope you enjoy this episode and please remember to subscribe in iTunes. Do you have a question that you would like answered in an upcoming podcast? Please send your question to: coach@agileinstructor.com.All Things Agile - Episode 011 - Ken Rubin InterviewTranscript:Welcome to the All Things Agile Podcast – your destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast in iTunes, and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.Ronnie: Hello everyone and welcome to All Things Agile. I’m very excited to announce that Ken Rubin is our guest today on the show. Ken is a noted author of Essential Scrum as well as being a public speaker and Agile instructor. Before we begin, a quick reminder that this podcast is for informational purposes only and we accept no legal liability. So let’s get started! First off, Ken, thank you so much for joining us on this episode.  I am really glad to have you on this show. I’ve given the audience just a quick introduction, but can you please take a few minutes and explain a little bit more about yourself, both personally and professionally? We really want to get a chance to know you.Ken: Sure! So my background is software engineering. My degrees are all in computer science and I’ve had a typical path through most software companies. I’ve been a developer, project manager, VP of Engineering at a number of companies both large and small. I’ve done 10 startup companies in my career, and I’ve taken two of those public on the NASDAQ. I did my 2 year stint with IBM in the mid-1990s. I’ve helped companies and I worked with 130 people; we ran around North America building large distributed object systems and if anybody’s old enough to remember, I came out of the Small Talk world. Back in the late-1980s, I helped bring Small Talk out of the research labs at Xerox PARC, and I worked with a startup company that was a spin-off of Xerox PARC called Barclay System. We were the early market object technology folks.  So we brought Small Talk and object technology to the market.I’ve been doing Agile since the early-1990s. Scrum, formally, since 2000. In those days, I worked for a startup company in Colorado called Genomica. It was a 90 person engineering team, and they let the VP of engineering go. I ended up inheriting the engineering team which wasn’t functioning all that well and we transitioned everybody over to Scrum. And that ended up working out much better for us. And I’ve been using Scrum ever since, about 14 years. These days, I spend my time out either doing Scrum training classes and Kanban training classes or doing coaching. And, I hope that in our discussion today I can go over a number of examples that I had the benefit of seeing a lot of different companies and what’s working and what isn’t working.Ronnie: Thank you for the introduction Ken. I’m really looking forward to the insights you can provide us based on your considerable experience. The first question I’d liked to ask you, regarding your book Essential Scrum, is in regards to the dedication and introduction. It really got me thinking about the importance of relationships and software. I also started thinking about how relationships or soft-skills play into the success of Scrum. What is your insight or your advice on how relationships affect Agile teams?Ken: It’s a good question to start with. To me, the unit of capacity in Agile is the team. Even the Agile Manifesto calls that out – individuals and interactions over processes and tools. It really is about the team. So how they interact with each other, how they perform is of outmost importance. The relationships among the members of the teams is critical. If you’re going to have self-organizing teams, they have to have trust in one another. That’s one of the characteristics that, for me, distinguishes a group from a team. Group, simply being a bunch of people that I threw together with a common label. And honestly, the only thing they have in common are the T-shirts they printed out that have the name of the group on it.A team is a group that’s gone through the stages. Sort of the top most stages: forming, storming, norming and performing. And if you can make a real investment to turn a group into a team, first, they had to figure out these soft skills issues: how to work well together? Otherwise, they would never become a high performing team, and they would constantly be at odds with one another. So one of management’s responsibility is to help put the right people on the team, but once they’re there, it’s the soft skills that help bring these members together, that help them work well and function well. In most Scrum classes, there’s an exercise: the Yes – And, vs the Yes – But exercise. And the intent behind that – it’s actually an exercise that borrowed from improvisational comedy training and the idea is to try and help teams understand how to work well together, how to form those relationships, how to take one person’s idea, build on top of it and not be in a Yes – But style passive-aggressive cutting things down: ‘Yeah, I heard what you said; it seems like a good idea but let me now tell you why it sucks.’ That’s not a foundation for building a high performance team. If the soft skills are not addressed, then likely you won’t have a style of organizing teams which are the unit of capacity in doing Agile and for that reason, you’ll likely fail.Ronnie: I definitely agree. What came to my mind is the book ‘Speed of Trust’ by Stephen Covey. It describes how trust is a major factor and how people fill in the gaps in communication and that with a high trust environment, the team is able to move more quickly.Ken: I think it’s really important. How we disagree is as important as how we do agree. At no point would I ever suggest that team members shouldn’t disagree, or shouldn’t have a vigorous debate. They should do it though in a very proactive way; in a way that’s reinforcing their ability to come up with an innovative solution, not inhibiting that ability. So if they don’t have the skills to work with each other and challenge each other, then very likely that the best achieved is mediocrity.Ronnie: Excellent point! And I think that leads into our next question: There is a quote in your book that I love, which is that one of the benefits of Scrum is that it really exposes existing issues. I couldn’t agree more. It’s been my experience that Scrum really sheds light on underlying problems or processes that are actually bottlenecks. One of the challenges that I’ve seen is that sometimes the personalities and procedures that were in place before adopting Agile may be discovered to be part of the concerns. Some of the potential personalities involved may even be in leadership roles. So one question I would like to ask you is, how does an organization work on improving their adoption of Agile when much of the legacy culture, leadership style and procedures are still in place?Ken: This is actually a critical question and how people respond in this situation, to me is one of the tell-tell signs as to whether they’ll be successful – let me give you a specific example. Some years ago, I was giving a management presentation during lunchtime in front of my boss. So we budgeted 90 minutes, brought in food, the management team. So senior management and director level people and some VPs are in the room and I made the following comment; I said – by the end of your Sprint, you should get the work done and you should have zero known defects on what you just built. And I also mentioned that people that have historically been members of the testing team should be fully integrated in with developers in a single team. They should work together collaboratively with zero defects to get things done.Immediately this lady in the back of the room raised her hand. She said ‘This won’t work here’. I said ‘Why not? What part of that?’ She said ‘I manage the QA team’. She goes ‘You just told me that I should assign my people on to the Scrum team.’ Yes, right – we work collaboratively that way. She said ‘Yeah, well here’s the problem. You also said that at the end of every Scrum we should have zero known defects and the reason that won’t work is because we compensate our testers based on the number of defects they find.’ So she’s saying basically that’s not very motivating if you’re one of my testers because you’re going to make less money if you do that.Now, what she says next is the tell-tell sign for me as to whether a company has a hope of being successful with Agile. Here’s what she didn’t say. She did not say ‘Well, in that case, I’m just not going to assign my people out on to the Scrum teams. I’m not going to do that, I’ll just keep them together’. Meaning, I see the impediment. Agile has shone a bright light on where we have an impediment. And rather than address the impediment head on, instead what I’ll do is I’ll alter the definition of Agile so that that impediment doesn’t exist. Now, companies that are bolted to that approach will probably fail and fail quickly with Agile. Instead, what she actually said was ‘I think I’m going to have a conversation with the VP of HR and the VP of Engineering so that we can discuss how we’re going to change the compensation plan for our testers’. Now, we have in place people that understand that the current process, the current compensation system is at odds with them being successful with Agile. And rather than run away from the problem, hide when the impediment gets exposed, we’re willing to address it head on. So my advice – if you don’t have the executives trained or understanding these key points, you’re likely to have a problem. By the way, her next comment – I mentioned other things; I don’t pull people off of Scrum teams to work on your pet projects. Another person raised her hand and said ‘I do that all the time – what else shouldn’t I do?’At least in an environment like that, they’re willing to entertain it. So my approach to trying to address the problem is the leadership requires the proper kind of training and coaching principally on core Agile principles. That’s where I try to focus with them. So if I can get 60-90 minutes with them over lunchtime, that’s a good start. Not as good as having them in a multi-day class, but they’re not willing to make that commitment usually. So get 60-90 minutes, help them to understand that core Agile principles and hopefully they can align their behavior with how we’re going to do agility downstream, cause if they don’t, we will have a serious disconnect and companies with a better experience at that will likely fail in their attempt to use Agile, because of that disconnect. It’s a critical question and either they’re going to understand what we’re trying to do and embrace it, or they’re not and these companies are going to have a hard time. Ronnie: I love that example! One of the approaches that I’ve seen previously is that the director VPs and executive teams actually complete certified Scrum Master training. I believe that really helped them understand the vision and what Agile teams actually need.Ken: I find it beneficial when people like that, people with high level titles actually attend the classes. Part of the benefit is not just their understanding, which is profound, but a second benefit as well. You know, for example – in one class, I was talking about how teams should give range answers to questions as a way of communicating uncertainty. Range answers to planning questions, like ‘When will you be done?’ Give a range answer: between X number of sprints and Y number of sprints. And in this one class, an engineer stood up and said ‘Yeah, but my management is never going to accept a range answer’. And there’s only one person in this class – it was a large class – and the only person in this class wearing a suit was the general manager of the whole division. He then stood up, turned around and said ‘Well, I’m the guy asking the questions and I’m telling you I’m willing to accept a range answer and I’d like to talk to you about how we can keep range answers within one calendar quarter – but yes, a range answer will be acceptable’.That pretty much addresses the whole point right there. People are looking at each other, are like ‘Okay – he is the guy who’s asking questions and he just said he’s willing to do it and I guess we can actually move on here under the assumption we can provide range answers’. So getting the senior execs in a classroom, I think it’s a high priority – but it doesn’t happen nearly as frequently as it should. Occasionally, I’ll get the luxury of having a one day – and rarely, but it does happen – a two day class with leadership. I would say one of every four classes I do, we have that hour to 90 minutes lunchtime conversation. Which is precisely an hour to 90 minutes good, not as good as a half a day or a day or two would. Ronnie: Great answer! Leading to my third question which is adaptive vs. predictive, which is referenced in your book. One of the examples that came to my mind was release planning. Could you please take a moment to explain to our listeners adaptive vs. predictive and perhaps how it might apply to release planning?Ken: Be happy to. A lot of folks, when they think of Waterfall, they think predictive. Predictive up front water. In Waterfall, we have to put together the full requirements document on the first day, when we have the worst possible knowledge we’ll ever have about that project. So to a certain stage, you have to predict. If you’re being rude, you’d say you’d have to guess what all the requirements are. A lot of people didn’t think of Agile as adaptive – more just in time. So if you imagine like these two being on either sides of a teeter totter or a see-saw, what I’d like to suggest is that if you’re overly aggressive in either dimension, overly predictive or overly adaptive, you’re probably going to be unhappy.If you’re overly predictive, you’re probably just going to dip down into the guessing pool. There’s a part of you who might say ‘You couldn’t possible know that – not on the first day, not when you have the worst possible knowledge you’ll ever have!’ At this point, you’re just guessing, and that seems dangerous. On the other hand, if you’re fully adapted and you’ll do everything just in time, which in the context of release planning would mean no upfront planning whatsoever, my guess is that’s going to feel chaotic. Agile isn’t about everything done and adapted just in time. It’s about finding balance; balance between up-front work, predictive work and downstream adaptive work. And where you set that balance point will be different for different types of projects or products, different companies.So let’s buy into the fact that it’s a misperception to believe that Agile is anti-upfront planning. Because, of course, that’s simply not true. Agile is anti-waste. And if you do too much planning upfront, then you’re going to inject too much unnecessary planning inventory into the system that’ll have to be reworked or thrown out when something goes wrong. So the principle here is upfront planning should be helpful, just not excessive. In the spirit of just enough, just in time. But there’s nothing in there that says ‘avoid upfront planning’ so release planning – if you very specifically look at that, if you define what it means, in today’s world release planning is becoming a harder term to use because in the past, a release typically was performed after multiple sprints of work were completed. So in that scenario, a release was larger than a sprint. But what about the teams that release every sprint?You can argue ‘Well, isn’t sprint planning the same as release planning?’ Or what about teams that do continuous delivery or continuous deployment. They can release every feature as it become available during this sprint. You can even argue that in that context, a release smaller than the sprint. So let’s change the term just for a moment. Let’s call it longer term planning. And people might say ‘Well, longer than what?’ Well, longer than a sprint. Even if you release every sprint, or even if you release multiple times during the sprint, there’s still a benefit to looking out at a horizon that’s larger than a single sprint. We might be using milestone releases along the path to a bigger goal. And so release planning, is really trying to plan to that large goal.Okay, that presents certain issues. Here you are at on the first day of the project – what if that longer goal is 6 months out? Or even longer? Can you actually give any kind of accurate answer that early on? And the answer is that you’re going to get asked the questions. And we all know what the questions are. Questions like ‘When will you be done?’ or ‘How many of those features do you think will be available 6 months or 9 months from now?’ And ‘What’s all this going to cost?’Now, these seem like fair questions to ask. And for us, trying to be in a position to answer them, we need to figure out what realistically we can do. And the good news is we can do some things. And the way we’ll address it is, much like I was suggesting earlier, we give range answers. In release planning, the smart approach is always give a range answer to questions. If they ask, ‘When will you be done?’ – stating a specific date is likely going to be overly precise. On the first day of the project you cannot be that precise, you don’t have good enough information. But I can always be accurate by giving a range. You just have to give a sensible range. If I tell you it’s going to take 4-7 sprints to get this done; that expresses one level of uncertainty. If I said it’s going to take 4-29 sprints; that would express a completely different level of uncertainty.At a certain point, I know I can always be accurate, but it could be ridiculous. Yeah, it’s going to take between now and 3 years from now – yeah, but that’s not very helpful. So we try to give range answers that are accurate, that are reasonably actionable by the people who hear them. They can make a business decision – ‘Should I do this, should I not do it?’ So we have to do some amount of upfront planning to be in a position to answer those questions. Typically, at the release planning level, we try to work with medium-sized stories. Not epics that tend to be too big, but use more portfolio level planning, but with some people might call features or even themes so we try to generate a first pass at those, input high level size estimates on them and then based on a team’s history velocity, or a forecasted velocity, we try to give a rough estimate. And we try to simplify the problem. If someone says ‘Well, my release is going to be 2 years out’, I don’t think that’s a reasonable timeframe to be planning. Especially because there’s likely very important increments along that path that we can plan first. Rule number one is always try to turn a big problem into a small one in planning. And always give range answers. So I do think by balancing upfront, predictive work, sort of adjusted time adaptive work, we can do reasonable release planning. With a very important caveat. We update the release plan every sprint. Release planning is not a one time at the very beginning activity. Yes, I did do it early on because I probably got asked some questions I had to address. But I update my release with every single sprint as I acquire better knowledge. That’s how I tend to approach it.Ronnie: Perfect answer. Our next question is also from Essential Scrum which is in regards to idle work vs. idle workers. I’ve seen this come up countless times and it can be very frustrating on me. I often see management focused on idle workers. For example ‘Why is this person only at X percentage of utilization and rather than a team mindset of why is there work being idle?’ Could you please take a few minutes and explain idle work vs. idle workers for the audience? Ken: I will. To me, this is a critical topic, and I cover it in all of my classes because it lays a foundational principle that I need. The way I try to explain it to folks is this way: the largest cost in software product development is the people. Once we buy hardware and whatever software people need to do their job, the real cost of any software organization is the cost of the people that are hired, which is why budget almost always equals headcount. Everybody is interested in eliminating waste, but the issue of course, is that within organizations there are multiple forms of waste. And these types of waste typically trade off, meaning it’s usually impossible to simultaneously eliminate all forms of waste. So what people tend to do is they go after the waste they can see. And since we said the largest cost in software product development is people, then a visible obvious form of waste would be underutilization of people. Meaning, if I hire someone to do testing and I pay them 100% salary, there’s an expectation that that person is going to test 100% of the time. And by the way, my management probably measures me on how busy I keep that tester, so they assume that the tester reports to me. If I hire that individual in, pay them 100% salary and assign them to a project, and that project requires 60% of their time, if I were to stop there, it would give the appearance of a 40% underutilization of my tester. And I’ll look bad to my management because I’m paying this person 100% salary, but the individual’s only working 60% of the time. Okay, that won’t do.So to solve the problem, I’m going to do the obvious. I’m probably going to assign that person to a second project, which will lead them up 30%. Okay, I now have them at 90% utilization – but there’s still a 10% underutilization – well, it worked so well for 2 projects, let’s try 3. Okay, clever me. I’ve now eliminated idle tester waste. I’ve driven underutilization of my tester to 0. They’re 100% utilized. So I have eliminated that form of waste. The question, of course, is what just went the other way? Meaning, we said sometimes waste trades off – as one goes down, the other goes up. Well, here’s the problem. The idle workers weren’t waste that was causing the most economic advantage. Here’s the problem: as we keep people that busy, chances are they’re going to need to start blocking work. As an obvious example, I’ve assigned that person to work on 3 separate teams. It’s very likely, at any point in time, that person’s blocking two teams. They’re working on one of the projects and the other two are waiting. That means, the work is now idle.So what you end up seeing is this inventory that’s building up all over product development. Inventory being blocked work sitting in queues, waiting to get done. And the problem is that blocked work, that inventory, is causing huge economic damage. And people don’t focus on it because that’s an invisible form of waste, hard to see in our inventory and product development because typically, it’s bits out on the disk, code out on a server in best cases. Whereas inventory in other cases tends to be more visible. So they go after the visible ways which is idle workers and they ignore the kind of invisible ways. The people are still 100% busy, so it looks like the system is working at capacity. The problem is that if you examine what happens in large companies, at scale, if you look at how work flows across their organization, across the system, the collection of teams they put together to get the job done, what you often find is up to 90% of the time, the work is blocked.Imagine you took a stopwatch out of your pocket when a customer asks you to work on a feature and you agree to do it. If you click the stopwatch at that point and time starts running, you don’t get to click the stopwatch again until you’ve actually delivered the features to the customer. And so, what I’m saying, from click to click on that stopwatch, in a lot of organizations that I visit, up to 90% of the time or more the work isn’t moving. And that’s causing severe economic damage and the reason I say that is it’s injecting a cost of delay. The work could have been done faster and delivered to customers faster and delivering work faster generates revenue today; revenue today is worth more than revenue tomorrow because revenue today generates money and money is a time battle. When you compare the cost of delay, of idle work, against maybe a little bit of underutilization of the workers you realize that you’re working on the wrong thing.In organization, it’s all about the idle work, but that’s exactly the opposite of what most companies do. Most organizations attempt to optimize the utilization of their people, and by doing so, they inject a lot of delay into how long it takes to get the work done and that delay has a real cost. And they don’t quantify it, so they don’t really see the impact of that. So you focus on the idle work, you don’t worry about the idle workers. You’re trying to achieve what I call ‘fast, flexible flow’. To very quickly flow the work across to your teams in a fast and flexible way. You subordinate other decisions to that, which means ‘I don’t really care how idle or how occupied or how utilized your workers are, but I do care about is how quickly you can pull the work across your organization in a high quality way.’ Though in a sense, most organizations are focused in the wrong place. They’re watching the workers when they should be watching the work. That’s the concept here.Ronnie: Well, unfortunately I’ve seen that happen many times, and especially with the example regarding QA. It is such a common practice to do just what you described – when one person is placed on multiple teams to boost utilization numbers. That practice actually injects more project risk because if the person is working on team A, B and C – if team A hits a major bump in the road, there’s no margin to absorb it. Work simply becomes blocked in the other teams, it can really cause havoc. I love your answer which forces the organization to ask better questions.Ken: It’s a good example. I’ll leave you with one analogy for the listeners. And I know it’s the extreme analogy, so don’t get upset because it’s just extreme, but it’ll illustrate the point. Isn’t it true we pay firefighters to be idle most of the time? If you think about it, you really don’t want to keep your firefighters 100% utilized, because if you do, then the next fire that breaks out, very likely structures will burn and people might die. And as citizens, we deem that to be unacceptable. So we actually pay firefighters to be idle most of the time. Why? Because when you need them, you need them. And you need them now and any cost of delay associated with that work is unacceptable because the ramifications are too great. But I’m not saying you should pay people to sit around and be idle on your software project. But I’m suggesting the fallout – if there’s a certain skillset that when you need it, you need it; and any delay in it becoming available blocks your work and there is significant cost of delay in the blockage, you might want to seriously rethink the strategy of trying to keep everybody at 100%. Ronnie: Very true, I love that example. There are tons of questions that I would love to ask you, but I definitely want to respect your time. With that said, my final question is in reference to Validated Learning, which is mentioned in your book, Essential Scrum. I’m a huge fan of Validated Learning and the Lean Startup by Eric Ries, which I highly recommend. We may have some audience members that are not yet familiar with the concept and how it might apply to their team. Can you please take a few minutes and explain to our listeners Validated Learning? Ken: Sure. Lean Startup is a very good book and does leverage core Agile principles and a lot of the terminology, which is why I’ve used it in the Essential Scrum book, because it very nicely captures a category of principles that are fundamental to Agile. And the way to think about Validated Learning is you should validate important assumptions fast. It’s dangerous to make an important assumption and have it live long in an invalidated state. Because if I make an assumption and I don’t go out and get it validated, I start building things or making other decisions on top of that assumption and if a long time later I finally validate or attempt to validate the original assumption, what if I determine the original assumption was wrong? Now, I’m likely sitting on a problem that is much, much larger than it needs to be. So most people are familiar with the techniques of performing validated learning, prototype, concept study, experiment – meaning that validated learning is the act of buying information when you’re presented with a high degree of uncertainty, and therefore you made an assumption, if you were certain about something – you wouldn’t have to make an assumption, you’d just make the correct decision. But in the presence of a high degree of uncertainty, you have to make these assumptions and then what you have to do is go buy knowledge, buy information to validate your learning, meaning to be able to confirm or refute the hypothesis that you stated, the assumption that you made is correct or it isn’t.You just have to do that fast. So, in Agile, if you think about a learning block – you make an assumption, then we build something, then we get feedback on what we built, then we inspect and adapt, the goal is to go through that loop very very quickly. So in Agile the third part of this Validate Learning is that you have to organize the flow of your work to get fast feedback. In a sense, you say ‘What is the next most important thing I can learn?’ and then go learn it. And then validate your learning. And if you learn that you’re going the wrong way, take what you learn, plant your foot and alter your direction. Take the learning that you have and maybe go to a better place based on that. So Validated Learning has two superior economic characteristics. One – it prunes a bad path quickly. If you’re going down the wrong path, which you don’t want to do, is keep running down that path very fast. You’d like to determine you’re on the wrong path quicker so that you can then pivot over to a new path. That’s economically valuable. The second economic characteristic – it helps your exploit an emergent opportunity faster. What you don’t want to do is learn late in a project: ‘Wow – there’s a much better way we could’ve done this’. When it’s likely to do anything about it in this release and maybe in the future. Maybe we’re so far down committed on the path we’re on that even though we all now agree there’s a much better way of doing it, we actually can’t exploit it. By validating your learning sooner, you’re able to them exploit those opportunities sooner and end up in a much better place.So this is a critical concept. It applies in startup companies, it applies in well-established companies; they’re building the next generation product that’s been there for 10 years. You have to validate your learning, validate the important assumptions fast and you organize the flow of your work to get that fast effect.Ronnie: Thank you so much, Ken, for being such a great guest on our show. I’d love to give the listeners an opportunity to learn more about your services and how they may be able to contact you. Can you please take a few minutes to expound upon that?Ken: I appreciate that. I have a website, it’s innolution.com and on there I have a blog that I talk about a lot of these topics and I also have a lot of my presentations that I give at conferences so, if anybody’s interested feel free – you can go down and look at presentations on portfolio management, on what I call Essential Scrum and a variety of other topics, the most recent being risk management. So by all means, feel free to have a look at that. Mike Cohen and I also have developed a tool called Comparative Agility. It’s a free survey that you can take which at the end tells you how Agile your team is by comparing you with close to 13,000 other people who have already taken the survey – so there’s a number of resources out there. Also, I do offer training and coaching, so if your company might have an interest, feel free to contact me. All my information is on my website.Ronnie: Thank you so much for joining us today Ken and for your great insight and advice.Ken: I appreciate you hosting me and I wish everybody the best of luck with their application of Agile! Thank you for listening to All Things Agile! We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!