POPULARITY
2 episodes with tom poppendieck
2 episodes with tom poppendieck
2 episodes with tom poppendieck
2 episodes with tom poppendieck
2 episodes with tom poppendieck
2 episodes with tom poppendieck
2 episodes with tom poppendieck
2 episodes with tom poppendieck
2 episodes with tom poppendieck
BONUS: Rediscovering Agile's Roots, What We Can Learn From Lean Manufacturing with Doug Rabow In this BONUS episode, we reconnect with Doug Rabow, a previous guest and an expert in Lean-Agile strategic management known for his dedication to fostering empowered teams and enhancing processes through Lean principles. This discussion dives into the foundations of Lean, its evolution from manufacturing, and how software development can benefit from these time-tested methodologies. Join us as we uncover how adopting Lean can transform software practices and culture to align more closely with the true spirit of Agile. Introduction to Lean and the Toyota Production System (TPS) "Lean isn't just a methodology; it's an ongoing journey of learning and problem-solving." Doug begins by mapping out the origins of Lean and its cornerstone, the Toyota Production System (TPS) (Wikipedia article on TPS). Initially crafted to solve operational challenges in manufacturing, TPS introduced principles aimed at efficiency and continual improvement. Doug underscores that while Agile has gained broader recognition, Lean provides an essential, often overlooked foundation that extends beyond frameworks like Lean Six Sigma or isolated process improvements. "Lean isn't a set-and-forget solution; it's about cultivating an evolving culture of problem-solving." Cultural Foundations of Lean: Adapting for Software Teams "Respect for people and a culture of continuous improvement form the heartbeat of Lean." Transitioning to software development, Doug highlights the core cultural tenets that empower teams to excel. He points out that scaling these principles—such as fostering a culture where problem-solving is embedded in daily practices—is vital due to the complexities of software as a people-driven process. Referencing Conway's Law, Doug illustrates how the structure of teams directly impacts code and workflow. "Developing software is as much about building teams as it is about building products. Lean teaches us that these are inseparable." The Toyota Way: A Blueprint for Excellence "Applying Lean is about chasing excellence, not just managing tasks." Jeffrey Liker's The Toyota Way introduces 14 principles that Doug relates to software environments, emphasizing the value of discipline and respect for people. He discusses the importance of aligning processes with long-term strategies and ensuring that these processes are designed to foster continuous learning. Doug reiterates that truly understanding and integrating Lean requires more than surface-level adoption. "Respect for people isn't an add-on in Lean; it's the root of a thriving, innovative team culture." Waste in Software Development: Insights from the Poppendiecks "Work in progress is not an asset; it's a liability." Doug shares insights from Mary and Tom Poppendieck's (Mary and Tom have been on our podcast here) pioneering work on Lean Software Development, particularly their adaptation of waste types from manufacturing to software. These include partially done work, extra features, relearning, handoffs, and task switching. Doug points out that waste reduction strategies—such as Kanban and pull systems—help teams minimize bottlenecks and optimize flow. "Software development, like manufacturing, benefits from visualizing value streams and focusing on reducing waste." Metrics and Measurement in Lean "The right process will create the right results—focus on process metrics, not individual metrics." In Lean, metrics are crucial for assessing and refining processes. Doug advocates for using metrics like cycle time and throughput to provide teams with insights into system efficiency. He explains how focusing on process metrics rather than individual productivity helps sustain a culture that prioritizes team learning and growth. "When we measure what truly matters—the process—we empower teams to solve problems collectively and improve outcomes." About Doug Rabow Doug Rabow is a dedicated practitioner of Lean-Agile strategic management with an emphasis on building empowered teams and optimizing processes through Lean methodologies. His extensive experience in applying Lean principles in software development has made him a trusted voice in the Agile and Lean community. You can link with https://www.linkedin.com/in/dougrabow.
Join Murray Robinson and Shane Gibson in a conversation with Mary and Tom Poppendieck about Lean and Software Development. Organizations have queues because they don't care about the customer. The three rules of lean, customer focus, flow and highly efficient expert teams. Scale your organization like a micro services architecture. Its not about doing the work right its about doing the right work. Don't focus on utilization focus on the value we provide. Don't copy practices copy the principles behind the practices. Don't centralize processes. Set goals and let teams develop their own processes. Listen to the podcast on your favourite podcast app: | Spotify | Apple Podcasts | Google Podcasts | iHeart Radio | PlayerFM | Amazon Music | Listen Notes | TuneIn | Audible | Podchaser | Connect with Mary and Tom @ http://www.poppendieck.com/ or leanessays.com, Murray via email or Shane in the Twitter-sphere @shagility. The No Nonsense Podcast is sponsored by: Simply Magical Data
"Pull, don't push. Don't tell people what to do. Tell them what results you want and let them figure out how best to achieve the outcome that's needed." Mary & Tom Poppendieck are the co-authors of several books related to Agile and Lean, including their award-winning book “Lean Software Development: An Agile Toolkit” published in 2003. In this episode, Mary & Tom shared about lean software development, its principles and mindset, and the concept of a pull system. Mary & Tom then pointed out the problems of having proxies in software development and how it is much better to manage by the outcomes by having the people directly figuring out the best way to achieve those outcomes. Later on, Mary & Tom talked about the concept of flow, why it is important to optimize flow, and how to optimize flow by analyzing the value stream map and minimizing approval process. Listen out for: Career Journey - [00:05:26] Lean Software Development - [00:18:50] Pull, Don't Push - [00:23:34] Proxies - [00:31:00] Managing by Outcome - [00:37:10] Optimizing Flow - [00:41:18] Value Stream Map & Approvals - [00:47:00] 3 Tech Lead Wisdom - [00:55:05] _____ Mary Poppendieck's Bio Mary wrote the now-classic book “Lean Software Development: an Agile Toolkit”, proposing an approach which focuses on customers, respects software engineers, concentrates on learning, and leverages flow. Mary is a popular writer and speaker. Sequels of her first book include “Implementing Lean Software Development: from Concept to Cash”, “Leading Lean Software Development: Results are Not the Point” and “The Lean Mindset: Ask the Right Questions”. Tom Poppendieck's Bio Tom has over three decades of experience in computing, including several years of work with object technology. Tom holds a PhD in Physics and has taught physics for ten years. He is the coauthor of four books: “Lean Software Development” (2003), “Implementing Lean Software Development” (2006), “Leading Lean Software Development” (2009) and “Lean Mindset” (2013). Follow Mary and Tom: Website – http://www.poppendieck.com/ Mary's blog – http://www.leanessays.com/ Mary's Twitter – @mpoppendieck Our Sponsor Today's episode is proudly sponsored by Skills Matter, the global community and events platform for software professionals. Skills Matter is an easier way for technologists to grow their careers by connecting you and your peers with the best-in-class tech industry experts and communities. You get on-demand access to their latest content, thought leadership insights as well as the exciting schedule of tech events running across all time zones. Head on over to skillsmatter.com to become part of the tech community that matters most to you - it's free to join and easy to keep up with the latest tech trends. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/91.
For a team, is solo leadership the most effective? Or is collective leadership a feasible alternative? Should product responsibility be primarily a solo activity? Or fundamentally the activity of a group? With sometimes drastic differences in timing and supply chain, how can one stay lean in the complicated world of IoT products that not only have software but also have hardware and firmware? Join Chris and Austin for another fantastic time with Mary and Tom Poppendieck. They pick up the discussion where they left off last time and revisit "Leadership and Responsible Engineers." However, this time they focus on collective vs. solo leadership and collective vs. solo responsibility. Then they dive into the "Lean Internet of Things" and techniques for healthy system integrations. Video and show notes: https://youtu.be/9SyYPaAD1K4
In this episode of The Rabbit Hole, we are unpacking The Seven Wastes of Software Development! Dave and Michael break down the seven points as they appear in the book Implementing Lean Software Development by Mary and Tom Poppendieck and chat about their experience and thoughts on each.
When it comes to software delivery, what terms do you use to describe results? Products, features, points, enhancements, specs, or requirements? Something else? Who is responsible for software delivery? Who should be? Has Agile missed the boat when it comes to responsibility and leadership? Join Chris and Austin as they discuss "Responsible Engineers and Outcomes" with Mary and Tom Poppendieck. They walkthrough concrete examples of what it looks like for lean teams to optimize outcomes and minimize outputs. While exploring these examples, they touch on customer interaction, feedback, the responsible engineer, and the single threaded leader. You don't want to miss this episode of the Mob Mentality show with two of the biggest thought leaders in lean software development! FYI: Video and show notes to be posted here in the next day or so.
Mary and Tom Poppendieck join us to talk about Software Engineering: Then, Now, and Next. Mary started her career as a process control programmer, moved on to manage the IT department of a manufacturing plant, and then ended up in product development, where she was both a product champion and department manager. Tom is an enterprise analyst and architect, and an agile process mentor. He focuses on identifying real business value and enabling product teams to realize that value. Links http://www.poppendieck.com/ https://www.leanessays.com/ https://twitter.com/mpoppendieck Resources Working Backwards: Insights, Stories, and Secrets from Inside Amazon Think Like Amazon "Tempting Time" by Animals As Leaders used with permissions - All Rights Reserved × Subscribe now! Never miss a post, subscribe to The 6 Figure Developer Podcast! Are you interested in being a guest on The 6 Figure Developer Podcast? Click here to check availability!
This podcast is the last podcast of 2021 and marks the end of season #1. I do a quick overview and review of the podcast over the year. I wanted to thank the following guests: Ben Rockwood (@benr)Doris QuinnMary and Tom Poppendieck (@mpoppendieck)Jeffrey Fredrick (@Jtf)George Dekker (@GeorgeDekker)Dr. Steven Spear (@StevenJSpear)Courtney Kissler (@chawklady)Josh Corman (@joshcorman)Kevin Behr (@kevinbehr)Elisabeth Hendrickson (@testobsessed)harper (@harper)Carmen DeArdo Dennis Schlagheck Glenn Wilson (@GlennDynaminet)Mark Burgess (@markburgess_osl)John Waraniak (@JohnWaraniak)Steve Pereira (@SteveElsewhere)Jabe Bloom (@cyetain)Paula Thrasher (@paula_thrasher)Dominica DeGrandis (@dominicad)Laksh Raghavan (@laraghavan)Tom Geraghty (@tom_geraghty)Andrew Clay Shafer (@littleidea)
This episode is a continuation of Richard's interview with Mary and Tom Poppendieck. As the official part of the interview finished, they continued chatting and sharing some great ideas. Luckily, the record button was still on, so we can share this fantastic "unofficial" part of the conversation with you. You can read the transcript of the episode at https://kasperowski.com//podcast-75-mary-and-tom-poppendieck
In this episode, Richard interviews Mary and Tom Poppendieck. Richard's Agile heroes, the Poppendiecks have written highly influential works on lean software development, including Lean Software Development: An Agile Toolkit, The Lean Mindset, and Leading the Lean Software Development: Results are Not the Point. Richard tackles with them one of the burning problems of today's business world: how to retain an increasingly independent workforce? When you finish listening to this episode, visit their website at: http://www.poppendieck.com. You can read the transcript of the full episode at http://kasperowski.com/podcast-74-mary-and-tom-poppendieck.
Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Tomo worked with 6 teams on a project. Although the teams were good at developing software, they lacked something that was critical. As Tomo investigated further, he pinpointed what was missing, and focused on providing them with the tools to overcome their lack of innovation, and decision making ability. In this segment, we refer to the concept of Swarming, which when applied correctly can make times much more productive. How can Angela (the Agile Coach) quickly build healthy relationships with the teams she's supposed to help? What were the steps she followed to help the Breeze App team fight off the competition? Find out how Angela helped Naomi and the team go from “behind” to being ahead of Intuition Bank, by focusing on the people! Download the first 4 chapters of the BOOK for FREE while it is in Beta! Featured Book of the Week: Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck is one of the foundational books for Lean applied to software. Although many have followed the Poppendieck's, their book still has many learnings on how to apply Lean to software development. In this segment, we also refer to the work by Klaus Leopold, of which the book Rethinking Agile is one example. About Tomo Lennox Tomo has 20 years experience in project management, both waterfall and Agile. A few years ago he was at David Anderson's first Kanban Conference and has been a fanatic ever since, even though he has lost several jobs as a result of it. Tomo became then an advocate for projection over guessing, and reactive planning. You can link with Tomo Lennox on LinkedIn and connect with Tomo Lennox on Twitter.
Mary and Tom are instrumental figures on the path I call "Deming to Devops". We discuss their journey from lean to their modern-day thought leadership roles. Chatting with Mary and Tom about Dr. Deming... it doesn't get any better than this.
Get the book.Mary and Tom’s websitePentatonix singing Aha! in Singapore (and Mitch blowing Paul's mind)Support the show (http://patreon.com/agilebookclub)
Get the book.Here's the song I mentioned, and missnamed.This is the company that makes the mystery game. If you sign up for notifications of new games, they give you a free mini game.Here is the one-page contract I used with companies of all sizes for projects up to a quarter of a million dollars.Support the show (http://patreon.com/agilebookclub)
Welcome to yet another episode on the Agile Atelier podcast! Today’s topic is Lean Software Development, I have the pleasure of chatting with two special guests – Mary and Tom Poppendieck. Mary and Tom are best known for their book Lean Software Development: An Agile Toolkit. Mary started her career as a process control programmer,…… Continue reading Episode 30: Lean Software Development with Mary and Tom Poppendieck
https://www.leanblog.org/391My guests for Episode #391 are Mary Poppendieck and Tom Poppendieck, the authors of books including Lean Software Development: An Agile Toolkit, Implementing Lean Software Development, and The Lean Mindset: Ask the Right Questions.In the episode, we'll hear their thoughts on Lean as "a way of thinking that values people" and how teamwork, problem solving, and customer focus are integral to Lean -- in software or otherwise. How can we build capabilities for problem solving ("producing people") and how can we "learn how to learn"?Questions, Links, and MoreHow did you first discover Lean? How did you come to see the potential applications to software development?You published Lean Software Development in 2003 -- how do you define that term “Lean” and what does it mean to you?How has your view of Lean evolved over those 17 years?What have you learned about Lean / TPS from visiting Japan?Your 2013 book is called "The Lean Mindset" -- as the subtitle says, asking the right questions is important... why so? How do we know what the right questions are?2009 -- Leading Lean Software Development -- another provocative subtitle... "results are not the point" -- what do you mean?LeanEssays.comTheir website: http://poppendieck.com/Mary on Twitter
Joe Krebs speaks with Mary and Tom Poppendieck about Lean Software Development. Together they wrote a series of books: “Lean Software Development” “Implementing Lean Software Development”, “Leading Lean Software Development” and “The Lean Mindset” in chronological order. Mary and Tom talked about how Lean fits into the universe of processes, tools and techniques in regards to processes like Scrum or Kanban. They did that from a leaders point of view. We discussed the role of knowledge workers and how that relates to people for example in Lean Manufacturing. We also had a chance to touch on Kata practices as they gave feedback to the initial release of the Agile Kata.
In this episode, I speak with Mary and Tom Poppendieck about Lean Software Development. We talked about knowledge workers vs. manufacturing, scaling, kaizen and the kata. Mary and Tom also grouped the last 4 decades of software development and give a projection for the decade starting in 2020. I hope you enjoy the listen. If you like to meet Mary and Tom in person, join the Agile Power Week in New York on MAR 3-5. (www.incrementor.com/apwnyc).
Allen Holub on Deliver It, Jason Tanner on Drunken PM, Mary and Tom Poppendieck on Unlearn, Saron Yitbarek on Greater Than Code, and Dave Karow and Trevor Stuart on Deliver It. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting July 8, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. ALLEN HOLUB ON DELIVER IT The Deliver It podcast featured Allen Holub with host Cory Bryan. Cory started out by reviewing an article by Ron Jeffries called “Story Points Revisited.” Allen’s take is that the negatives around story points are more than just the potential for misuse; he believes story points have no value at all. He says the most important thing is to narrow your stories, not estimate them. He says estimates exist because of fear. The software development process is opaque to certain managers and, as a result, they want estimates to alleviate their fear, but when you are delivering every day, you can eliminate the fear without resorting to estimates. Cory asked Allen what product owners need to know about Agile architecture. Allen said that one of the mistakes that he sees product owners make a lot is they try to do a miniature up-front design and expect that to be implemented. When this happens, he says there is too much information captured up-front of what is going to be built during the sprint and not enough information captured during the sprint as a side effect of releasing code to users and getting their feedback. This leads to inappropriate architectures because when you do anything up-front, you start doing everything up-front. Your sprint planning starts involving architecture decisions, UI decisions, and UX decisions that may be wrong and you will not know if you are wrong until you release. In Allen’s view, the most important thing a product owner does is answer questions that come up during the course of development. He uses a “two-minute rule”: if a question comes up during development, the product owner needs to be able to answer within two minutes. Allen talked about how the constraints of a bad architecture can prevent you from ever being Agile. He says, “Agile has nothing to do with standup meetings and backlog grooming and all of those. The important thing is to get stuff into your user’s hands quickly.” Allen says that the architecture has to be focused on the domain. Where systems that are wrong go wrong is that they don’t map to the domain but to the technology. A change at the story level, which is where the majority of changes come from, ends up touching all the modules or layers of your system when your architecture is mapped to your technology instead of your domain. Allen says that when he does a workshop on Agile architecture, people raise their hands about halfway through and say, “All we’re doing is domain analysis!” The fact is, if the domain and code are matched to each other, domain analysis is architecture. One of the questions Allen asks when he gets a bunch of product owners in a class is, “How many of you talk to multiple customers multiple times a day?” Maybe 5% raise their hands. So he says, “Who in the organization does talk to multiple customers multiple times a day?” This is often met with silence. He asks, “What about Sales? What about Tech Support?” He says that if you can’t respond to customer kinds of issues as well as a salesperson or a tech support person could, you don‘t know the domain well enough to be helpful to the engineering team. Cory asked Allen what he thought of the distinction between regular stories and “technical” stories. Allen says that there is no such thing as technical stories. A story describes the users of your system performing some kind of domain level work to achieve a useful outcome. Fixing some technical thing like changing the color of a button in no way makes your end users’ lives easier; it does not help them do their work. Allen says that the role of the architect in an Agile environment is very different from what we traditionally think of, just like the role of a manager in an Agile environment. In Agile environments, the job of people who are in a leadership position is to make sure that you can do your job, not to tell you what to do. They communicate a strategic requirement, provide support, and remove the obstacles. The same, he says, applies to Agile architects. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ep90-agile-architecture-with-allen-holub/id966084649?i=1000441313352 Website link: http://deliveritcast.com/ep90-agile-architecture-with-allen-holub JASON TANNER ON DRUNKEN PM The Drunken PM podcast featured Jason Tanner with host Dave Prior. Dave started out by asking Jason why he believes the daily scrum is broken. Jason said that the daily scrum is broken because, first, most developers hate the daily scrum because most daily scrums take the traditional weekly project status review meeting and do it five times a week with the Scrum Master filling the role of the project manager. Second, he says, is that it is being done backwards. The center of attention should not be the Scrum Master, but the team and the sprint backlog. He says that the purpose of the daily scrum is misunderstood. The three questions don’t result in a plan but result in just an exchange of information. For what real daily planning looks like, he uses an analogy of driving down the road and seeing a bunch of plumbers’ trucks from the same company parked outside of a McDonald’s. Inside, they’re planning things like, “We’re going to the Johnson’s house at noon. Can you come over and meet me because it’s going to be a two-man job.” Jason says he hates the three questions. He says the subject of the sentence is not helping us in collective ownership of the sprint backlog. “I have my user story. I have my Jira ticket. I have five team members and we each have a ticket.” Shifting the subject of the sentence to “we”, he says, changes the behavior dramatically. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jason-tanner-is-on-a-mission-to-fix-your-daily-scrum/id1121124593?i=1000441958371 Website link: https://soundcloud.com/drunkenpmradio/jason-tanner-is-on-a-mission-to-fix-your-daily-scrum MARY AND TOM POPPENDIECK ON UNLEARN The Unlearn podcast featured Mary and Tom Poppendieck with host Barry O’Reilly. Barry asked Mary and Tom what we may need to unlearn since the Agile movement began. Mary says that Agile started as a reaction to what was going on at the time. The vast majority of people doing software engineering today weren’t around back then. One of the things Agile has to do is grow up to be not a reaction to bad things that happened in the past, but to be something that talks about, “What does it take to do good software engineering?” She contrasted the software engineers she speaks to today that expect to be handed a spec with the engineers she worked with early in her career who treated engineering as problem-solving. Tom talked about how many who are working to make organizations more agile attempt to solve problems with process. This assumes that the organization’s problems are process problems but they are actually architectural problems. This includes problems with the architecture of the applications they are evolving, problems with the structure of the organization, and problems with the structure of the relationships between the supporting groups and those who are benefitting from said groups. Mary talked about how Amazon AWS was one of the early organizations to understand that you need to give teams of smart, creative people problems to solve. As a result of having this insight, they organized the company in such a way as to optimize for this, such as by eliminating a central database which was heresy back in 2005. She called out AWS Lambda in particular because this product did not optimize for short-term shareholder value and would never have been approved at most companies because it reduced what Amazon was charging customers by five times. She attributes this ability to self-disrupt as being essential to Amazon AWS’s success. Tom talked about the fact that when you attempt to scale things up, you reach a point where complexity dominates any future gains and wipes them out. He says you instead need to de-scale: figure out how to do things in little chunks that are independent and don’t require coordination. He says that this is how cities have been organized for thousands of years. Mary said that she has been doing software since 1967 and has never seen anything last two decades and still be current. Agile is two decades old and cannot be current unless it is constantly adapting to what is current today. She brought up continuous delivery as a fundamental change in agile thinking. It changed the way we thought about how we structure organizations and teams and what kinds of responsibilities we should give to them. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/solving-problems-safely-with-mary-and-tom-poppendieck/id1460270044?i=1000442018979 SARON YITBAREK ON GREATER THAN CODE The Greater Than Code podcast featured Saron Yitbarek with hosts Arty Starr, Rein Henrichs, and Chanté Thurmond. They talked about the annual Codeland conference Saron is running and how it offers free on-site childcare this year. Saron says free on-site childcare at conferences today is where codes of conduct were a few years ago. She says that if her conference wasn’t making it easier for parents to attend, it wouldn’t be living up to their promise for inclusion. Chanté asked Saron what she learned in her transition from being a code newbie herself to the present day where she is running two podcasts, a software job, and a conference. Saron said she learned that it is important to be consistent in all your efforts, whether it is community work, your personal projects, or a project at work. Nothing gets built overnight and, for a while, nobody will care what you’re doing. If you want to do something great, it takes persistence and it takes you believing in yourself especially when you’re not getting external validation. Arty asked about what expertise in “newbie-ism” might look like. Saron says that it is about being comfortable in a state of frustration. She pointed to a study on the difference between those who finish a computer science degree and those who quit. The study said that those who finished the degree were comfortable being in a state of confusion: they knew that things were not going to make sense for a while and they were ok with that. A second thing, she says, that helps you become an expert newbie is realizing that almost all problems in coding are solvable. By contrast, in writing, there is no perfect essay. In journalism, there is a search for truth, but is truth attainable? In life sciences, we study nature all around us that we may never fully understand. She also says to keep your frustration external, avoid internalizing your failures, and she says to distance who you are from your work and the things you produce. Saron’s comment on being comfortable in a state of confusion triggered a Virginia Satir quote from Rein: “Do you know what makes it possible for me to trust the unknown? Because I've got eyes, ears, skin. I can talk, I can move, I can feel, and I can think. And that's not going to change when I go into a new context; I've got that. And then I give myself permission to say all my real yeses and noes, because I've got all those other possibilities, and then I can move anywhere. Why not?” Rein asked what Saron learned about teaching. Saron says that teaching is storytelling in disguise. She says that if we frame teaching opportunities as storytelling opportunities we can be better teachers. This reminded me of Josh Anderson’s comment on the Meta-Cast podcast that I referenced way back in episode 3, “Taking The Blue Pill Back To Sesame Street.” Rein brought up a theory of learning called conversation theory. In conversation theory, teaching happens as a conversation between two cognitive entities. You have to come to agreement and build a bridge with that other cognitive entity. It deconstructs the teacher-learner binary. The teacher themselves has to be a learner too. Chanté asked about the ethos at Code Newbie for being a learner and a teacher. Saron says they look to the community to pitch in. When someone asks a question, they encourage the community to answer. She contrasted Code Newbie with Stack Overflow. Code Newbie attempts to teach the learner from where they are and avoid the condescension that is common on Stack Overflow. She said that to create an environment where people are not afraid to ask questions, we have to be unafraid of being vulnerable ourselves. Go first, share your vulnerability, and share what you’re struggling with. The moment you start doing that, other people will be much more likely to raise their hands as well. Chanté asked Saron what resources she recommends for code newbies to learn to code. Saron said that the hard part isn’t finding resources but sticking with them when things get tough or boring. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/135-intentional-learning-with-saron-yitbarek/id1163023878?i=1000442022293 Website link: https://www.greaterthancode.com/intentional-learning DAVE KAROW AND TREVOR STUART ON DELIVER IT The Deliver It podcast featuring Dave Karow and Trevor Stuart with host Cory Bryan. They talked about running experiments to learn about your customer. Cory asked how people can run such experiments at scale. David pointed out that having a way to run the experiment is one thing, but you also need to be able to rapidly make sense of the results in a repeatable, authoritative way. Trevor says it is all about assumptions, hypotheses, and documentation. Before you even start your experiment, you need to understand why you are running it in the first place. In other words, you need to establish what is going to change as a result of the experiment. Trevor says that much of the market is already doing experiments and they don’t know it. They just call it “using feature flags” and rolling things out incrementally. They just need to move one step further to slice and dice their user populations, roll things out for longer time periods to those users, and bring the resulting data into a form that facilitates decision-making. David talked about dog-fooding by starting your rollout of new features with your employee population, giving examples from Microsoft, where it takes a few weeks to go from the employee population to the full customer population, and Facebook, where it takes about four hours for the same kind of rollout. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ep91-product-experiments-with-trevor-and-dave-from-split/id966084649?i=1000442844631 Website link: http://deliveritcast.com/ep91-product-experiments-with-trevor-and-dave-from-split FEEDBACK Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website:
> Sign Up For Our Newsletter: http://www.firsthuman.com/being-human-newsletter/In this week's episode of Being Human, I talk with Lean icons, husband-and-wife authors and teachers, Mary and Tom Poppendieck. Mary and Tom travel the world helping people to create and deliver stunning products and services through the power of the Lean approach. We talk:- The origins of Lean as fundamentally about people working at their best- The metaphor of double-entry bookkeeping for building in software quality- Why business should focus on flow efficiency, not resource efficiency- Why you should *not* be automating your business processes- The first questions to ask yourself in starting a Lean journeyEnjoy!Links:New writing: www.leanessays.comBooks:"Lean Software Development": https://amzn.to/2XenqYP"Implementing-Lean-Software-Development": https://amzn.to/2JfWqyB“The Lean Mindset”: https://amzn.to/2FAMBdd“Leading Lean Software Development”: https://amzn.to/2XbrXeJ
> Sign Up For Our Newsletter: http://www.firsthuman.com/being-human-newsletter/In this week's episode of Being Human, I talk with Lean icons, husband-and-wife authors and teachers, Mary and Tom Poppendieck. Mary and Tom travel the world helping people to create and deliver stunning products and services through the power of the Lean approach. We talk:- The origins of Lean as fundamentally about people working at their best- The metaphor of double-entry bookkeeping for building in software quality- Why business should focus on flow efficiency, not resource efficiency- Why you should *not* be automating your business processes- The first questions to ask yourself in starting a Lean journeyEnjoy!Links:New writing: www.leanessays.comBooks:"Lean Software Development": https://amzn.to/2XenqYP"Implementing-Lean-Software-Development": https://amzn.to/2JfWqyB“The Lean Mindset”: https://amzn.to/2FAMBdd“Leading Lean Software Development”: https://amzn.to/2XbrXeJ
> Sign Up For Our Newsletter: http://www.firsthuman.com/being-human-newsletter/In this week's episode of Being Human, I talk with Lean icons, husband-and-wife authors and teachers, Mary and Tom Poppendieck. Mary and Tom travel the world helping people to create and deliver stunning products and services through the power of the Lean approach. We talk:- The origins of Lean as fundamentally about people working at their best- The metaphor of double-entry bookkeeping for building in software quality- Why business should focus on flow efficiency, not resource efficiency- Why you should *not* be automating your business processes- The first questions to ask yourself in starting a Lean journeyEnjoy!Links:New writing: www.leanessays.comBooks:"Lean Software Development": https://amzn.to/2XenqYP"Implementing-Lean-Software-Development": https://amzn.to/2JfWqyB“The Lean Mindset”: https://amzn.to/2FAMBdd“Leading Lean Software Development”: https://amzn.to/2XbrXeJ
Barry O’Reilly has had many mentors over the years, and among them, Mary and Tom Poppendieck have been some of the most inspirational. In today’s conversation, they talk about challenges the Agile community faces, debunk the myths of scaling agility, and finally, Mary and Tom reveal how they have stayed relevant for decades as they continue to coach, mentor, and help others. About Mary and Tom Neither Mary nor Tom started with software. Mary was an engineer who worked with problems that had life and death ramifications, and Tom was a physics teacher whose students contact him decades later to say ‘thank you - you made a big difference.’ They’ve written many of the seminal books and contributed much to the Lean and Agile movement and have seen fads and trends come and go. Barry asks them what has been their key insights over the years. When did you discover agile? Agile developed as a reaction to what was happening in the software industry in the late 1990s. Agile has to grow up, to no longer be reactionary when bad things happen, but to determine how to create GOOD software engineering from the start. She draws on her experience as a traditional engineer and shares a lesson about how proxies between engineers and people with problems are a bad idea. It’s a matter of trusting professional judgment. Tom observes that, too often, Agile tries to solve problems with processes. But the problem isn’t usually the process; it’s architectural. He talks about the different structures, from software to the leadership teams, that can lead to dysfunctional situations. If you want to solve a problem, you need to fix the structure. How Agile Can Grow There’s no simple answer to this, Mary points out because it depends on where you’re at. You can understand all the fundamental steps needed but if your team isn’t well-integrated, it will get you nowhere. She shares an experience with a company who had accepted a big contract they weren’t ready for. Mary recommended the ‘sync and stabilize' method and taught them how to use it. It didn’t just save their contract; it changed how they looked at their whole company. Tom highlights the non-technology component of software, the ‘wetware,’ or what happens with people. He points out that money isn’t the issue; it’s the shortage of passionate, creative people - especially in isolated IT departments that are treated as cost centers. Tom believes you should give them challenging problems and get out of their way. Teams Tailored to Problems Mary loves to talk about how organizations such as AWS and T-Mobile handle their organizational structure and customers. When there is a customer problem, a team is brought together to solve it and integrate it into the rest of the services so everything works. That team is given a lot of autonomy, including trading immediate profits for better customer experience AND have accountability to ensure they are also adhering to operational excellence and profitability of their service. Ultimately, better customer experiences drive bigger profits. Tom makes an important point: scaling isn’t possible after a certain point. At some point, complexity dominates future gains and wipes them out, so you have to descale. In other words, you have to do things in ‘little chunks’ that are independent and don’t require strict coordination. Tom uses the example of a city and how it functions. Final Thoughts Part of what helps Tom and Mary stay current is that they are truly agile. Mary points out that she’s never seen anything in technology last two decades and remain current. Agile has been around for about that long, but has it been changing and adapting? Resources https://twitter.com/mpoppendieck http://www.poppendieck.com/
Mary and Tom Poppendieck on The Modern Agile Show, Daniel Mezick on Agile Uprising, Jennifer Tu, Zee Spencer, Thayer Prime, and Matt Patterson on Tech Done Right, James Colgan on This Is Product Management, and Matt Kaplan on Build by Drift. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting March 18, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. MARY AND TOP POPPENDIECK ON THE MODERN AGILE SHOW The Modern Agile Show podcast featured Mary and Tom Poppendieck with host Joshua Kerievsky. Recorded at the ScanAgile 2018 conference in Helsinki, Mary and Tom talked about their keynote on proxies and permissions. Inspired by Bret Victor’s statement that creators need an immediate connection to what they create, Tom and Mary presented on how the most effective teams are autonomous, asynchronous teams that are free of the proxies and permissions that separate creators from their creations. This led to a discussion of lean thinking and Mary pointed out that the interesting thing about lean is that fast and safe go together. She gave the example of a construction site where nothing slows things down more than the occurrence of an accident. Mary talked about how Jeff Bezos is a good early example of someone who understood that if you want to get really, really big, you need to have autonomous agents acting independently and thinking for themselves. iTunes link: https://itunes.apple.com/ca/podcast/interview-with-mary-and-tom-poppendieck/id1326918248?i=1000407584120&mt=2 Website link: https://github.com/modernagile/podcast/blob/master/ModernAgileShow_26_Interview_with_Mary_and_Tom_Poppendieck.mp3 DANIEL MEZICK ON AGILE UPRISING The Agile Uprising podcast featured Daniel Mezick with hosts Jay Hrcsko and Brad Stokes. Daniel told the story of how the OpenSpace Agility movement was born from ideas he brought to a Scrum Gathering in Paris in 2013 under the name Open Agile Adoption. He described Open Space as an invitational, all-hands meeting format in which there is an important issue, no one person has the answer, and there is an urgency to reach a decision. The Open Space format then creates the conditions for high performance through self-organization. Brad brought up that he imagines that OpenSpace Agility can be terrifying to some leaders. Daniel noted that the fear is due to the fact that we have failed the executive leadership of the largest organizations. In the name of “meeting them where they’re at,” we’ve traded away our principles and values and haven’t taught them anything in exchange. Daniel says, “Self-management scales. Not the framework.” This echoes Mary Poppendieck’s comments from the Modern Agile Show on how self-managing, autonomous, asynchronous agents are the only way to scale. Using Scrum as an example, Daniel said that, for the Product Owner to be successful, everyone in the organization must respect his or her decisions. If you do that, he says, you will immediately get culture change because you’ve refactored the authority distribution schema. iTunes link: https://itunes.apple.com/ca/podcast/openspace-agility-with-daniel-mezick/id1163230424?i=1000430511928&mt=2 Website link: https://agileuprising.libsyn.com/podcast/openspace-agility-with-daniel-mezick JENNIFER TU, ZEE SPENCER, THAYER PRIME, AND MATT PATTERSON ON TECH DONE RIGHT FROM TABLE XI The Tech Done Right podcast featured Jennifer Tu, Zee Spencer, Thayer Prime, and Matt Patterson with host Noel Rappin. Noel started by asking the guests what they thought the biggest mistake people make when trying to hire developers is. Thayer said, “One of the biggest mistakes anybody makes in hiring is hiring people they like and that they want to work with because they’re nice as opposed to hiring against a spec of what the worker is supposed to be doing.” This comment matches my own experience because this practice was rampant on previous teams of mine. Jennifer asked Matt how his company attracts candidates and he described using their current employee’s networks. Thayer called this the number one diversity mistake that all companies make. Noel asked about what to do at the end of the process where you need to go from multiple opinions you need to turn into a single yes/no decision. Jennifer has everyone write down their impressions before they talk to anyone else and write down specifically what they observed to support the conclusion you come to. This is how I always do it, but I’m always surprised at how few teams practice this. Noel asked about good and bad uses of interview time. I loved Jennifer’s example of what a bad use of time it is to say, “Tell me about yourself.” Sometimes I have candidates jump into providing this kind of information even though I hadn’t asked. Such people steer the interview into a well-prepared speech of all their best qualities that doesn’t give you a full picture of the candidate. Thayer then made a comment about the tendency of interviewers to try to make the candidates sweat. I agree with Thayer that this is usually the exact opposite of what you want if you’re trying to make the interview as much like the actual job experience as possible. iTunes link: https://itunes.apple.com/ca/podcast/episode-56-developer-hiring/id1195695341?i=1000430735771&mt=2 Website link: https://www.techdoneright.io/56 JAMES COLGAN ON THIS IS PRODUCT MANAGEMENT The This Is Product Management podcast featured James Colgan with host Mike Fishbein. James is a product manager for Outlook Mobile, which has 100 million monthly active users. James talked about his strategy for user growth being to make a product that is trusted by IT and loved by users. This led to their measures of success, such as usage and love for the product, measured by things like app store rating. James gave a great example of doing user research to create a product that is loved globally rather just in certain geographies. They did research in Asia and found drastic differences in the relationship between personal time and work time. They found North Americans and Europeans kept a strong delineation between work and personal time, but they found significant overlap between personal and work time among Asian customers. The data-driven nature of the product decisions payed dividends in both choosing the right features to work on and avoiding the wrong ones. They got the idea that they wanted to improve the ease of composing emails, but after looking at their instrumentation, they found that the average session length was 22 seconds. So instead they focused on consumption of emails over composition. iTunes link: https://itunes.apple.com/ca/podcast/188-listening-to-users-at-scale-is-product-management/id975284403?i=1000430581654&mt=2 Website link: https://www.thisisproductmanagement.com/episodes/listening-to-users-at-scale/ MATT KAPLAN ON BUILD BY DRIFT The Build by Drift podcast featured Matt Kaplan with host Maggie Crowley. Matt talked about how the book Creativity Inc. by Pixar founder Ed Catmull inspired him to see the similarities between creating products and telling stories. He says that every great story has a protagonist (the target user), starts with tension (the problem the product is trying to solve), has an end state (the vision for solving the user’s problem), has a core belief (the product differentiators), and consists of a sequence of events to get to that end state (the work we need to do to get the users from the tension to the end state). Maggie asked what the benefits are of thinking about products in this way and he explained that product management is about solving problems and telling stories. Stories could be used to convince salespeople that you’re doing the right thing, to tell engineers about what they’re going to build, or to tell customers about what your team has built. iTunes link: https://itunes.apple.com/ca/podcast/build-19-how-great-products-are-like-great-stories/id1445050691?i=1000430866513&mt=2 Website link: https://www.youtube.com/watch?v=swz0TnLwbrA&list=PL_sQbSaZtRqCn6JJSkjma79c8c4bLdaJH&index=4&t=0s FEEDBACK Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/channel/UCysPayr8nXwJJ8-hqnzMFjw Website:
In this episode of The Rabbit Hole we are unpacking the The Seven Wastes of Software Development! Dave and Michael break down the seven points as they appear in the book Implementing Lean Software Development by Mary and Tom Poppendieck and chat about their experience and thoughts on each.
Episode 26 of the Modern Agile Show features an interview with Mary and Tom Poppendieck, co-authors of numerous excellent books, including Lean Software Development, Leading Lean Software Development and The Lean Mindset. Mary gave a wonderful keynote at the Scandinavian Agile conference (2018) called Proxies and Permissions. In that talk, Mary pointed out that she and Tom believe that “people ought to be able to figure things out for themselves” rather than being fed recipes. In Mary's talk she highlighted Bret Victor's (@worrydream) Designer's Principle (from his talk, Inventing on Principle: https://www.youtube.com/watch?v=EGqwX...) that “creators need an immediate connection with what they create.” Mary describes how important it is for people on agile teams to be "autonomous and asynchronous”, to get feedback rapidly from what they build instead of waiting a long time to see the impact of what you do. This is especially true if you are running experiments. Mary and Tom discuss a variety of “proxies” that stand in the way of fast feedback and autonomy. Mary explains how “speed and safety” go hand in hand. Mary believes that many agile scaling approaches are “a crutch” for organizations that have tight dependencies between people and architecture issues that require lots of people to talk, rather than being able to work autonomously, as they do at Amazon. Mary and Tom discuss how they see the four Modern Agile principles and how they relate to their Lean work. Finally, Mary describes how teams need a “concept of leadership”, someone who works as part of the team and helps teach the team how to work well, solve problems and learn.
It's Episode 9 of the Troubleshooting Agile podcast! This week we're discussing Agile Principle 7: "Working software is the primary measure of progress." Some of the topics we cover are: -The importance of "moving past the 'phase model' or the 'percent-of-budget model'" in measuring progress. -How Burn-Up/Down Charts simplify and optimise the process of measuring progress by assigning value only to that which provides value to the customer. -And how they also build trust between the business and software development sides of a company by delivering regularly. -The dangerous pitfall of taking Agile Principal 7 too literally and finding yourself toiling away in a Feature Factory. -How to avoid this pitfall by motivating your team with Type Y Management - perhaps taking inspiration from Star Trek's Jean-Luc Picard - and focussing on Business Outcomes. -That an unexpected outcome of focussing on 'working software' is often less software. 'But the software you end with, you know works. And you know it matters.' ** LINKS: -The 12 Agile Principles - http://agilemanifesto.org/principles.html -An extract from Alistair Cockburn's brilliant Crystal Clear: A Human-Powered Methodology for Small Teams on Earned-Value and Burn-Charts - http://alistair.cockburn.us/Earned-value+and+burn+charts -Mary and Tom Poppendieck's brilliant book on Lean Software Development - https://www.amazon.co.uk/Lean-Software-Development-Agile-Toolkit/dp/0321150783 -John Cutler's blog on how to tell if you're working in a Feature Factory - https://hackernoon.com/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2 *** We'd love to hear any thoughts, ideas or feedback you have regarding the episode. You can email us, here: agile@troubleshootingagile.com Tweet us, here: twitter.com/TShootingAgile Or find our website, here: troubleshootingagile.com/ Also, here is a link to our iTunes: itunes.apple.com/gb/podcast/troub…d1327456890?mt=2 If you have a moment, please like, subscribe and share with your friends. We really appreciate it.
This week on The Guardian Podcast with Ryn Melberg, Ryn welcomes Mary and Tom Poppendieck. Mary and Tom are the authors of four different books on the concepts of Lean and Agile. Their website is here: www.poppendieck.com. To learn more about this and other podcasts go to www.rynmelberg.com.
Craig catches up with two luminaries in the Agile and Lean space, Mary and Tom Poppendieck at YOW! Conference to talk about agile, lean, rapid feedback, culture and leadership. The discussion points include: Making the link between lean and software development and discovering that waterfall makes no sense The origins of the first book: Lean Software Development: An … Continue reading →
Muy buenas a todos! Estoy muy contento de retomar Game Stuff, el podcast donde entrevisto a profesionales del sector de los videojuegos. Para el episodio número 5 tengo el placer de contar con la presencia de Pablo Domingo, Agile Coach y Scrum Master de King. Pablo es un profesional con una carrera de más de 13 años en el mundo de las metodologías ágiles, en la entrevista de hoy vamos a tener la oportunidad de conocer de primera mano cómo se organizan los equipos en empresas que intentan estar a la vanguardia en la gestión de equipos y el desarrollo de software. Además Pablo nos da muchísimo contenido útil para todos aquello interesados en las metodologías ágiles, si te interesa conocer más sobre ésta manera de desarrollar software no puedes perderte éste episodio. Si al escuchar el podcast os surge alguna duda podéis usar los comentarios para exponerla y Pablo estará encantado de resolverla. EN ÉSTE EPISODIO APRENDERÁS: Qué son las metodología ágiles y que cambio implican respecto al desarrollo de software tradicional Cómo se organizan los equipos en empresas punteras de software Cuáles son las mayores dificultades al implementar las metodologías ágiles Cómo mejorar el flujo de trabajo de los equipos. Cuáles son los referentes en metodologías ágiles en la actualidad Puedes escucharlo aquí. LINKS Y RECURSOS DE LOS QUE HABLAMOS EN EL EPISODIO: (INCLUYE BIBLIOGRAFÍA RECOMENDADA POR PABLO DOMINGO) LEAN Y KANBAN Kanban: Successful Evolutionary Change for Your Technology Business de David J.Anderson Lean Software Development: An Agile Toolkit de Tom Poppendieck y Marie Poppendieck AGILE Agile Kaizen: Managing Continuous Improvement Far Beyond Retrospectives de Ángel Medenilla Management 3.0: Leading Agile Developers, Developing Agile Leaders de Jurgen Appelo Essential Scrum: A Practical Guide to the Most Popular Agile Process de Kenneth S. Rubin COACHING Co-Active Coaching: Changing Business, Transforming Lives de Henry Kimsey-House DESARROLLO DE SOFTWARE Agile Software Development, Principles, Patterns, and Practices de Robert C. Martín Refactoring: Improving the Design of Existing Code de Martín Fowler MOB PROGRAMMING http://mobprogramming.org/ An experience of its author PABLO DOMINGO @pavleras https://www.linkedin.com/pub/pablo-domingo/22/939/5b3 becomeagile.wordpress.com GRACIAS POR ESCUCHAR! Muchas gracias por unirte a Game Stuff y escuchar el episodio, si quieres dejar feedback estaré encantado de responderte en la sección de comentarios de más abajo. Además si te ha gustado el episodio sería increíble si lo compartieras en redes sociales mediante los botones del lateral de la página. También puede dejar una reseña en Itunes y me ayudarás a llegar a más personas y seguir generando contenido de utilidad para la comunidad. Puedes suscribirte al podcast en Itunes o en Ivoox para recibir automáticamente los nuevos podcast sin preocuparte de nada. No olvides que puedes seguirme en @danielgguillen o en Facebook! Y por último agradecer a @pavleras su asistencia al podcast, hasta la próxima!
John and Damon talk to Mary and Tom Poppendieck about their groundbreaking work translating Lean product development principles to software development, "The Seven Deadly Sins", containers to reduce friction, their best-selling books, and what keeps them from actually retiring. Show notes at http://devopscafe.org
We discuss "Waterwheel", Agile, Lean, and Rewrites. Waterwheel Methodology — Medium How to Manage the "7 Wastes" of Agile Software Development Interview: Mary and Tom Poppendieck on using Lean for Competitive Advantage Glen Mailer on Twitter: "Shiny new estimation cards. Did I buy enough? No idea. http://t.co/zglAIwvMIP" Lessons learned from the big rewrite The Big Rewrite - Chad Fowler Uncle Bob Martin on Twitter: "Is a major rewrite every justified? Usually not. But in this case… http://t.co/QaFIxPHa" The Big Redesign In The Sky Forward 2 Dead of Winter: A Crossroads Game
Agile Instructor - Coaching for Agile Methodologies such as Scrum and Kanban
I am thrilled to present a wonderful interview with Mary and Tom Poppendieck. They are true legends in the Agile and Lean Software Development movement. Checkout today's episode where we discuss challenges facing many organizations such as: product vs. project mindset, globally distributed teams, and equipping teams for success. We also discuss their latest book, The Lean Mindset. Please consider picking up the book to learn more about these topics in greater detail.Please check out their website: poppendieck.com to learn more about Mary & Tom and their insightful work. Many thanks to Mary and Tom for investing their time for this podcast and for their contribution to our industry.All Things Agile - Episode 005 - Mary and Tom Poppendieck 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 on iTunes, and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.Ronnie: Hello everyone and welcome to the All Things Agile Podcast, Episode 5. I’m very excited to present to you a wonderful interview with lead software legends Mary and Tom Poppendieck. Before I begin, a quick reminder that this podcast is for informational purposes only and accepts no legal liability. So let’s get started!One of the goals for this podcast is to interview and feature influential leaders in the Agile space. Today’s guests are just that – Mary and Tom pioneered the Lean Software development movement, with their groundbreaking book Lean Software Development and Agile Toolkit. It’s a classic among Agile literature. In 2013 they also released ‘The Lean Mindset – Ask the Right Questions’. Mary and Tom travel the globe, speaking at conferences and consulting with many of the world’s top companies. It’s an honor and a pleasure to have them on the All Things Agile Podcast. Without further ado, let’s welcome Mary and Tom!Well, thank you for joining me today Mary and Tom, I really appreciate it. Why don’t we go ahead and get started with a few questions. During my own career, I have worked at several Fortune 500 companies. And I’ve often found that large organizations tend to be project-focused, rather than product focused. For example, I have seen environments where software development is treated as a black box, and it can sometimes have a throw-it-over-the-fence mentality. I would love to hear your thoughts on integrating software development as part as a holistic product chain.Mary: If you look back to the early 90’s, I was a manager in the early 90’s and there were very few of my colleagues that could even type. Typing wasn’t something that you learned, unless you were going to be a secretary. The idea of doing email and stuff was so difficult that when the internet first came, many managers sat down their secretaries to do their email typing. Eventually that went away. But if you look at industries that were formed before technology was widespread, like banks and insurance companies and those kinds of industries, you’ll find that this technology area was separated out from the mainstream for two reasons: one reason is because the managers of the line businesses simply were not comfortable with technology; and another was that computer technology was considered something that was expensive and should be centralized in order to reduce costs.Well, today, computer technology is not the same. It is the fundamental basis for competition for almost every company that uses it. Thanks to the kinds of products that they offer, or the things that help them be competitive – if you take a look at the new companies like Google and Facebook and Amazon and those companies, computer technology is a fundamental competitive advantage. And if that’s true, then it needs to be manage, at least what’s done, in the line organization, rather than in some side-organization that is in side to the line organization. So if you look at the companies I’ve just mentioned, they don’t have a central IT department. They have the line organizations responsible. That doesn’t mean that they don’t think about IT costs, but they think about them as product development costs.So now, the things that people develop that are helping the company become more competitive and distinguish it from other companies, are things that need to happen with people who sit in the line organization and truly understand customers and are close to them and secondly, software technology today is much more thought of not as a black box, but as a constant feedback mechanism. So you do something, you see the results on customers and on the line business, you adapt to the results and you continue on.With those two things said, first of all it provides the competitive or strategic advantage to be thinking in line organization about technology. And secondly, technology is by and large best developed as a short feedback loop kind of a business; it makes very little sense to continue on with this black box concept that used to be a sensible idea. Tom, you have something to say?Tom: Yes, definitely. I’d like to address this from a little more abstract level and put projects in their proper place. The motivating aspects as identified by Simon Sinek is ‘always a purpose’, a reason for doing things, a difference that an organization is attempting to make in the world. It’s the reason why people come to work, why they think about a problem, why they devote a lot of energy to solving a problem. Now, ‘Why?’ is primary – nothing great happens without a great ‘Why?’ ‘How?’ is where the project sits; it’s one of the techniques for containing risk, for containing how much resources you’re going to devote to achieving your ‘Why?’. Agile is another collection of techniques that are ‘How?’s – ways of working strategies, tools.Engineering disciplines are another set of ‘How?’s. Automated testing and many others. But they’re all ways of working, ways of thinking to achieve a purpose. And neither of those are your product. Your product is ‘What?’ that’s Simon’s third level. Why, How and What? Now, whether you are successful is not so much a matter of did you sail this in the constraints, that your project imposes? It is ‘did you do the very best that you could in terms of achieving your purpose within the constraints of your available tools and skills, and risk management strategies?’I read a fascinating article in Harvard’s Business Review yesterday. And it was saying that the most important, the most powerful way of managing risk is to measure and analyze time to recover the something going wrong in any individual component of what you’re doing. This translates easily at least in my initial impression, into how fast is your feedback loop?If you try and do a ‘What?’ that doesn’t really contribute to achieving the purpose and find out about it until very much after it has been done, and after many things have been built on top of it, you have wasted all of the good skills, all of the good techniques and you have triggered away your ‘Why?’ But if you find out about it very quickly, and you haven’t placed practices and approaches that you can recover very quickly, then you have the very best that you can; you’ve delivered the best ‘What?’ that you can using your constraints to achieve your purpose. And I think that’s the framework for thinking about projects – it’s just a tool; they’re not the ‘What?’, they are not the ‘Why?’ – they’re just a way of containing risk. Ronnie: Right, that makes sense. I agree. Sometimes, people place more emphasis, if you will, on the success of the project rather than the success of the product. And for the customers, I agree. Excellent answers. The next question I was wanting to ask, kind in a similar note, I also worked on projects where everything was kind of guided by arbitrary dates if you will. And sometimes, the end customer and the product features were really not in focus. Have you seen this behavior before and if so, what advice do you have for our listeners on how to tackle this issue?Mary: Well, it’s interesting where the arbitrary dates come from, because I think that a business organization wants them to help them move forward with customers. They have some frame in mind about how much it’s worth to them to do that, how much money they can spend and what kind of deadlines are important, and those deadlines and those budget constraints should be honored as far as what are our constraints for meeting our overall objective? But then those get translated into somebody’s version of minor objectives and minor deadlines and if we don’t do this by this time, we can’t get to there by that time. Then those become completely arbitrary and basically unattached to the overall purpose. And those kinds of deadlines that are fake, are pretty easy to detect and what is the reason for them? That’s what you got to ask. Why do we have these strange deadlines? Why don’t we have, instead, a very tight feedback loop and a visibility of the progress we’re making towards the overall objective of what we’re trying to do and understand what part of the progress needs to happen at different times.Now, if the way that you do a project is you first do all of the design and then you do all of the next step and it isn’t until the end that you actually do the work, write the code, write the test, integrate the software, then those days are truly artificial. But if you strategy is to say ‘I am going to have a complete system in two months – it’s going to be a minimal system, but it will be workable and we can get feedback on it – and that two months is going to give us another 8 months to finish the whole thing and the feedback necessary to do that’ – that’s a much more viable deadline. So you have to say are the high level constraints appropriately applied as low-level constraints to get stuff done or are they artificial? Because if they’re artificial, smart people can figure that out and they will ignore them. Tom?Tom: Not all deadlines are arbitrary. Some are legal, some are annual rhythms of shows. There are some very legitimate deadlines. And a competent team with a competent manager that understands what it takes to do work will be able to achieve a real deadline. However, if a deadline is used as motivation, as a goad, as a way of avoiding waste, then it can be very ineffective and very destructive. It can lead to bad behavior. The use of a deadline that is not legitimate, that is not related to the ‘Why?’, to the work being done, is probably a symptom of lack of competence to measure what really matters about the progress of the work.Mary: I want to throw in one last little thing here, and that is that projects should have things called: cost, schedule and scope. And the thing that really should be flexible is neither, in most business’ cases cost, nor schedule. The thing that should be flexible is scope, because cost and schedule deadlines are typically driven by business constraints. But the scope should be the thing that is negotiable almost always and the reason for that is that, especially in a software environment, the thing that we’re putting together is a complex system. The more junk, features, capabilities or whatever that we throw into that massive software, the more complex it is, the more difficult it is and by and large, over time, the more stuff you have in software, the more crud you get in there, the more complexity you get in there, the harder it is to change, to manage and so on.So in software, you want to think of ‘stuff’ as bad. You don’t want to measure a team on how much junk can I put in, in a window of time? You want to say: How much business purpose can I achieve within as little code as possible? So you are looking for reduced feature set, reduced capabilities that get the job done. And so the thing you really want to reduce is not the budget or the schedule; it’s the amount of stuff that you try to squeeze into a business-driven budget and schedule. So typically in all projects – and this is not the way most project managers look at it – but a software project almost always bend on scope, rather than bend on deadline or on cost.Tom: It is impact. Did you achieve the impact that your work aimed to achieve? Did it achieve its purpose? If the impact can’t be measured, you have no guidance about what to include and what to leave out. You have no measure about when you’re done. If you have as much impact as your tools and skills and techniques permit, as the team was capable of and the project was a success…Ronnie: I definitely like that impact thing – that kind of really sums it up really well, thank you. If you don’t mind, I’ll ask the next questions which is: in my experience, I’ve seen senior exectutives get very excited about Agile and they decide to roll it out across the organization. However, sometimes the teams can be lacking in technical skills or tools to ensure success. For example, great Agile teams place a high value on quality and that usually will translate in frequent and rigorous testing. And if a team has, for example, automated tests in place that will result in the product being in good shape. However, there may be teams which have never worked, for example, with test automation and it can then be a real challenge. What are your thoughts regarding skills and technical preparation in relation to methodology adoption?Mary: Methodology is the result – it’s not the driving factor in a good Agile implementation. What you’re trying to do is create an environment with rapid feedback, so that you can do a better job of satisfying customers. And you should not be measuring ‘did I do this or that Agile practice’? You should be measuring ‘do I have greater impact in delivering what my customers really want?’ And that’s where you get to the quality, the test automation and that sort of thing.So let’s talk about a different objective for that executive, so that the executive have stuff that they can measure and put hands around. And that is, instead of working about a methodology called Agile, why not worry about what I’m going to call ‘The Software Development Process of the Future’ which is continuous delivery. So instead of saying that we have these meetings and we have these things, you should be saying ‘How fast, from the time I decide to do something, until the time I get it in production – how long does that take?’ And when you start looking at how far along am I on the path to continuous delivery - that is my executive goal. Those companies that do that have far more effective Agile implementations because it’s that one thing that you’re focusing on that continues delivery, that drives all the good technical behavior by the way of good practice behavior.Let me give you an example in Alcoa – once upon a time when he became CEO, decided that he wanted to focus on one single thing and it was going to be safety. And every single issue around any kind of safety incident was what the entire company focused on. And that became a lever to cause all kinds of additional good behavior and the company really took off, because you can’t have safety without quality, alert workers, really good, well-run equipment, all of that sorts of things. And similarly in Lean, the concept of flow is sort of that driving principle. So you try and just focus on flow, everything falls in place. All the technical things, all the quality things and so on. Similarly in software. Let’s not focus on process; let’s focus on continuous delivery. How far are we towards being able to deploy immediately? And if we make that the one principle of how we perceive, then what we have is a driving principle that will drive all the rest of the good behavior and certainly, all of the technical behavior.Ronnie: Excellent answer. A final question, if you will. There are many great sources of information on implementing Agile, but most are geared towards smaller organizations often. And for larger companies, it can be a hurdle if you will to implement new methodologies in a global workforce. For example, I’ve recently worked with teams that are split across India, Brazil, China, Mexico and of course here in the US. What insight can you provide on how to tackle teams that are globally distributed?Mary: There certainly are many big companies – we wrote in our new book about Ericson as an example – very large companies that are very effective in implementing Lean and Agile concepts. But they don’t hold a lot of stake in having ‘teams’ that are geographically distributed. Yes, organizations are geographically distributed – but why do teams need to be? So what I see large, effective organizations do when they think about distribution is to say what are the things that need to be communicated? And how can we effectively, at a single site, have communication among colleagues and think about communication across teams on a different scale? So the effective ones don’t try too hard to make individuals have to communicate across large distances. And if they do, they have people travel.However, there can definitely be reasons why people should – and really valid purpose-drive, business-driven reasons why people need to communicate across geographic boundaries. And there certainly are plenty of examples on how this is done effectively. If you look at the open source movement, none of the open source projects have people co-located. These ones work very well with the communications issues across countries and if you look at them for models on how to do it. So if teams do need to be distributed, then you want to think ‘Why?’ Okay? You do not want to have class A people figure out what to do and class B people are in another continent that actually implement it, because that gets us back to the first question. The people that are doing the implementation are divorced from the purpose. But if the teams are geographically distributed, you have to think hard about how can they all share a common purpose that they understand and believe in and commit to, and if they do that the communication issues will be solved. And if you can’t imagine teams across countries dedicated to a common purpose, then you should say: Why are our teams structured this way? So every company that has solved this problem, has solved it in a different way, depending upon their market and their structure and all of that sorts of things. But they do have a few things in common. One is, they think for themselves. They don’t take rule books. They try to make sure they honor the intelligence of every person on the team and make sure that they can participate fully their thoughts in thinking about it, and they don’t have these wall handover mechanisms because that’s not the right way to deal with this. Tom: All the teams we have seen around the world, and we’ve seen many, have one shared characteristic. And it’s not tools or techniques or methodologies – it’s they think for themselves. There are many examples, case studies about groups that have thought about their problem and their context and their challenges and they think for themselves and come up with a unique combination of tools and techniques and disciplines that make them highly effective in achieving their purpose. A team which is distributed and is simply doing what it’s told to do is not going to be very effective. A team which is distributed for a good reason who all believe in a purpose that they are trying to achieve and have adequate tools, handles and the like, that make it possible to communicate effectively, will figure out how to do it. They will think for themselves, if they have sufficient feedback about how they are doing, how things are working for them; they will figure out how to do it. And there are many, many ways that different teams figure out how to do this. But it’s not a recipe. It’s not a product that you buy; it’s how people think about what they are doing together. If they can’t think together, they can’t be very effective at working together. They can’t learn together. The product will reflect that lack of learning.Ronnie: I definitely agree. I definitely agree with you that having those teams be able to really understand it and what they’re trying to achieve and have those goals and have that thought in control is very key – it’s as you mentioned, if you kind of have a class A, class B type situation, then it can often result in micromanaging and diminish morale and sometimes poor quality – I’ve seen in the past the results in code. Great points, great points! And a lot of them are actually referencing some of your more recent work – if you don’t mind, I’d love to mention that briefly. You guys have put together a great book last year ‘The Lean Mindset’. Would you like to maybe highlight that a little bit more?Mary: Sure! I was just reading in an article that it used to be ‘share all their value’ was the thing that businesses thought they were in business for. But today, in today’s economy and today’s high-tech environment, what you really want to do in order to have a successful business is you need to have great people that use their minds for accomplishing the common purpose. And that purpose has to be something that these people believe in and you need to have an intense focus on delighting customers. And those three things: customers that you’re trying to delight, employees that are deeply engaged at trying to make something happen for those customers and an overriding purpose are the three sort of company drivers of the future.Our book has 5 chapters. One is on purpose and then the next one is on engaged workers and energized workers; the third one is about delighted customers. And then we talk about efficiency and what efficiency means in this context. Efficiency means, in the Lean context, flow efficiency rather than resource efficiency. Which is a whole other topic that we can talk about sometime. And lastly, we talked about innovation because today’s economy, today’s technology moves too fast to be comfortable that what worked 3 years ago is going to work 3 years from now, so constant innovation is another thing that companies need to have. That’s sort of, in a nutshell, what the book is about, those 5 chapters. And to sum it all up we have lots of case studies in there, as Tom said, and each case study shows how thinking for yourself in your context is important; which means it’s important to have people who care to think for themselves and who are allowed to think for themselves and who are inspired to help make the company successful. Ronnie: Excellent! I definitely encourage our listeners to pick up a copy of your latest book. Once again, it’s ‘The Lean Mindset’ and it’s available at book stores everywhere. I picked up my copy on Amazon, and I really just want to thank you both Mary and Tom for joining me today for this podcast episode. It’s been tremendous help to myself and I’m sure, to all of our listeners. I really thank you so much for your time Mary and Tom, you’ve been great! Thank you 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!
Agile Instructor - Coaching for Agile Methodologies such as Scrum and Kanban
Today's episode is centered around some exciting news. I am launching a new venture, Team Xcelerator Inc., which will focus on Agile team software. The AgileInstructor.com blog and the All Things Agile podcast will be moved under the Team Xcelerator umbrella. I am very excited about the possibilities. Please checkout the podcast and send me your thoughts and product feature input using coach@agileinstructor.com. Also, don't forget to please post a kind review in iTunes. We really appreciate your time and support :)All Things Agile - Episode 4 - A New HopeTranscript: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.Hello everyone and welcome to the All Things Agile Podcast, Episode 4. Today’s title is ‘A New Hope’. This is paying homage to the classic Star Wars title, but before we begin, a quick reminder that this podcast is for informational purposes only and accepts no legal liability. So let’s get started.As an Agile coach, I’m frequently searching for tools to help myself and others utilize Agile methodology successfully. Candidly, I haven’t found many tools which truly reflect the needs that I have seen over the years. Rather than let this frustration remain, I decided to start a new company: Team Xcelerator Inc. to tackle common challenges for Agile teams. You have undoubtedly heard references to Team Xcelerator a few times already. I want to take a few moments to talk about it in more detail. Everything is still very early stages, but I’m hopeful that many Agile practitioners will come to love it. A goal of mine is to develop a product which reflects the global nature of today’s workforce. Almost all development teams are now spread across the world and this trend is only continuing to rise. The use of Agile itself is also on the rise. However, many organizations are still struggling with learning and how to adapt Agile, including the fact that teams or departments may implement Agile differently.Many of the products that I’ve seen on the market are really just project management tools. We still have a lot of work remaining, but it is a goal of mine to develop Team Xcelerator into a cloud-based web tool which will enable teams to specifically focus on Agile success. I also intend for Team Xcelerator to be affordable. I want to encourage teams to utilize the tool and achieve success. It will be targeting organizations of all different sizes, including young startups to industry veterans. I can’t release too many specifics at this time, but I did want to take a moment and let my audience have advance notice of this new platform. I’m also interested in your input to ensure that it better conforms to your needs. As the episode title alludes to, it is a new hope for me and for the world of Agile; an opportunity to create a platform for Agile professionals, by Agile professionals. And I hope that you’re excited about this recent product news as I am – and remember: you can check out my blog using the website agileinstructor.com and feel free to contact me using coach@agileinstructor.com and feel free to include product comments that you may have regarding Agile tools. I would love to be able to take in your input and ensure that we have product features that will truly meet the needs of our audience.Also, don’t forget to visit our previously discussed sponsor: TeamXcelerator.com which makes this podcast possible. And thank you once again for joining me for this quick podcast – join me for Episode 5, we’re having an exciting interview with Mary and Tom Poppendieck who are the innovators of Lean Software. You don’t want to miss it! Remember – it’s time to accelerate your team, today! 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!
Here's the second part of our interview with Tom and Mary Poppendieck. The links for this episode are included with the show notes for part 1. This podcast is in English - Deze podcast is in het Engels
In this episode we interview Mary and Tom Poppendieck, authors of that great trilogy of books on Lean Software Development. Because of the lenght of the interview we decided to publish it in two parts, with the second half expected to be published in a week or so. In this first part we talk with Tom and Mary about Lean principles and how they apply to software development. We speak about Toyota, about innovation and startups, and Tom and Mary explain what is meant with set-based design. This interview was recorded in an Amsterdam hotel lobby on the 26th of September 2010. Interview by @freekl and @mamersfo. Audio post-production by @Mendelt. Links for this podcast: Lean Software Development: An Agile Toolkit (Mary and Tom Poppendieck) Published May 18, 2003 by Addison-Wesley Professional Implementing Lean Software Development: From Concept to Cash (Mary and Tom Poppendieck) Published September 17, 2006 by Addison-Wesley Professional Leading Lean Software Development: Results Are not the Point (Mary and Tom Poppendieck) First edition published October 31, 2009 by Addison-Wesley Professional Lean Thinking: Banish Waste and Create Wealth in Your Corporation (James P. Womack and Daniel T. Jones) Second edition published June 10, 2003 by Free Press Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Result (Mike Rother) Published August 4, 2009 by McGraw-Hill Switch: How to Change Things When Change Is Hard (Chip and Dan Heath) Published February 16, 2010 by Random House Canada Cracking the Code of Effective Innovation: Organizational Size and Style Is Driving Innovation success Published June 2007 by Future Think LLC Toyota’s Principles of Set-Based Concurrent Engineering (Durward K. Sobek II, Allen C. Ward and Jeffrey K. Liker) Published January 15, 1999 in MIT Sloan Management Review Survive to Make Money or Make Money to Survive? (John Shook) Published December 4, 2008 by Lean Enterprise Institute Drive: The Surprising Truth About What Motivates Us (Daniel H. Pink) Published December 29, 2009 by Riverhead Hardcover Hidden Value: How Great Companies Achieve Extraordinary Results with Ordinary People (Charles A. O'Reilly III and Jeffrey Pfeffer) Published August 2000 by Harvard Business Press Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management (Jeffrey Pfeffer and Robert I. Sutton) Published Marc 1, 2006 by Harvard Business Press Toyota’s Journey From Waterfall To Lean Software Development (Henrik Kniberg) Published 16 March, 2010 on Henrik Knibergs' blog The Team Handbook (Scholtes, Joiner & Streibel) Published march 24, 2003, by Joiner/Oriel Inc This podcast is in English - Deze podcast is in het Engels
Welcome to the Software Process and Measurement Cast 76!In the SPaMCAST 76 I interviewed Tom and Mary Poppendieck talking about lean and their new book "Leading Lean Software Development: Results Are not the Point". Our interview covered the book, lean and leadership to just a few topics.Mary Poppendieck has been in the Information Technology industry for over thirty years. She has managed software development, supply chain management, manufacturing operations, and new product development. She spearheaded the implementation of a Just-in-Time system in a 3M video tape manufacturing plant and led new product development teams, commercializing products ranging from digital controllers to 3M Light Fiber™. Mary is a popular writer and speaker, and coauthor of the book Lean Software Development, which was awarded the Software Development Productivity Award in 2004. A sequel, Implementing Lean Software Development, was published in 2006. A third book, Leading Lean Software Development, was published in late 2009.Tom Poppendieck has over 25 years of experience in computing including eight years of work with object technology. His modeling and mentoring skills are rooted in his experience as a physics professor. His early work was in IT infrastructure, product development, and manufacturing support, and evolved to consulting project assignments in healthcare, logistics, mortgage banking, and travel services.Tom holds a PhD in Physics and has taught physics for ten years. He is coauthor of the book Lean Software Development, which was awarded the Software Development Productivity Award in 2004. A sequel, Implementing Lean Software Development, was published in 2006. A third book, Leading Lean Software Development, was published in late 2009.Website: http://www.poppendieck.com/Leading Lean Software Development: Results Are not the Point http://www.amazon.com/exec/obidos/ASIN/0321620704/poppendieckco-20Contact Mary:Phone: 952-934-7998Email: mary@poppendieck.com Contact Tom:Phone: 612-804-7217Email: tom@poppendieck.com The essay in SPaMCAST 76 is titled "Walls". In the essay, "Walls" I explore the impact of living in an echo chamber when it comes to the ideas and concpets you use to drive change.Conferences and Speaking Engagements in 2010 (To Date)Are Your Project Stakeholders Satisfied February 11, 2010 11:00 am - 12:30 pm Eastern Time Measuring customer satisfaction is more than just asking if your clients got what they wanted. Customer satisfaction is a messy mix of expectations, experiences, and perceptions - with maybe a hint of functionality. In this webinar, Tom Cagley will outline one method for measuring this mixture and for identifying what really matters in customer satisfaction.Learning Objectives: • How to define customer satisfaction • Strategies for identifying what really matters • A practical framework for measuring customer satisfaction • Not all attributes of customer satisfaction matter to the same level for all stakeholders Register at http://solutions.compaid.com/forms/WebinarA20100211?ProcessType=PreRegQuest Conference in Dallas April 21 - 23. I will be talking on "Process Improvement in a Multi-Model World". The conference includes two days of workshops. The website to get more information is http://www.qaiquest.org/dallas/index.htmlNext!The next Software Process and Measurement Cast will feature an interview with . . . Me. Pat Ferdinandi turns the tables to explore the origins of the SPaMCAST and plans for the future. I had fun being interviewed and hope you will enjoy the disucssion.
© 2020-2025 Ivy Podcast Discovery LLC
