Scrum Master Toolbox Podcast: Agile storytelling from the trenches

BONUS: The Chip Race Behind AI With Rakesh Kumar
AI feels like a software revolution, but Rakesh Kumar argues that the next limits may come from chips, energy, and the physical systems underneath our code. In this BONUS episode, Rakesh explains why AI progress is tied to hardware, what software teams need to relearn about efficiency, and why the economics of data centers should matter to product leaders.
Why Chips Became a Society Topic
"The race about AI essentially becomes the race about chips."
 
Rakesh traces his path from a small town in India to computer science, chip research, entrepreneurship, and eventually writing The Chip Age. The turning point came during the COVID-era chip shortages, when cars, appliances, and everyday electronics became harder to buy. That moment made chips visible to people outside engineering. AI then raised the stakes further: the promise of new medicines, new materials, and major productivity gains depends on models that require enormous amounts of computation. For software people, that means chips are no longer background infrastructure. They are part of the product strategy, the cost model, and the operating constraint.
AI Progress Depends on Computation
"To the first order, the more chips you can use and the more data you throw in at training AI models, the more powerful an AI model becomes."
 
Vasco frames the shift with a sharp comparison: AlexNet used two GPUs in 2012, while newer frontier models use tens or hundreds of thousands of GPUs. Rakesh connects that growth to AI scaling laws. The problems AI is asked to solve have changed, from recognizing cats and dogs to scientific discovery and complex reasoning tasks. That creates pressure to train larger models with more data and more chips. The result is a world where software teams cannot assume that compute is cheap, abundant, or invisible. AI roadmaps are now connected to chip availability, data center capacity, energy, and the ability to use hardware well.
Software Teams Need to Care About Efficiency Again
"Software developers now have to refocus on performance, because that dictates the quality of AI you can serve and the cost of AI when you're serving AI."
 
For years, software teams could often rely on hardware getting faster underneath them. Rakesh says AI changes that habit. If two teams have access to the same number of chips, the team that extracts more useful work from those chips has an advantage. That advantage shows up in model quality, inference cost, latency, and energy consumption. Efficiency is no longer a niche concern for low-level specialists. It becomes a product concern. Teams building with AI need to understand where computation goes, how much energy it consumes, and which architectural choices make expensive infrastructure work harder than it needs to.
The Hardware and Software Boundary Is Moving
"Because of AI, the hardware design and the software design at some level, those abstractions have started merging."
 
Rakesh points to new AI-assisted chip design workflows, including the Jalapeno chip example Vasco mentions, as a sign that software and hardware work are moving closer together. Chip design that once took years can now be accelerated with AI-supported automation and specialized partners. At the same time, hardware choices are becoming more tailored to AI workloads. General-purpose chips offer flexibility, but specialized chips may offer much better efficiency. That creates a trade-off familiar to software leaders: optimize too narrowly and the target may move; stay too general and the system may be too costly to run.
The Data Center Constraint
"I think we have to figure out how to do AI efficiently. The current way of doing AI seems pretty unsustainable to me."
 
Rakesh warns that AI data centers are running into physical constraints. Large facilities can consume gigawatts of power, and a significant share of that power is used to move heat out of the system. There are also inefficiencies in generation, transmission, distribution, cooling, and in the short useful life of expensive GPUs when model requirements change quickly. For agile teams and product leaders, this matters because energy and infrastructure are becoming part of the real cost of AI features. The question is not only whether an AI feature works. It is whether it can be served responsibly, affordably, and at scale.
What Breaks First in the AI Supply Chain?
"The capacity of the grid grows really slowly. We have this slowly increasing supply now hitting against the AI exponential."
 
When Vasco asks what may break first if AI demand keeps rising, Rakesh ranks energy supply as the biggest challenge. New transmission lines and grid connections can take years, while AI demand grows much faster. Chip supply comes next: can the industry build enough chips fast enough? Cost is also a pressure point, especially for smaller companies, developing countries, and individual consumers. Rakesh also flags a broader economic risk: data centers can cost billions, and some financing is backed by older chips as collateral. If the economics fail, the impact may reach beyond individual AI companies.
What Software Developers Should Prepare For
"Generating functional code will be a lot easier in future than generating functional code that meets your performance and energy objectives and constraints."
 
Rakesh argues that every software engineer needs to become fluent with AI, but that is only the starting point. The valuable work may shift toward areas where AI still struggles: physical AI, robotics, IoT, sensors, performance, energy, and verification. If AI writes more code, teams still need ways to build confidence in that code. Vasco connects this to familiar engineering practices such as testing, performance testing, security testing, and maturation. The future may include much more software than today, but the scarce skill may be knowing how to make software trustworthy, efficient, and suitable for the physical systems it touches.
About Rakesh Kumar
Rakesh Kumar is a Professor and John Bardeen Faculty Scholar in Computer Engineering at Illinois and author of The Chip Age. He studies chips and computer systems, co-founded chip companies, advised companies and governments, and developed technologies now used in phones, tablets, and computers.
 
You can follow Rakesh Kumar's work on his University of Illinois webpage and read The Chip Age.

Marcin Klimaszewski: The Product Owner View of Great Scrum Masters in Agile Teams
In this episode, we refer to Design Thinking, Product Build Day, and The Mom Test by Rob Fitzpatrick.
The Great Product Owner: A Scrum Master Who Knows When to Step Into Product Work
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
 
"The skill of a great Scrum Master is being flexible with the role." - Marcin Klimaszewski
 
Because this is a Product Owner week, Marcin closes the week by describing what great Scrum Masters look like from the product side. The key word is flexibility. A great Scrum Master protects team rhythm and alignment, but also understands when the team needs something outside the textbook process. Marcin shares the example of a product or epic kickoff where the Scrum Master worked with the Product Owner and Product Designer to create a useful workshop. The team did not only hear what was expected. They clarified assumptions, named missing data, discussed whether discovery was needed, and identified risks early. That kind of kickoff can save weeks later because it gives the whole team a shared understanding of what they are trying to deliver and how they need to deliver it. For Product Owners, that Scrum Master is not a process guardian standing aside. They are a partner who notices when product clarity, team alignment, and delivery confidence need help.
 
Self-reflection Question: Where could you step in this week to help the team clarify product assumptions before sprint execution begins?
The Bad Product Owner: The Scrum Master Anti-Pattern of Staying Inside the Role Description
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
 
"Scrum Masters could go to someone else to get inspiration. This flexibility can come from different directions." - Marcin Klimaszewski
 
The anti-pattern in Marcin's story is the Scrum Master who treats the role description as a boundary instead of a starting point. Product work often contains uncertainty: outdated data, missing discovery, technical blockers, stakeholder tension, or unclear decisions. A Scrum Master does not need to be a product expert, designer, architect, or developer to help. They need to sense the tension and know how to inquire. Vasco gives a simple example: hear tension in a meeting, ask the architect for coffee, and learn what is really blocking the team. Marcin adds that Scrum Masters can learn from their own background and from other specialists, just as therapists use supervisors to think through difficult situations. The lesson for Scrum Masters is practical: flexibility is not improvising randomly. It is knowing when the process is not enough, asking better questions, and helping the team find the conversation that needs to happen.
 
Self-reflection Question: Are you using the Scrum Master role to create clarity, or to avoid stepping into unclear conversations?
 
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
 
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
 
Buy Now on Amazon
 
[The Scrum Master Toolbox Podcast Recommends]
 
About Marcin Klimaszewski
 
Marcin Klimaszewski runs Product Build Days. One day to validate a business idea. Teams build the app themselves with AI tools, use synthetic users to sort out the usability, and design the sharpest test they can run the next day with real users. For founders, PMs, designers and other non-coders. An idea that cannot survive one day is not worth a quarter.
 
You can link with Marcin Klimaszewski on LinkedIn.
 
You can also learn more at Product Build Day.

Marcin Klimaszewski: Product Owner Ownership That Gives Agile Teams Real Direction
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
 
"Ownership is one of the most important things, and knowing how to hold this ownership." - Marcin Klimaszewski
 
Marcin defines Product Owner success through ownership. The word is in the title, but in many organizations the role is not actually given the authority, clarity, or support needed to make decisions. A successful Product Owner protects the team from conflicting stakeholder pressure, becomes a reliable decision point, and gives the team a clear sense that product decisions will lead somewhere. Marcin shares a Product Build Day example where a founder entered the day with a clear statement: the prototypes and tests would inform real product direction, not become a fun internal exercise. That clarity changed the team's energy. People knew the work mattered, the decision would affect future sprints, and the Product Owner would own the result. Vasco connects this to Extreme Ownership by Jocko Willink: Product Owners cannot hide behind "someone told me so." They need to own the goal, the trade-offs, and the decisions that guide the team.
 
Self-reflection Question: Does your team know which product decisions are real decisions, and who owns them?
Featured Retrospective Format for the Week: Silent Notes, Clustering, and Dot Voting
Marcin's favorite retrospective format starts quietly. Everyone writes feedback on sticky notes, online or offline, often anonymously. The notes are then revealed, grouped into similar themes, named by the team, and voted on so the group can select the most important topic to address. The strength of this format is that it gives quieter people room to contribute, makes everyone read what others wrote, and reduces the chance that the loudest voice defines the whole conversation. Vasco adds a useful sanity check: after voting, ask whether anyone sees a better idea on the board that did not get selected. That small pause helps the team guard against groupthink. Marcin's tip: do not use any retrospective format too many times in a row. Change the format to create fresh thinking.
 
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
 
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
 
Buy Now on Amazon
 
[The Scrum Master Toolbox Podcast Recommends]
 
About Marcin Klimaszewski
 
Marcin Klimaszewski runs Product Build Days. One day to validate a business idea. Teams build the app themselves with AI tools, use synthetic users to sort out the usability, and design the sharpest test they can run the next day with real users. For founders, PMs, designers and other non-coders. An idea that cannot survive one day is not worth a quarter.
 
You can link with Marcin Klimaszewski on LinkedIn.

Marcin Klimaszewski: Product Owner Discovery When Agile Stakeholders Want Delivery First
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
 
"If I can ship everything by the weekend, what is worth shipping?" - Marcin Klimaszewski
 
Marcin's current challenge is one many Product Owners recognize immediately: convincing stakeholders to invest time and money in discovery. Everyone says they want to understand the customer, but when discovery becomes real work, the pressure returns to plans, backlogs, and delivery. Marcin points to the Double Diamond design process as a useful way to explain the work. The first diamond explores problems and decides which problem deserves attention. The second diamond explores solutions. Many companies rush into the second diamond and become feature factories. The backlog is already large, stakeholders already have promises, and discovery can feel like more uncertainty instead of progress. Marcin's experiment is to shrink discovery into something stakeholders can tolerate and teams can actually run: Product Build Day, a one-day workshop where people build AI-assisted prototypes, pitch options, and design the sharpest user test for the next day. The larger shift is clear: product development is a search problem, not just a delivery problem.
 
In this episode, we refer to Design Thinking's Double Diamond and Product Build Day.
 
Self-reflection Question: How much of your backlog exists because the team is avoiding the uncertainty of discovery?
 
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
 
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
 
Buy Now on Amazon
 
[The Scrum Master Toolbox Podcast Recommends]
 
About Marcin Klimaszewski
 
Marcin Klimaszewski runs Product Build Days. One day to validate a business idea. Teams build the app themselves with AI tools, use synthetic users to sort out the usability, and design the sharpest test they can run the next day with real users. For founders, PMs, designers and other non-coders. An idea that cannot survive one day is not worth a quarter.
 
You can link with Marcin Klimaszewski on LinkedIn.

Marcin Klimaszewski: The Product Owner Lesson From Agile Teams That Forget the User
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
 
"The user never wants to log in. That is never the goal of the user." - Marcin Klimaszewski
 
Marcin describes a pattern he has seen too often: teams speak about users as if the team already knows what users need. In one EdTech example, the obvious solution looked simple from the development side: students should log in. But in a classroom with twenty or thirty students and only forty-five minutes, login was not a neutral feature. A few forgotten passwords, a few typos, and the teacher suddenly became an administrator instead of a teacher. The Product Owner needed the team to see the real problem, not just the technically familiar solution. The eventual answer was simpler for the users: the teacher logged in and shared a code with the students. That gave the product enough identification without stealing classroom time. Marcin connects this to the Sam Walton reminder that the customer is the real boss. For Product Owners and Scrum Masters, the work is not to defend our preferred solution. The work is to keep asking what problem the user is trying to solve.
 
In this segment, we talk about EdTech and the Sam Walton idea that the customer can fire everyone by spending money somewhere else.
 
Self-reflection Question: Where is your team solving an internal business problem and calling it a user need?
Featured Book of the Week: The Mom Test by Rob Fitzpatrick
Marcin recommends The Mom Test by Rob Fitzpatrick because it helps product people and Scrum Masters ask better questions. The trap is familiar: we explain our idea, ask whether people like it, and receive polite opinions instead of useful evidence. Marcin points out that better discovery starts with people's real experiences, problems, and past behavior. He also recommends Sprint by Jake Knapp, a practical guide to design sprints and structured product discovery. Sprint helped him see workshops as sequenced decisions toward a larger goal, not ceremonies to follow blindly. The method is useful only when it helps the team learn, align, prototype, test, and decide.
 
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
 
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
 
Buy Now on Amazon
 
[The Scrum Master Toolbox Podcast Recommends]
 
About Marcin Klimaszewski
 
Marcin Klimaszewski runs Product Build Days. One day to validate a business idea. Teams build the app themselves with AI tools, use synthetic users to sort out the usability, and design the sharpest test they can run the next day with real users. For founders, PMs, designers and other non-coders. An idea that cannot survive one day is not worth a quarter.
 
You can link with Marcin Klimaszewski on LinkedIn.