Solving Problems Safely with Mary and Tom Poppendieck

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/