Podcasts about in agile

In this episode of Building Better Developers with AI, Rob Broadhead and Michael Meloche tackle a challenge that many modern developers face: navigating multiple software methodologies. With insights shaped by both real-world experience and AI-generated suggestions, the discussion reveals how developers can stay effective when juggling Agile, Waterfall, DevOps, and hybrid workflows. Understanding Common Software Methodologies The episode begins with an overview of today's most widely used software methodologies: Agile, Scrum, Waterfall, Kanban, DevOps, and SAFe. Rob and Michael highlight that developers often switch between these within the same organization or even across concurrent projects, depending on client requirements, legacy constraints, or team structure. The result? A dynamic but complex work environment that demands both technical and mental agility. The Challenge of Switching Software Methodologies The core challenge is staying productive while adapting to different software methodologies across teams and projects. Developers face more than just a change in process—they often deal with different toolsets, coding standards, sprint cadences, and collaboration models. This constant context switching can drain mental resources. “It's like being bilingual,” Michael explains. “If you're not fluent in a method, switching is exhausting.” Even development tools play a role. Some developers separate projects by using different IDEs to help them mentally shift gears between methodologies. Clarifying ‘Done' in Software Methodologies Rob and Michael explore a common point of contention: the definition of “done.” In Agile, it often means feature-ready for review or feedback. In Waterfall, it usually means final and locked. “You'll start a war in a meeting just asking what ‘done' means,” Rob quips. Michael uses a cooking analogy to explain the importance of clear expectations: requirements are the recipe, code is the ingredients, and the finished product must match what was promised. Without agreement on what “done” means for each software methodology, delivery and testing become chaotic. Adapting to Different Software Methodologies To truly thrive, developers must move from a methodology purist to an adaptive mindset, focusing on the value being delivered rather than the rigidity of a particular framework. “Don't serve the methodology. Serve the customer,” Rob emphasizes. Michael reminds us to avoid getting lost in small details, like UI color tweaks, when more critical features remain incomplete. Staying aligned with the end goal ensures that effort translates into real progress, regardless of methodology. Documenting Within Software Methodologies In teams that use multiple software methodologies, documentation often becomes fragmented or overly complex. Rob and Michael both stress that great developers learn to write “just enough” documentation—and keep it in one place. Michael offers a best practice: let the codebase be the source of truth. Embedding JavaDocs, comments, or changelogs within the code ensures that updates stay consistent with the actual implementation. It reduces dependency on separate, often outdated documentation tools. “If your code and documentation don't match, one of them is lying,” Michael warns. Key Takeaways on Software Methodologies Understand core methodologies — Agile, Waterfall, DevOps, and hybrids Support healthy context switching — Use tools and routines that help you adapt Align on ‘done' — Define it clearly with your team Focus on outcomes — Avoid getting stuck in rigid process rules Document just enough — And keep it close to your code Be Adaptable, Stay Focused To succeed across software methodologies, developers must be flexible, clear, and focused on delivering value. Rather than being loyal to a single framework, the best developers understand the principles behind them all. They communicate effectively, manage context switches efficiently, and utilize smart documentation to keep projects aligned. When you serve the goal—not just the process—you become a truly adaptive developer. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Learn From CoWorkers: Interview with Douglas Squirrel Rock Bottom Can Be a Starting Line Invest In Your Team – They Will Want To Stay Building Better Developers With AI – With Bonus Content

Agile in Hardware: The Future of Agile Hardware Development, A Case Study From High Power Semiconductor Industry With Milad Maleki and Markus Thut In this Agile in Hardware episode, Milad Maleki and Markus Thut of Hitachi Energy Ltd. describe the pioneering methods and challenges of Agile hardware development in high-power semiconductor manufacturing. From introducing cutting-edge RoadPak technology for Formula E racing to optimizing consumer EV solutions, they share a fresh perspective on agile practices beyond the traditional software domain. Join us as we uncover the intricacies of an iterative approach to hardware design, production integration, and actionable insights for advancing Agile principles in complex hardware manufacturing. The RoadPak Project: Pioneering eMobility Innovation Milad and Markus kick off the discussion with the story behind the RoadPak project, a powerful technology supporting electric mobility and racing industries, including Formula E and Formula 1. Developed initially as a small-scale prototype, RoadPak has since evolved into a versatile solution with wide-reaching applications in consumer electric vehicles and fast-charging stations. “From racing to consumer EVs, RoadPak's journey showcases the transformative potential of scaling innovation from concept to consumer solutions.” Redefining Agile in Hardware: An Iterative Revolution Unlike traditional hardware development's linear approach, the team adopted an Agile model to adapt and evolve both the product and its manufacturing processes at the same time. By designing the production line in tandem with the product, they created a collaborative environment where feedback directly informed product design and production line adjustments. “In Agile hardware, the manufacturing process becomes part of the product itself—a continual feedback loop between design, production, and customer needs.” Iterative Sample Development: The A, B, C, and D Samples Milad and Markus discuss the use of progressive sample iterations (A, B, C, and D) to refine RoadPak's development. But, within each of the sample phases, they iterated quickly, for example having samples from A1, A2, A2b, etc. This approach provided invaluable insights, allowing for cost-effective tools and small-scale prototypes that rapidly incorporated feedback from customers and the production line. “Every iteration helped us with fast and impactful learning cycles which refined both product design and manufacturing. Proving that fast feedback is crucial—even in hardware.” Customer Feedback and Early Prototyping: Shortening the Feedback Loop To ensure RoadPak met real-world requirements, the team engaged customers early and often. They relied on simulation, rapid prototyping, and laser-cut parts to accelerate the feedback process. A specialized “evaluation kit” enabled customers to test the component in their own environments, exemplifying how quick delivery - even in hardware projects - can significantly speed up product development. “Early customer feedback is critical; our evaluation kit bridged the gap, turning theoretical design into practical functionality for real-world testing.” Integrated Development: Product and Manufacturing as Partners This episode emphasizes the unique challenges of developing the product and manufacturing process concurrently. By focusing on early quality control and optimizing the process on-site, they achieved higher yield and product reliability, setting the foundation for scalable, high-quality production. “For any new product, designing the manufacturing process alongside the product itself isn't optional—it's essential for quick feedback, and long-term success and quality.” Key Success Factors in Agile Hardware Development Markus and Milad highlight the importance of cross-functional teams, communication, and focus on dedicated resources. By streamlining their team's goals and processes, they maintained agility and clarity in the development cycle. This episode wraps up with tips and resources for those looking to apply Agile principles to hardware, emphasizing the value of flexible, collaborative workflows. “Focus and communication drive success in Agile hardware; with the right team alignment, you're equipped to adapt quickly and effectively.” Recommended Resources Milad and Markus suggest practical resources to deepen listeners' understanding of Agile in hardware. The book Scrum Essentials: Agile Software Development and Agile Project Management for Project Managers, Scrum Masters, Product Owners, and Stakeholders by Troy Dimes serves as an adaptable foundation. “Books and frameworks are starting points, but adapting Agile to hardware means integrating experimentation as a core part of the process.” About Markus Thut and Milad Maleki Markus Thut is a lead engineer at Hitachi Energy Ltd.'s semiconductor production in Lenzburg, Switzerland, specializing in high-power semiconductors and eMobility innovations. Markus is recognized for his forward-thinking approach to automation and industrial innovation, rooted in Swiss precision and a dedication to bringing visionary ideas to life. You can link with Markus Thut on LinkedIn and connect with Markus Thut on Twitter. Milad Maleki is the Head of R&D for high-power semiconductors at Hitachi Energy. With a PhD from École Polytechnique Fédérale de Lausanne (EPFL), Milad has led groundbreaking research and development initiatives in the semiconductor field, championing collaboration and innovation to power a sustainable energy future. You can link with Milad Maleki on LinkedIn and connect with Milad Maleki on Twitter.

Welcome back to the Building Better Developers Podcast, where we continue to explore the developer journey—from novice to expert—focusing on practical skills and mindset shifts that turn good developers into great ones. In this episode, we dive deep into a critical topic that affects developers at every stage of their careers: scope creep, requirements management, and defining what it means to be “done.” Understanding Scope Creep Scope creep is a familiar challenge in software development. It occurs when the project's scope expands beyond its original boundaries, often leading to cost overruns and missed deadlines. However, scope creep isn't always as straightforward as it seems. We discuss its nuances and how it can be misinterpreted in different contexts. A key point is the distinction between adding new features and uncovering missed requirements. Sometimes, what seems like a new feature is a previously unidentified requirement. This distinction is crucial because it changes how the issue should be addressed. If a requirement was missed initially, it's not just a case of scope creep; it's a flaw in the original project planning. The Importance of Clear Requirements Our discussion emphasizes the critical role of clear, well-defined requirements in avoiding scope creep. Poorly defined or incomplete requirements are a primary cause of scope creep. If a developer assumes they understand the requirements without fully clarifying them, they risk building something that doesn't meet the project's needs. This leads to delays, additional costs, and frustration on both sides. We suggest a proactive approach to gathering and refining requirements to mitigate this. Developers should always ask questions, clarify any ambiguities, and ensure they understand the entire process or system they are working on. This diligence can prevent many of the issues that lead to scope creep later in the project. Defining “Done” We discussed the concept of “done” as another crucial aspect of project management. In Agile methodologies, “done” should be clearly defined and agreed upon by all stakeholders before work begins. This includes not only completing the required features but also ensuring they function correctly and meet all specified requirements. It is also important to break down larger projects into smaller, manageable pieces. This allows developers to deliver incremental progress and ensures that each stage meets the definition of “done” before moving on to the next. By doing so, developers can avoid the pitfalls of monolithic projects, where the definition of “done” becomes blurred, leading to scope creep and other issues. Avoiding Self-Imposed Scope Creep We also touched on a lesser-discussed form of scope creep: self-imposed scope creep. This happens when developers add features or enhancements that were not part of the original requirements simply because they believe these additions would improve the project. While well-intentioned, this can lead to missed deadlines and dissatisfaction from clients who didn't ask for these “extras.” The advice here is clear: stick to the requirements. Developers should focus on delivering what was agreed upon and avoid the temptation to add unnecessary features. This discipline ensures that projects stay on track and meet the client's expectations. The Role of Testing in Managing Scope Creep Testing plays a vital role in managing scope creep and ensuring that the project stays on course. Michael encourages developers to adopt a test-driven approach where possible. By starting with the end product in mind and testing each stage against the defined requirements, developers can catch potential issues early and avoid costly rework later. Final Thoughts The episode wraps up by reinforcing the idea that being a better developer isn't just about writing good code quickly. It's about understanding the broader context of the project, asking the right questions, and managing both the technical and non-technical aspects of development effectively. By doing so, developers can avoid the common pitfalls of scope creep, deliver projects on time, and meet (or exceed) client expectations. In conclusion, managing scope creep, clarifying requirements, and defining what “done” means are essential skills for developers at any level. As you continue your journey in software development, keep these principles in mind to build better code and better projects overall. Stay Connected: Join the Developreneur Community We invite you to join our community and share your coding journey with us. Whether you're a seasoned developer or just starting, there's always room to learn and grow together. Contact us at info@develpreneur.com with your questions, feedback, or suggestions for future episodes. Together, let's continue exploring the exciting world of software development. Additional Resources Sprint Planning – Setting The Scope A Positive Look At Scope Creep The Importance of Properly Defining Requirements Getting It Right: How Effective Requirements Gathering Leads to Successful Software Projects The Developer Journey Videos – With Bonus Content

Stitching Agility Into Life and Work Today is June 26, or 6-26, a playful nod to Disney's beloved blue alien, Experiment 626, better known as Stitch. As we explore the connections between this mischievous character and Agile methodologies, let's dive into how Stitch's adventures in "Lilo & Stitch" can teach us about flexibility, adaptation, and the power of ohana in our personal and professional growth. Segment 1: Embracing Change and Chaos: Stitch, created to be a destructive force, initially thrives in chaos. However, throughout the movie, he learns to adapt his behavior and purposes to fit into his new family with Lilo. This mirrors the Agile principle of responding to change over following a set plan. In Agile frameworks, like Scrum or Kanban, the ability to adapt to changing project scopes or client needs is crucial. Stitch's journey from chaos to adaptation is a perfect metaphor for teams adjusting their strategies and workflows to achieve better outcomes. Segment 2: Incremental Learning and Growth: Stitch's development is not overnight. His integration into human society and his transformation into a beloved family member is gradual. This reflects the Agile commitment to continuous improvement and iterative progress—be it through sprint retrospectives in a Scrum team or the PDCA (Plan-Do-Check-Act) cycle in Lean practices. Stitch's incremental learning and the small steps he takes towards becoming a better version of himself highlight the importance of growth in small, manageable increments. Segment 3: The Importance of Feedback and Collaboration: Lilo's feedback plays a critical role in guiding Stitch's behavior, showing how crucial feedback is within Agile teams. Just as Lilo offers real-time, constructive feedback to Stitch, Agile methodologies emphasize regular feedback loops with stakeholders and continuous delivery to ensure the product meets user needs. Moreover, Stitch learns the value of collaboration and teamwork—core aspects of any Agile project. Conclusion: As we wrap up today's episode, let's reflect on the lessons from Stitch's story. His transformation from a creature of chaos to a loving family member underscores the Agile values of individuals and interactions, customer collaboration, and responding to change. On this 6-26, let's remember how Experiment 626 can inspire us to embrace our Agile journeys, fostering environments where flexibility, continuous improvement, and strong collaborations are at the heart of what we do. Call to Action: Thank you for tuning into today's episode. If Stitch's story inspired you, or if you have your own tales of agility in action, we'd love to hear from you. Reach out to us through our website or email, and join us again for more insights on applying Agile principles beyond the workplace. Remember, like Stitch finding his ohana, you're not alone on your Agile journey. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

https://medium.com/@sametkaraahmet/together-in-agile-methodology-385c1d8c3311 by: Samet Karaahmet "Together" in Agile... I know you hear the voice of Troy right now.... We're all in this together... In the dynamic landscape of the IT sector, Agile methodology has become the cornerstone of efficient project management. At the heart of Agile lies the pivotal concept of feedback and the collaborative spirit encapsulated in the term “together.” Feedback in Agile is not just a formality; it's the lifeblood that fuels continuous improvement. In the iterative cycles of Agile development, regular feedback loops ensure that teams are not just progressing but evolving. This iterative process allows for adjustments, refinements, and realignment with project goals. Feedback is a two-way street. Team members provide insights into their progress, challenges, and the evolving landscape of the project. Simultaneously, stakeholders offer valuable input, aligning the project with overarching business objectives. This bidirectional communication fosters a culture of transparency and adaptability. Agile is inherently a collaborative methodology. It thrives on the principle of working together to deliver exceptional results. The “together” aspect goes beyond mere cooperation; it signifies a collective commitment to shared goals and mutual support. In Agile teams, collaboration is not restricted to formal meetings or designated collaboration tools. It permeates the entire work culture. Team members are encouraged to share knowledge, provide assistance when needed, and celebrate collective victories. This collaborative ethos creates an environment where the whole is truly greater than the sum of its parts. Working together and fostering a culture of mutual support directly impacts the quality of projects. When team members collaborate, they bring diverse perspectives to the table. This diversity leads to comprehensive problem-solving and innovative solutions. In a collaborative environment, feedback is not perceived as criticism but as an opportunity to learn and grow. Team members support each other in navigating challenges, ensuring that individual experiences contribute to the collective wisdom of the team. In conclusion, Agile methodology, with its emphasis on feedback and collaboration, becomes a catalyst for elevating project quality. The iterative nature of Agile allows teams to adapt swiftly, and the collaborative spirit ensures that each team member contributes meaningfully to the project's success. As we embrace Agile values, let's remember that together, through open communication and a commitment to continuous improvement, we not only meet project goals but exceed them, delivering solutions of the highest quality. The Essence of Feedback in AgileThe Power of Collaboration: Working Together for ExcellenceSupport, Assistance, and the Ripple Effect on Project Quality How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

Agile Timeboxing - Gain The Focus You Need! In the dynamic world of Agile project management, the concept of “timeboxing” has emerged as a crucial technique for fostering efficiency, maintaining focus, and enabling iterative development. Timeboxing is a disciplined approach that sets specific time limits for tasks, activities, or phases within an Agile project. This technique empowers teams to manage their work effectively and deliver valuable results within defined timeframes. Understanding Timeboxing in Agile Timeboxing is a practice that derives from the Agile principle of time management and continuous improvement. It involves breaking down work into manageable chunks, each with a predefined duration. The timeboxes, which can range from hours to weeks, create a sense of urgency and commitment, driving teams to complete tasks within the allotted time. In Agile methodologies like Scrum, timeboxing is utilized in various aspects of the project, including: Sprints: In Scrum, each sprint is a timeboxed iteration typically lasting 1 to 4 weeks. This time constraint encourages teams to focus on delivering a potentially shippable product increment by the end of the sprint. Daily Standup Meetings: Daily standup meetings, also known as daily scrums, are timeboxed to a brief 15 minutes. Team members provide updates on their progress, discuss obstacles, and plan their work for the day. Backlog Refinement: Backlog refinement sessions, where the team reviews and refines the product backlog, are timeboxed to ensure that they don't become lengthy meetings. Retrospectives: Retrospectives, as discussed in a previous article, are timeboxed meetings where the team reflects on the iteration and identifies areas for improvement. Benefits of Timeboxing Enhanced Focus: Timeboxing creates a sense of urgency and encourages the team to concentrate on the most critical tasks. By setting clear time limits, teams avoid getting sidetracked and ensure that they deliver valuable increments of work. Predictability: Timeboxing improves predictability in project planning. Since tasks and iterations have defined durations, the team can better estimate the amount of work that can be accomplished within a given timeframe. Improved Collaboration: Timeboxing encourages collaboration and helps manage expectations. Knowing that a timebox is limited, team members are more likely to communicate, prioritize, and work together efficiently. Reduced Waste: Timeboxing reduces the likelihood of gold-plating (overengineering) and scope creep (adding features mid-iteration). Teams focus on delivering what's necessary, reducing waste and optimizing the use of resources. Continuous Improvement: The timeboxing practice feeds into the Agile principle of continuous improvement. By analyzing results at the end of each timebox, teams can identify areas for optimization and implement changes in subsequent iterations. How to connect with AgileDad: - [website] https://www.agiledad.com/ - [instagram] https://www.instagram.com/agile_coach/ - [facebook] https://www.facebook.com/RealAgileDad/ - [Linkedin] https://www.linkedin.com/in/leehenson/

As the world becomes more interconnected and projects become more complex, collaboration has become a critical factor in the success of any team. Whether you're working on a software development project or launching a new business venture, the ability to work together effectively is essential. In the context of agile teams, collaboration plays an especially important role in ensuring that the team can deliver high-quality results in a timely and efficient manner. In this episode, we'll explore the concept of collaboration and its importance for agile teams. We'll delve into the benefits of collaboration, the challenges that teams often face when trying to work together, and some strategies for fostering effective collaboration in your own team. Brandi OlsonBrandi Olson is a best-selling author, organizational agility expert, and the founder of Real Work Done, a consultancy serving leaders through agile transformation, organizational strategy and team design, and executive coaching. She has spent two decades consulting with organizations — from nonprofits to universities to global companies like 3M and Mayo Clinics. An expert in organizational learning and change, she teaches leaders how to solve problems and adapt fast with high-performing teams. A sought-after speaker on agility and high-performing teams, Brandi lives in Minnesota with her two kids, four chickens, and one dog.LinkedIn: https://bit.ly/3l7jQwCpdboliEmail: hello@realworkdone.com

How Are Agile Retrospectives Like Jedi Councils? Jedi Council meetings and Agile retrospectives share similarities in their purpose and structure as gatherings designed to reflect on progress, identify areas for improvement, and plan for the future. Let's explore these concepts in more detail. Jedi Council meetings: In the Star Wars universe, the Jedi Council is an assembly of experienced Jedi Masters who are responsible for guiding the Jedi Order and making critical decisions. They regularly convene to discuss the state of the galaxy, assess current situations, and determine the appropriate course of action. These meetings often involve reflecting on past events, addressing challenges, and strategizing for the future. Agile retrospectives: In Agile software development, retrospectives are regular meetings held by Agile teams to reflect on their recent work and identify areas for improvement. During retrospectives, team members discuss what went well, what could be improved, and what actions they should take to enhance their performance in the next iteration. The focus is on continuous improvement, learning, and adapting to change.

In Agile methodologies, testing is one of the pillars of the product-building process. Still,  tests can be detrimental if not properly set. Even more so when they pile up and get in the way of developers. In this episode, Software Developer Daniel North teaches us how to simplify tests. In like manner, he advises us how companies should conform their policies to streamline their policies and allow teams to be flexible yet without running wild. Listen to the full episode or read the transcript at https://semaphoreci.com/podcast/dan-north-testing.Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.

Michael Gothe is an Agile Organizational Coach at Crisp in Stockholm, Sweden. He has 20+ years of experience in building high-performance team-based Agile organizations and has worked with large multi-national/cultural organizations and start-up companies. Michael is passionate about transforming businesses to become truly Agile organizations that create fantastic value for customers and are an inspiring place for people to work. He also loves capturing the moment through photography, lives close to nature outside Stockholm, and is a proud father of three.Connecting with MichaelTwitter: http://twitter.com/teamcoachLinkedin: http://se.linkedin.com/in/teamcoach A Few Quotes From This Episode"I don't think there is  a formal study of or body of knowledge about 'Agile leadership.' I think it's about leading in complexity.""The key to success is learning. And the biggest hindrance for learning is when you think you know.""So as a leader, you first need to kind of shift from a 'know it all' to 'learn it all' approach." (attributed to Microsoft's CEO, Satya Nadella)"In Agile, you work with creating faster feedback loops and high-quality feedback loops. You want to have both quantitative and qualitative data."Resources Mentioned In This EpisodeBlog: CrispUpcoming Event/Learning Opportunity: Leading ComplexityDocumentary: Atari: Game OverBook: Deliberately Developmental Organization by Kegan and colleaguesWebsite: The Agile ManifestoBook: Empowered: Ordinary People Extraordinary Products (Silicon Valley Product Group) by Cagan and JonesAbout the 2022 ILA Healthcare Conference2022 ILA Healthcare ConferenceAbout The International Leadership Association (ILA)The ILA was created in 1999 to bring together professionals with a keen interest in the study, practice, and teaching of leadership. Plan now for ILA's 24th Global Conference online October 6 & 7, 2022, and/or onsite in Washington, D.C., October 13-16, 2022.Connect with Scott AllenWebsite

The idea of technical debt is a hot topic among software development groups.  In particular, this concept shows up in agile efforts.  While it is more a concept than a pattern, we can use this as a pattern for our design and development work.  In fact, it lines up well with the Pareto principle and pushing details off until after delivery. The Technical Debt Pattern Defined I like to think of technical debt architecture as boxes and connections that are dotted lines.  We sometimes see a whole section of functionality surrounded by a dotted line fence.  These are referred to as future features or possibly optional.  These items are, in fact, technical debt in the design.  We are assuming they will be in that category before we even start on the solution.  The pattern can be handled through phases of implementation or the amorphous "future version" label. Applying The Pattern This pattern is easy to apply.  The designer or architect selects an item or items and designates them some form of future scope.  In Agile terminology, this is an assignment to the backlog.  The item(s) might even have some sort of special priority or designation to put them in a backlog that is pre-backlog in the process.  The term hold or ice is not uncommon for these items and implies how little with think of the priority.  While this approach can be a way to kick the can down the road, it is also a pattern for focusing on high-value features first.  These have less value by definition and we will get to them once the more important features are complete. Challenges Anytime we put an item on a backlog there is the danger it will never get brought back to be done.  Therefore, technical debt is almost an anti-pattern as well.  It can be a mechanism for sweeping features under the proverbial rug.  There must be ownership of these items and a push to ensure they do eventually bubble back up to be addressed.  That can require a strong product owner or project manager.  Nevertheless, it is possible and can provide working software for customers in a much shorter timeline.

On today's episode with Allan, we have Tim Rohrbaugh, CISO at JetBlue, here to talk about Agile methodology and how it can be applied to an entire security program. Tim got into cyber through the military. From the military he went into consulting and ended up at JetBlue. At JetBlue that he is always trying to find ways to invest dollars in security programs to balance what is going on. Along with that, he strives to keep his team motivated and moving forward. Agile is a software programming methodology, and it replaced Waterfall. Waterfall was the traditional model of development, where large chunks of code had to flow from developers to QA, back to developers several times, and finally to release. Agile, on the other hand, works off user-centric stories, which roll up to bigger stories called epics. Stories are small, discrete goals, met with smaller, discrete chunks of code released in what are called 'sprints'. QA is very rapid as well, leading to rapid release. Agile is characterized by daily 'standup meetings' where literally nobody sits in an effort to keep the meetings as short as possible. In Agile, product owners come up with ideas and thread those through marketing and development. In appplying this paradigm to running a security teamm, Tim replaces product owners with threat intelligence folks. This unique approach towards managing a security program means that all decisions are threat-informed, and that small incremental wins are a constant. But Tim does not stop there. Anyone on the team can create and manage a story to address any specific and immediate security need... Key Takeaways 1:10 Tim's background and day job 2:08 JetBlue 2:39 Introduction of Agile 3:57 Tim's approach 6:15 How Agile is used 8:31 Threats addressed 9:46 Story sourcing 11:03 Creating the story 12:48 Narrative skill 14:08 Metrics 15:53 Risk management aspect 19:00 Not using risk 21:38 Positives 23:20 What keeps Tim going in cyber 24:42 What Tim is looking forward to in cyber Links: Learn more about Tim on LinkedIn Follow Allan Alford on LinkedIn and Twitter Learn more about Hacker Valley Studio and The Cyber Ranch Podcast Sponsored by our good friends at AttackIQ

Jessica Katz is the founder and owner of Liberated Elephant,  she's an acclaimed agile coach, mentor and speaker. We can learn lots about change with Jessica today including: What actually are the “agile change values” How to unlock your internal predator The key themes for leading change How to liberate your elephant with an agile mindset Plus load more hacks! Join our Tribe at https://leadership-hacker.com Music: " Upbeat Party " by Scott Holmes courtesy of the Free Music Archive FMA Transcript: Thanks to Jermaine Pinto at JRP Transcribing for being our Partner. Contact Jermaine via LinkedIn or via his site JRP Transcribing Services Find out more about Jessica Katz below: Liberated Elephant - http://liberatedelephant.com Jessica on LinkedIn - https://www.linkedin.com/in/jeskatz/ Jessica on Twitter - https://twitter.com/ElephantTaming   Full Transcript Below ----more----   Steve Rush: Some call me Steve, dad, husband or friend. Others might call me boss, coach or mentor. Today you can call me The Leadership Hacker.   Thanks for listening in. I really appreciate it. My job as the leadership hacker is to hack into the minds, experiences, habits and learning of great leaders, C-Suite executives, authors and development experts so that I can assist you developing your understanding and awareness of leadership. I am Steve Rush and I am your host today. I am the author of Leadership Cake. I am a transformation consultant and leadership coach. I cannot wait to start sharing all things leadership with you.   Today's special guest is Jessica Katz. She's a trainer, a mentor, and an Agile coach through her firm, Liberated Elephant. Before we get a chance to speak with Jessica, it's The Leadership Hacker News. The Leadership Hacker News   Steve Rush: There is a "change" theme in today's news. So, we're going to focus on a report created by Bond Capital, a Silicon Valley VC firm, whose portfolio includes Slack and Uber. The recent report, which briefed us investors has said that the global pandemic has had a similar devastating impact to Silicon Valley as the San Francisco earthquake of 1906. So why does that matter to the rest of the world? Well, Bond best-known partner. Mary Meeker is a former bank analyst and renowned for her annual internet trends report, which many investors and entrepreneurs use as a touchstone for where tech is and where it's going. And her 28-page report calls out some really interesting themes that I thought I'd share with you. So, here's the top five things I've pulled out of the report.   Number one is data-driven forward planning, the biggest market cap growers, Microsoft, Amazon, Apple, Alphabet, Google, and Facebook, or possess short and long-term business plans centred around data and their data plans include execution, iteration, engineering, and science. The report goes on to say admits the current pandemic expect these business plans to be more widely focused with more scientists, engineers, domain experts, serving as board members and non-executive directors with much stronger, more relevant voices.   Number two, the continuation of remote working environments. With the coronavirus forcing companies to adapt to remote working environments to much greater degrees than they were used to. Many companies may find for certain positions, remote working is just fine, if not more efficient for them, CEOs and boardrooms will need to reflect on their companies and employees and ask management to recommend their evaluation of what their teams work best with together in person and what also needs to be effective to ensure maximum efficiency if they continue to work remotely.   Number three, interestingly, Meeker findings from an informal survey asking companies about remote work found that those who focus on effective written communication and documentation based off the Amazon way had the best and most efficient transitions to remote work. This form of collaboration can result in much more discerning and productive input. And of course, decision making.   Number four, and not surprising, accelerating digital transformation. The businesses that are doing the best and will make it through this pandemic with less difficulties and problems will be the companies who had already begun the offline to online transition. The current pandemic has accelerated these trends, which will place more emphasis and focus on a company's technological presence with its worker consumers, as mentioned by Meeker. This includes the integration of cloud-based business functions, persistently demanded products, accessible and manoeuvre online presence, efficient delivery methods with limited contact and digitally efficient products with a social media presence.   And number five is on-demand business growth models. With the change in the way that we as consumers and workers have adapted the demand on companies, such as Uber, Airbnb are struggling due to social distancing, staying at home orders. On the other hand, on-demand services such as Instacart or DoorDash or any other door delivery service provider has expensed large spikes in demand and are eagerly hiring new labour.   The on-demand economy has grown across the globe over the last few years. In Meeker report, she calls out that in 2018, there were 56 million estimated on-demand customers compared to 25 million in 2016. The Bureau of labour statistics also concluded the on-demand services has around 156 million workers, and that's in the US alone as of the middle of 2020. Meeker believes that the on-demand and door to door delivery service may be gaining a permanent market share in these unusual times, due to the clear benefits to consumers and the opportunity of displaced workers to receive work, income and schedule your flexibility around their personal schedules.   The report goes on to say that Instacart is reportedly hiring 250,000 workers now, which in more than Walmart and A3combined. So, I guess the leadership lesson here is as leaders and as business folk, are we being really thoughtful to the trends that are emerging in the future that are impacting on not just what's happening now, but how our business might need to adapt and change in the future? My final reflections is for you to consider. What are the top five things that are trending in your business area that could impact on you, your colleagues and your business in the future? That's been The Leadership Hacker News. Like always, if you have any information, stories, nudge it my way and contact us through social media.   Start of Podcast   Steve Rush: Jessica Katz is a special guest on today's show. She's the founder and owner of Liberated Elephant. She's an agile coach and mentor where she really makes the elephant in the room work for you, Jessica, welcome to The Leadership Hacker Podcast.   Jessica Katz: Hi, thank you so much for having me on today.   Steve Rush: It's our pleasure. So, before we kind of get into a little bit about what you do now, just give us a little bit of a tour if you like of your career so far, where it's taken you?   Jessica Katz: Sure. So, my career so far, well, I started in an administrative role really and recognize that if I was going to make the kind of money, I wanted to make to support my family, I needed to something different, went back to school and ended up in project management and from project management moved over into scrum, which is a type of agile process and then into agile coaching and now into my own business, which is the really abbreviated version of my history. Steve Rush: What was it specifically for you that says, right, okay. I've got this foundation of project management, you've pivoted into the world of scrum and agile, which is perhaps a precursor, isn't it for managing change in a more rapid and changing environment, but what was it specifically, you said, right. I'm now going to run my own business. I'm going to leave behind corporate America?   Jessica Katz: Yeah. So, I got passed over for a promotion and it caused me to introspect and realize that my personal values and desire for the way I thought business should be, were out of alignment with the company I was with. And I started my business there and I worked as an employee at there and at other places before it was really able to cut the wires and move into my own thing and have it just be my thing, you know, the getting passed over for promotion. I thought I was ready for, that I thought I was capable of, that I thought I was the right person for and realizing rather suddenly that the organization was going a very different direction than I thought was healthy or good for the people that work there. Caused me to say, you know, maybe I should be making this kind of change in the world and not just in the one place I work. And so that's really what kicked off my business. I wanted to start moving the culture of business elsewhere,   Steve Rush: Got it, by the way, I think your company name is an amazing, so Liberated Elephant. It just instantaneously puts most people that worked in any business environment, straight in that room, where there is that uncomfortable elephant awaiting to be attacked. How did you come up with the name or is it just blatantly obvious?   Jessica Katz: Well, it took a little work to come up with the name, cause lots of people have business names with elephants. I had to do a little digging to find the right name, but for me, one of my superpowers is that I'm able to identify chinks in the armour. And when I work for other people, when I'm in an employee position, then I'm what they call an internal predator. And I look for chinks in the armour and identify weaknesses in the processes or breakdowns in communication. And I bring those to light and I'm ready to work through them with whomever I've brought them to, right. And I'm not throwing them at people going now, you solve it, right. I want to solve it with them. And those kinds of things, breakdowns in communication, in effective processes, processes we've put in place to deal with personality instead of actually dealing with the personality. Those are the kinds of elephants you see regularly creating dysfunction in our organization. Steve Rush: Now the whole principle of managing change and leading change has really morphed over the last 10 years. And for those that are not familiar with agile, there's a number of different variants of variations of Scrum, Kanban, and others. So, for those that are not familiar, just maybe give us a summary as to how you might describe somebody that you've bumped into has no idea about leading and managing change. What agile really is?   Jessica Katz: Sure. So agile is based in four values. Individuals and interactions, over processes and tools, working software over comprehensive documentation, customer collaboration, over contract negotiation and responding to change over following a plan. Those four values are the basis. Now agile as a whole is an umbrella term that encompasses many ways that we deliver on those four values. Scrum is one of them. Kanban is another, Lean, XP, even Six Sigma. They all fall under that agile umbrella, but agile at its core is just four values and 12 principles. It doesn't have any roles. It doesn't have any instructions on how to do it. It is just a value-based system. What we hear a lot in the world is, oh, well I'm Scrum, so I must be agile. And those two things, they don't have to be the same.   Steve Rush: Right.   Jessica Katz: You can be Scrum and not actually be living the values. You can be Agile and not be doing Scrums. So, there's you know, they can be separate. So, you know, one thing that I coach people towards in change really change management is about getting from where you are, to where you want to be and the way you move an organization from where you are to where you want to be, is you shift the mindsets and beliefs so that the behaviours follow. And often when people implement Scrum, they implement the process and then, oh, we forgot. We also need to switch people's minds.   Steve Rush: Right.   Jessica Katz: And you actually need to start with the mindset and then move into the rest. And that's a big lift for a lot of organizations. Well, we want to see results. What are the things we're doing to show that we're doing this change? And the real shift happens in small moments and in the individual minds of everybody in you company.   Steve Rush: Okay. So, when it comes to coaching other project leaders and managers around Agile, what would you say maybe the one or two consistent themes that keep presenting themselves for you that our listeners could learn from?   Jessica Katz: Sure. So, the first big one is that if leadership isn't bought in, really thinks the idea of having an Agile mindset is valuable, then we won't succeed. The reality is the transformation in organizations takes every individual to transform, or at least the majority of the people in the organization to transform. And it's weighted towards leadership because the individual contributors and your system will emulate leadership, copy what they see, because that's the path to promotion.   Steve Rush: Right.   Jessica Katz: So, what you really want to do is get your leaders bought in. So, when they bring me in as a coach, if I'm coaching an organization towards that change, I'm going to spend a lot of time with leadership. It doesn't mean the teams and the individual contributors don't need coaching, but they bring me in as an enterprise coach, I'm going to bring in a couple of Agile team level coaches to handle the, you know, the individual contributors and getting them moving in the right way. So, we attack it from two fronts. We get the leadership moved, and we get the individual contributors moved.   The second problem that shows up is the middle manager, the middle manager gets stuck. In Agile, we call the frozen middle. If you shift the top and you shift the bottom, the manager has both foundational pieces sort of shaken underneath them. And they have to figure out who they become in the new way, right? If you move both of those things, it's the who moved my cheese concept, right? Oh, suddenly my cheese, isn't where it used to be. The way I get measured, the way I get promoted, the way I promote others, the way I measure others all has to shift with that. And it can be very frightening for managers.   Steve Rush: Yeah, sure.   Jessica Katz: I'm not telling people what to do anymore. I'm letting them figure it out. And their job becomes connecting individual contributors to the larger business vision. And that's not a skill set we're taught before we become managers. So, it's can be quite, yeah, it can be quite frightening for the middle management set. Steve Rush: And when you start to think about leading change, what do you think the reason is that so many leaders of change initiatives, change programs and organizations often put that whole process before mindset? What do you think generally causes that?     Jessica Katz: It's easier.   Steve Rush: Yeah, I guess it is, isn't it? Yeah.   Jessica Katz: It's a path of least resistance to say, okay, use this tool and follow this process. And then we'll be Agile. Is easier than saying, let me spend the time to convince the population that this is a good idea, and really sit with them as they work through the struggle of shifting mindset so that they can be better, right? At slow, it often even just initiating a new process, never mind shifting a mindset. It actually slows down productivity for a little while with the long-term gain of increased productivity and public organizations. You're not driven towards long-term gain. You're driven towards short term gain because that's what moves the stock market, makes your board happy. So, there's a bunch of cognitive dissonances that shows up and, you know, sort of conflicts of interest that appear.   Steve Rush: And of course, if you have to manage mindsets of others, you've also got to manage the mindset of yours. And if your mindset is perhaps less open, less growth-orientated, then you're less likely to want to be experimental and to do new things and test new ways of working. Right?   Jessica Katz: Yeah, absolutely. It takes a lot of introspection and a lot of work to look at yourself.   Steve Rush: Yeah.   Jessica Katz: And the curiosity of self and curiosity of others is probably one of the biggest leadership skills.   Steve Rush: Yeah.   Jessica Katz: If you can get curious about yourself and where you might be wrong, and you can look at others and get curious about where they're coming from and their perspective, you get a much, much richer picture. It becomes collaborative instead of directive. And everybody gets to be in the together instead of responding and being reactive to everything else going on around them.   Steve Rush: The first time I got involved in Agile was a number of years ago, and I had this experience where I'd kind of gathered my team together. We were all on point. We all felt engaged with the new ways of working. We went to our executive team who all gave us the verbal communication, they said, "yes, we're all agreed", and, "we're all aligned", but actually they still wanted to get old gunk charts. And they still wanted the regular milestones and check-ins and steer codes that came with good old fashioned waterfall projects. How do you deal with that scenario?   Jessica Katz: Okay. This is a classic Agile coach response. It depends. It depends a lot on the context. So, let's say they want those things because it's a division that's making the shift and their leaders aren't making the shift. So, they still need the same reporting to fit into the rest of the organization. So sometimes that's the situation and a well-placed project manager can be very good at the translation between what we're doing in an Agile way, to the way we used to do things in the way we need to communicate to the rest of the organization. So that can be a really beneficial asset to that kind of situation.   Another thing that I found is that there's not a good focus when they're receiving metrics. There's not a good focus on what they're going to do with that metric. So, a lot of times you can sit, you can look at somebody and go, okay, here that you want this Gantt chart, what problem are you trying to solve by having this Gantt chart and if the problem and the Gantt chart don't actually match, right? So maybe the problem is well, I want to know what value we're delivering to the customer. Well, the Gantt chart, doesn't tell you what value we're delivering. It tells you when we're delivering things, but value is usually hidden inside initiatives or features or user stories, right? And, often organizations are very bad at communicating value. They're very good at communicating output. How many, you know, how many widgets did we make? Easy communication. What impact did those widgets have on our customer base and on our interactions with the world, that's a much harder lift. And so, you sort of leave that status quo going for a while, and you start to introduce other ideas and build on that till they're satisfied that they're getting the answers, they need to answer the question. And then you let go of the initial Gantt chart type style, right? It's just like implementing a new system. You do a little AB testing, right? Here's the thing you use to get. Here's the thing we're going to give you now, which one of these better answers your question? And once they're satisfied that the new information answers their question, well, you can let go of the old information.   Steve Rush: I wrote an article about four or five years ago when I was doing exactly this kind of transitioning behaviours around how people were leading change. And I coined the phrase of water Agile for, you know, we were kind of half Agile, half Waterfall. And it just takes a bit of careful consideration, education and communication to those people, doesn't it? Not just around how you're going to move them. What can you let go of and what do you need to hold and what reporting needs to go where? But do you ever find yourself now in the world of Agile saying to your coaches, stop right there. That's just a good old traditional Waterfall project. You don't need Agile.   Jessica Katz: Well, you know, I haven't run across one of them in recent years, but I do when I teach about Agile, I do make it very clear that there are opportunities for Waterfall that make good sense.   Steve Rush: Yeah.   Jessica Katz: A Waterfall project works when you know what you're going to do and how you're going to do it, and who's going to do it.   Steve Rush: Definitely so.   Jessica Katz: If you know the answer to those three questions with real, like real definite, like you really know. Not we guessed about our requirements and we think it's going to be this, but like really know. Installing a new server, updating firmware on a server, those kinds of things, maybe don't need Agile, right?   Steve Rush: Yeah.   Jessica Katz: Yeah, and those can work in a Waterfall way because you know what you need to do and you know how you're going to do it. And you probably have the same team that always does that kind of work. So, you have all of the pieces in play. Agile really is meant for complex projects, things where you don't know what, you don't know how and the, who is wobbly. And when I say to who is wobbly, I mean, the team is changing regularly or they're a brand-new team together. Or, you know, the team has to shift as the project shifts. That makes the who quadrant unknown as well.   Steve Rush: Yeah.   Jessica Katz: Yeah, so we're really like, Agile is best for complexity. And when it's simple, let it be simple. Waterfalls is okay; however, I would recommend that you make it small in both cases.   Steve Rush: Yeah.   Jessica Katz: Yeah, that if you do a Waterfall project, that's going to take you a year to implement, it's way too big. You want to do a really small Waterfall project, not a big gigantic thing because we're usually wrong about our estimates. Almost always wrong about our estimate. The cone of uncertainty will tell you your 0.25 to 4 times wrong on your estimate. So, if you estimate something's going to take a month, it could take you a week or it could take you four months. But if you estimate something's going to be a year, it could take you a quarter or it could take you four years. And that costs associated with that kind of risk is much higher. So, the smaller you can make it the better chance you have.   Steve Rush: Risk is also a really interesting point, isn't it? That keeps coming up in my change world. When I start introducing the whole hypothesis of experiments and testing and using some of the Agile techniques to start helping move change forward, faster and release value earlier. One of the things that keeps coming back is, surely this is much riskier than a good old traditional or to Waterfall project. How would you respond if you were positioned with that?   Jessica Katz: Yeah, it only feels like Waterfall is less risky because it feels false. Like it's more sure.   Steve Rush: Right.   Jessica Katz: Right, when we do a Waterfall project, we're certain. We've built all the requirements, we know everything, but the reality is as soon as it hits the market, we've lost our surety. Now we're getting feedback from our customer base and the market could be internal to the organization or external, as soon as it hits the market, you start getting feedback. And if you can't be responsive to that, if you spent a year building a project and now it hits the market and you find out the market, doesn't like it, you've lost a year's worth of money, where if you deliver for a couple of weeks and the market starts responding and you have an opportunity to shift your requirements so that it better suits the market. In a year's time. If it takes that long. In a year's time, you're much more likely to have satisfied your customer. And so, you know, usually when you build these big Waterfall projects, you pull like one or two people from the customer base, you have a little advocacy group. You're not really getting the full breadth of your customers and your customers are really what make the return-on-investment possible.   Steve Rush: And managed well, Agile will de-risk your project, the risk of change.   Jessica Katz: Yes.   Steve Rush: Absolutely, and I'm delighted here and it's absolutely something I experienced quite a lot, so awesome. You mentioned a little earlier, the frozen middle of the middle manager. This is taking you down a path yourself now where you're putting pen to paper and writing a book. So, we'll naturally going to have you back on the show when the books up and running to tell us a little bit about that, but from your research about that kind of frozen middle, you kind of almost identified, having you? There are three roles that typically present themselves in organizations where that kind of gets stuck. Tell us a little bit about what you found?   Jessica Katz: Sure. So, if you were a manager, you wear three hats. One is the hat of being an employee, right? I'm an employee. I'm coming here to do a job, to get paid, to grow myself, right? So that's one role,  the next role is one of advocate where you're advocating for the people that report to you. You're trying to create an environment that makes it possible for them to deliver, give them opportunities to grow, remove blockers so they can be successful. And then the other hat you're wearing is an enforcer. And this is the person who manages the status quo of the organization. Generally speaking, organizations want to stay at status quo. The pool will always be back to status quo. And the middle manager is the one making sure that continues down that path and in doing so, if they keep with the status quo and they present status quo and they lead like they're part of the status quo, then they're more likely to get promoted and have raises and be recognized for their work. So, there's a benefit to them in being an enforcer financially. And the other side of that hat is if you're advocating for the change, that's occurring in your teams and for your team, particularly if the team culture and the leadership culture is different. If you're advocating for them, then you look like you're not part of leadership and it will hurt your chances for promotion and raise because everybody wants to hire people and promote people that look and feel like them. And I'm not necessarily here talking about like physical attributes here. I'm talking about the, you know, the state of being, if you approach work the same way as the leader's approach work, they're more likely to recognize you as a good leader. Then if you approach work differently,   Steve Rush: Yeah. You need that kind of Azure and provocateur that drummer the change, Meister, call it whatever you will, but you need that to push against the status quo. How do you therefore then encourage that middle manager to manage their political corporate self-whilst still doing that effectively?   Jessica Katz: Very carefully.   Steve Rush: It's definitely true.   Jessica Katz: The first thing I recommend is that if they have a change that they think is worthwhile in the system. That in this position of middle-management, you don't actually have a lot of power. You have more power than the people that report to you, but in the organization at large, you don't have a lot. So, my recommendation then is to find a mentor in the system who's in leadership, who's known for implementing change and have them help you shepherd that idea through the system because you have to move change through the system that is. It's like, I mean, we see it all the time in the United States, the way laws are made, right? You have an idea and you have to wait until there's enough social pressure behind it before laws started to happen. It's the same kind of thing that needs to happen inside an organization. You build social pressure behind your ideas, and if you can get a mentor who is known for implementing change into your system, that's already in a high leadership position. You can leverage them to help you think it through and get it through in a way that is healthy and healthy for you as a manager and then also healthy for the organization. So, it's not jarring to the status quo.   Steve Rush: And this is also where Agile can help too. Isn't it?   Jessica Katz: Yeah.   Steve Rush: So, by running some experiments and some hypotheses, you can gather some evidence that helps the energy behind the change you want to plan or design, right? Jessica Katz: That's right. That big word that I heard you use there, the big words, hypothesis and experiment. A hypothesis looks like this. I believe, or we believe by implementing this change, we will see these results. We'll know where, right. Or we'll know we're wrong when this data is evidence and then try it a little. In fact, when I do Agile transformations, I don't recommend they changed the entire company all at once.   Steve Rush: Yeah.   Jessica Katz: I recommend that they set up a team or two fully empowered to make all the changes they need and test it in their system first and find out what blockers show up so that you can remove some of those blockers as you, it spread it further. So, you're not throwing your entire company into chaos, right? You're putting a company or two or a team or two into a chaos and deep learning for your organization. And I suppose that's really the trick around hypotheses and experiments is that you're looking for learning. Do you know that you're right? Is the change that you want to implement in the system a good one? Well, we don't know. So, test it, find a way to test it.   Steve Rush: Yeah.   Jessica Katz: Small test it small.   Steve Rush: And if you get these behaviours right, as a middle manager, these middle managers will progress because they'll have the evidence to suggest that what they want to do, delete the organizations, right? And then you create that change culture at the top of the shop through kind of just natural growth and natural progression, I suspect.   Jessica Katz: Essentially, if you can get a groundswell, the company has no choice, but to move, right. But you'd probably need a, you know, a one in five for every leader that is resistant to the change you need at least, you know, five or more people that are into the idea of that change.   Steve Rush: Got it.     Jessica Katz: Because of that weigh towards leadership. Steve Rush: So, this part of the shows where we now start to turn the leadership lens of you. So, I'm going to ask you a few questions now just to hack into your great leadership mind. So, the first kind of thing I'd like to explore with you is your top three leadership hacks.   Jessica Katz: Okay. So, the first thing I want to talk about is spend 15 minutes every day planning your day. It's it feels counterintuitive. Well, that's 15 minutes. I'm not working then. Right? But the 15 minutes is used as a little bit of self-care. It lets you look at the day and decide what you need to prioritize in that day to be effective, even better. If you can do like 30 minutes on Monday or Sunday. So, you know, going into the week, what to expect. Now, those 15 minutes could be in the morning if you're an early bird or in the evening, if you're a night owl for the next day, what I have found is that if I do it in the morning, it sorts of sets me up for the whole day and I'm much more effective and the right things get done. And if I do it in the evening, it makes it easier to sleep. Cause I'm not worried about what's coming up the next day. So that 15 minutes every day is a little bit of slowing down to speed up, which is a really common Agile trend incidentally that you want to slow down to speed up. It has long-term impacts instead of short-term impacts.   Steve Rush: Love it, yeah.   Jessica Katz: Yeah, so that's my first one. My second one is don't assume you're right. Just because you have a specific role. So, if you're, for example, I'm an Agile coach. I'm going to come into an organization and I want to come from deep curiosity, I can say things like, well, common practice in the Agile community is X and somebody could say, well, I don't think that kind of practice will work for here and I'll go, okay, well, let's have a discussion about what the common practice is trying to solve, what problem you're trying to solve and find a solution that better suits your needs. In a position of leadership, you need to do the same thing. I have an idea about how to solve this problem, but I want to leave the room open for other people's ideas. And sometimes that means in environments that have a high retribution culture. Sometimes that means not saying anything until other people have spoken. But in a low retribution culture where it's easy to trade ideas back and forth and up and down the hierarchy, then just leaving that open door and stay in curious to what other people have to say would be my second suggestion.   Steve Rush: Cool.   Jessica Katz: And my third suggestion is lift others up. This is the rising tides lift all ships kind of circumstance. In traditional hierarchical organizations. It's very common for leaders to put themselves forward and try and look good and doing things, always trying to hoard and do things so that they continue to promote. One, you're going to burn out at some point and two, it doesn't give the people you're supporting, the people that report to you. It doesn't give them room to grow. So, lift them up and help them shine. And you will shine as a result of it. It is another one of those. It feels counterintuitive to do, but it's the right way to scale yourself.   Steve Rush: I love it. Often though, the most important things that we need to train ourselves to do differently feel counter-intuitive. And I love the whole, you know, 15 minutes or 30 minutes a day, getting yourself in order because ultimately you called it out. This is not about time management. Time management is kind of baloney, right? It doesn't exist, but what does exist is prioritization, love those hacks. The next part of the show, our listeners have become affectionately accustomed to hearing stories from our guests where they've had some adversity, things have maybe screwed up in the past. We call it Hack to Attack. But the key thing here is that we've learned from it. And it's now a force of good in our life and our work. What would be your Hack to Attack Jessica?   Jessica Katz: So, I have been passed over for promotions. I have received bad performance reviews. I have been fired. All of those things have happened in my history and I was contemplating them. And I was like, what's the common theme really? That came out for me in those things. And the common theme is that I'm a really fast mover and a fast thinker and it is worth it for me to slow down and observe and listen to the systems I'm in to make sure I don't misstep or inadvertently cause harm where no harm needed to be. It does require a sort of deep self-management for me. So, you know emotional intelligence is you know, the factors of self-awareness, self-management, others awareness and others management. I would say the two that I was weak on was others' awareness and self-management. Really understanding the impact of my words and actions and staying around to clean it up. If I made a mistake, cleaning it if given the opportunity, right? Because if you do harm, the other person has to be willing to have you clean it.   Steve Rush: Defiantly.   Jessica Katz: That's kind of where my big learning has come in. Steve Rush: And thank you for being so candid. There'll be many people listening to this who suffer with a similar kind of philosophy. And it's just that kind of being self-aware and organized that can make a massive difference, so awesome stuff. The very last thing that we'd like to do is to give you a chance to have a bit of time travel now. So, you get to bump into Jessica when she was 21 and you get to give her some advice, what your advice going to be?   Jessica Katz: Well, just to set the stage for your listeners. When I was 21, I hadn't yet figured out what I was going to do with myself. I chose not to go to college right away. And I was a single mom. And I was about a year out from moving to Nashville where I had no support system. And if I had a chance to do it over or had a chance to go back and talk to myself, one of the things I would say is take a breath and look at your support system. How are you going to have that support, that kind of support, no matter where you go? And a lot of what that takes is asking for help, even when you think you don't need it. It's still a hard thing for me to do, to ask for help. I'm better about it than I used to be. But man, if I could have gotten a hold of 21-year-old me and been willing to lean into that vulnerability, it could have been a huge shift in my life earlier.   Steve Rush: If only we had time travelled, right?   Jessica Katz: That's right.   Steve Rush: By then the world we're all different and we wouldn't have had the learning experiences we've had along the way.   Jessica Katz: That's true. That's true.   Steve Rush: So, what's next for you, Jessica?   Jessica Katz: What's next for me? My primary client is a training organization. I do some subcontract training through them. So, I do have some public classes available. If anyone's interested, they can go to my website to find future classes and I need to buckle down and work on that book. I've been a bit stuck, but this conversation today may have gotten me unstuck. So, I just want to say thank you for that.   Steve Rush: You're very welcome. We can unliberated your liberated elephant, right now. Jessica Katz: That's right. That's right. Get my elephant out of the room right now.   Steve Rush: Awesome, and I know that when you've concluded your book, we'll get you back on the show. We'll talk about some of the experiences in there as well, and we'll make sure we help our listeners connect with you. In the meantime, what's the best place for them to, we can send them to your website and that's liberatedelephant.com.   Jessica Katz: And if they want to follow me on LinkedIn, I do a bunch of posting there and it usually cross posts Twitter so they can follow me on Twitter. On Twitter I'm @ElephantTamer.   Steve Rush: Love that.   Jessica Katz: And on LinkedIn, you can find me as Jessica Kat.   Steve Rush: Brilliant, we'll make sure all of those links to your websites, Twitter and LinkedIn are in our show notes as well.   Jessica Katz: Wonderful, thank you so much.   Steve Rush: Jessica, listen. It's been absolutely amazing chatting to you. I've thoroughly enjoyed the whole exploration of Agile and the change and how you coach that through with your clients. Just wanted to say, wish you every success with conclusion of your book and most importantly whatever you do next and thanks for being part of our tribe on The Leadership Hacker Podcast.   Jessica Katz: Great, thank you so much. Stay healthy.   Steve Rush: Thank you, Jessica.     Closing   Steve Rush: I genuinely want to say heartfelt thanks for taking time out of your day to listen in too. We do this in the service of helping others, and spreading the word of leadership. Without you listening in, there would be no show. So please subscribe now if you have not done so already. Share this podcast with your communities, network, and help us develop a community and a tribe of leadership hackers.   Finally, if you would like me to work with your senior team, your leadership community, keynote an event, or you would like to sponsor an episode. Please connect with us, by our social media. And you can do that by following and liking our pages on Twitter and Facebook our handler there is @leadershiphacker. Instagram you can find us there @the_leadership_hacker and at YouTube, we are just Leadership Hacker, so that is me signing off. I am Steve Rush and I have been the leadership hacker.  

When it comes to working on a team of any size, the concept of being a leader is important to understand. In Agile, whether you're a scrum master, facilitator, teacher or coach, being a leader means more than just managing a team and “doing the work”. Agile leadership is about growth and efficient productivity through personal channels such as self-awareness, humility, active listening, self-organization, flexibility and trust. A leader's job is to not just solve the problem but to create a fun and open team of confident individuals who are happy to solve those problems alongside you. In today's podcast, we're meeting with Agile leader, Joe Ziadeh, and hearing his thoughts on Agile facilitation and true Agile leadership. With over 25 years of successful Agile experience, Joe Ziadeh definitely lives up to his last name, which roughly translates to "awesome" from its Arabic roots. Starting as a software developer who happened to stumble into Agile during his college years, Joe would go on to work as a coach, teacher and consultant, helping transition startups, healthcare companies and banking companies into the Agile mindset. We're proud to introduce Joe Ziadeh. Support this podcast: https://anchor.fm/theagilecoach/support

Houston Business Growth Podcast Episode 3: How To Achieve Greater Business Results, Scale Your Business More Effectively, & Build An Envious Corporate Culture Along The Way _____________________________________________ Host: Brian Webb Guest: Anthony Coppedge _____________________________________________ Description: LISTEN TODAY, as the host, Brian Webb, along with our guest, Anthony Coppedge, walk you through How To Achieve Greater Business Results, Scale Your Business More Effectively,  and Build An Envious Corporate Culture Along The Way.  Anthony is based out of Fort Worth, Texas where he leads the Agile Transformation for Digital Sales at IBM. He's held leadership roles at Fortune 100 enterprises and sub-$20 million revenue software startups. He's been applying the values and principles of Agile since 2009 and is literally one of a handful of early leaders in the Agile Sales and Marketing space worldwide. _____________________________________________ Helpful Links: The Age Of Agile by Stephen Denning Mastering Marketing Agility by Andrea Fryrear _____________________________________________   Podcast Sponsored By: SERVPRO® Disaster Recovery Team Houston Find and Follow our Sponsor, SERVPRO® Disaster Recovery Team Houston Web: www.disasterrecoveryteamhouston.com Linkedin: https://www.linkedin.com/company/servpro-disaster-recovery-team-houston/ Facebook: https://www.facebook.com/SERVPRO9734 Intro Video:  https://youtu.be/YH1GXKrRUTU  _____________________________________________ Connect w/ Brian Webb Web: https://cmo.webbmarketing.solutions/ Linkedin: https://www.linkedin.com/in/thebrianwebb/ Facebook: https://www.facebook.com/thebrianwebb Instagram: https://www.instagram.com/brianwebb/ _____________________________________________ Connect w/ Anthony Coppedge Linkedin: https://linkedin.com/in/anthonycoppedge _____________________________________________ Click on this link for a full transcript of the podcast. _____________________________________________   Like what you hear? Want to Subscribe? Connect with Houston Business Growth Podcast on Apple Podcasts - Subscribe and leave us a review. Your participation helps us grow and reach more business owners and leaders just like you. _____________________________________________   Transcript: Brian Webb: Hey there, everyone. Welcome to the Houston Business Growth podcast. I'm your host, Brian Webb. This podcast is designed for entrepreneurs just like you that want to grow your business faster and make better decisions with fewer regrets. We're here to help you grow by bringing you tools, tips, and tricks, along with success stories and industry expert interviews that will help you to grow your business and your team while helping you to avoid the pitfalls and mistakes that cost you so much money and wasted time. So with no further ado, let's jump into today's episode.   Brian Webb: I am thrilled to death to have my good friend, long-time friend, Anthony Coppedge on the Houston Business Growth podcast today. I've known Anthony for about 25 plus years. And today's title is called, how to achieve greater business results, scale your business more effectively, and build an envious corporate culture along the way. Anthony, for those in our audience who don't know who you are and what you do, why don't you take a moment, introduce yourself.   Anthony Coppedge: I'm just this guy, you know?   Brian Webb: Yeah.   Anthony Coppedge: So I've known you so long. For those who don't know me, I am an [Agile 00:01:20] transformation lead at IBM, where I drive the transformation to agility, business agility, for digital sales. And so my background is in marketing, sales, entrepreneurship, business ownership, obviously, and software as a service business, as well as mom and pop and enterprise. So I have a pretty diverse background and I try to bring it all to bear.   Brian Webb: Awesome. Awesome. So I know you're going to be talking about what we've kind of named the title, how to achieve greater business results and scale, and build an amazing culture. I know that you're going to be talking to us about Agile. Why don't you tell our listeners exactly what Agile is, just to get us started today?   Anthony Coppedge: Sure. Well, we all know that the adjective to describe something agile would be nimble or flexible, or to be able to iterate or change quickly. And that really is the heart of it, the lowercase A. But when people talk about upper case A Agile, what they're talking about is a movement that started in 2001 when they said, there has got to be a better way to deliver software. And so it started there, where they would look at things like ... Brian, I know we're both old enough, do you remember Windows 95?   Brian Webb: I do.   Anthony Coppedge: What was after Windows 95? What was the next OS they released?   Brian Webb: Wasn't it 98?   Anthony Coppedge: It was 98. And then after that, what was it?   Brian Webb: 2000?   Anthony Coppedge: Yep. And then after that XP.   Brian Webb: I'm being tested.   Anthony Coppedge: Did you notice that it took years to roll out a new piece of software back then?   Brian Webb: Yeah. Yeah, yeah, yeah.   Anthony Coppedge: So that's what these guys were up against. It took years. So they would have these beautiful Gantt charts that would describe all the dependencies and what it would take to make something. And it was always precisely wrong. I like Gantt charts for one reason only. I love the whooshing sound they make as the deadlines fly by. Because they're always precisely wrong.   Anthony Coppedge: So this group of leaders met and said, there's got to be a better way. And they wrote a manifesto and said, what if we just had a way to chunk that up into small bite-size bits, and rather than figure out everything up front, we figure it out as we go. And so that's the idea behind Agile.   Anthony Coppedge: It has since been applied to project management, human relations operations, to marketing, and now of course I'm leading it for sales. So Agile is a way of working, a new way of working which brings people together to where we're better together than apart. And we learn, test, and validate very, very quickly so that we deliver higher value at scale.   Brian Webb: I know that transforming a culture sounds dynamic, not static. What are some ways that entrepreneurs can encourage this kind of cultural transformation?   Anthony Coppedge: Well, first you have to be able to know your why. So, so many businesses think their why is profit. No, that's a by-product, right? If you deliver phenomenal value in whatever you do, you're going to make money if you there's an appetite for it, right? So if you think of the Venn diagram of, what are you great at, what does the world need, and can you get paid for it? Right in the middle of that is this ideal way of saying that's the offering you should have. Well, every business needs to be able to clearly articulate what that is. We exist for the purpose of, and we know we're successful when, and we will do these things to align our work, our efforts, our actions, and attitudes, to make sure that happens.   Anthony Coppedge: So for an entrepreneur, you wear all the hats, right? Chief cook and bottle washer. But when you're thinking about growing your business you have to think about the clarity you have of where you want to go, not the outputs you want to achieve, but the outcome of being in business and make that visible, transparent, shareable, and easily transferable to everybody else in the organization.   Brian Webb: That makes sense.   Anthony Coppedge: And that's the key to building the culture you want. The best way to invent your future is not to look at your past. The best way to invent your future is your future.   Anthony Coppedge: So we want to think of it, not like maps go, but more like GPS. Now for those over 25 in the room, you know what I'm talking about, but there was a day when I was in sales, where you would have a binder of maps. And if I wanted to follow this road in Houston, from the Northside to the Southside, I would, when I get to the edge of the map it'd say, turn to page 37, then I flipped to page 37. There's the rest of that map. And then, okay, turn to page 45. And then that's how you were able to navigate and take a portable map with you. And what I would do, Brian, like any entrepreneur, I would find the most efficient ways to get from client to client, from location, location. And I would know those. And so I'd highlight them in. So I was determining routes.   Anthony Coppedge: Well with GPS, we have dynamic real-time information, mostly from other cell phones. And if it sees that on I-45, that there are no cell phones moving, that's probably a traffic jam. And so it's going to try to route you around that. So GPS is more interested in the destination than the route. And as entrepreneurs, we need to be far more interested in the destination than the route.   Anthony Coppedge: We don't need to tell people how to get somewhere. We need to make sure they have the tools, the competence, and the clarity to know that we're going to support them as they discover the best ways to get there because they're closer to it than we are. And we need to trust them with the ability to take our business and add that value to clients. So we delegate not just responsibility, but we delegate authority. What we're trying to do is build out a culture that says it's built on respect, openness, courage, empathy, trust. And these are very, very difficult things for someone who's used to doing it all and controlling it all, because Agile is the antithesis of control.   Brian Webb: Wow. That's a mouthful. So let me ask you this. So Peter Drucker once said, culture eats strategy for breakfast. In today's radically different world, especially during and after COVID, what's the difference between employee management today compared to even just a year ago?   Anthony Coppedge: Well, it's hugely different. And I think everybody listening to this podcast would already have experienced what that feels like. But if we were trying to put some labels on it and describe it, it would be chaotic, uncertain.   Anthony Coppedge: So how do you know if your people are have what they need to get the job done? How do you know, not just what are they working on, but are they getting the right results? How do you know what the process is that needed to be identified? How do we have better communication so that people don't feel like they're on an island inside their homes as they work from home?   Anthony Coppedge: And we've all had to address this, IBM too. And so one of the things what's been helpful is, Agile focuses on building a communication centric organization. So we're real big on visualizing and communicating about where we are, where we're going, and what's in the way. And so, because we do that regularly, daily, it's small little increments of check-ins, not to inspect, but to understand that give us the ability to pivot, test, and move quickly, so that our reps, even though if they're working from home, still feel like they are a part of something bigger and they still have the benefit of the largess of the organization, their peers, and their management to help support them.   Anthony Coppedge: So you don't have to see somebody working. You're looking for the fruit of that work. And anything that's not showing up, you're asking why, not what. There's the heart of really being a great manager inside an Agile organization. And in fact, Brian, I would say that traditional management looks at task management, activity metrics, quota attainment, as the way they understand quote unquote success. But what I would say, with Agile, we would look at it and say, how can I help you get what you need and what's in your way?   Anthony Coppedge: And so in Agile management, I don't want to inspect, I want to understand. In Agile management, I don't want to have activity metrics, I want to have outcome results. And I want to understand, are we delivering value, not, are we delivering stuff?   Anthony Coppedge: One of the easiest ways to see this is, look at the activities that someone says, yeah, I did all of these things and yet the business isn't moving forward. Pick an area in your business where you see that. And there likely is one. There's usually at least one person, larger companies are going to see it more common, where they're doing all the things, but the results aren't happening. Well, we shouldn't say, shame on you for not working hard enough. We should look at ourselves and say, shame on us for not trying to understand why that is. Because if I can understand that in COVID, people aren't answering the phones like they used to. They're literally not at the office. But they are responding to email. They're on LinkedIn. They are responding, but they're just doing it in a different channel. So having an activity quote of, did you make 50 calls a day? Well, that might be the wrong thing. But because we want to have busy-ness as an activity metric for success, we're having them actually be incredibly efficient at doing all the wrong things. That's not success. So we want to find new ways of doing that. And management in Agile is more about helping you with your career advancement and getting stuff out of your way. And that's it.   Brian Webb: So let me ask you this, when you're talking about metrics, what's important for Agile to measure? Or what kind of key performance indicators are focused on in an Agile organization?   Anthony Coppedge: Yeah. So you want to, first of all, visualize your mission, your vision, and your objectives. So I'm a big fan of OKRs or, objectives and key results. And the idea is to say, if we're supposed to be about this, then what are the things that we're going to focus on to get there? And let's go validate and see how that works.   Anthony Coppedge: So what you do is you empower people to be self-directed. And the measurements you look at are less about activity and more about outcomes. So there is both a sense of lagging indicators that you could check into to look for things based on the kind of business you have, that would be helpful to understand. But the more important question is to ask, why is that?   Anthony Coppedge: For example, it's not uncommon in the world of sales and marketing for people to be very busy looking at the click throughs and the open rates of things. But that's like true, but irrelevant, right? Because if they don't actually do something, I don't care how many people open my email. I don't care how many people click on my Facebook bot if it doesn't lead to something, right? I can have a false positive that shows, sure, I get lots of activity, but does it ever go anywhere? Well, then it's not success.   Anthony Coppedge: I once had a sales rep, a young sales rep say to me, "Hey, check it out, man. I got my stuff moved over this week and I'm visualizing my work and I made 400 calls this week and I made 400 calls the week before." And I said, "Great, how many leads did you get?" And he's like, "Well, none, but I made 400 calls." I'm like, that's not success, right? We actually are not paying you to make phone calls. What we're paying you to do is get results. That'll usually include phone calls, but I'm less interested in measuring the activity and more interested in understanding what's working, what's not, and where are you in that understanding continuum, so that I can train you if you need more training or I can demonstrate to you how to do something more efficiently, or you can show me our process is messed up, we're out of alignment, but this is where we are.   Brian Webb: We'll get back to today's episode in just a moment, but first, a quick word from our sponsor. Today's episode is brought to you by Team Meacham at SERVPRO's Disaster Recovery Team Houston.   Brian Webb: Whether you know it or not, your business needs an emergency response plan. We see it on the news all the time. Another business owner who experiences tragic loss due to fire, or extreme storms like hurricanes, or flooding. And we all hope it will never happen to us. But research shows that up to 50% of all businesses shut down after a major disaster. And if the property damage isn't bad enough, the business downtime and loss in revenue only makes it worse.   Brian Webb: So should your business be devastated from a fire, flood, or storm damage, how do you minimize the downtime and frustration of getting back to normal as soon as possible? Here's the answer. You need an emergency response plan.   Brian Webb: How do you achieve this? It's easy and it's free. Once you reach out to SERVPRO's Disaster Recovery Team Houston, one of their ERP specialists will set up a time to meet with you or someone from your team. When the specialist shows up, they will walk through your facility with you and make a concise profile document for your business outlining all of the critical information like, where the electric, water, and gas shutoff valves are located, along with the priority areas of your business and the primary points of contact. Wouldn't you prefer that when someone does show up to assist you in a time of crisis, that they already know what to do, where to go, whom to call, and how to get started? Of course you would.   Brian Webb: Additionally, imagine getting VIP service like three hour priority response time when you call. And the work begins on arrival to bring your business back to normal as quickly as possible. Before the SERVPRO Disaster Recovery Team Houston even shows up, they already have photos of your facility, they know where to park, and exactly who they should be dealing with.   Brian Webb: And guess what? It's free. No contracts, no catch.   Brian Webb: You really need to get this taken care of today. You want to be prepared in the event your business does experience fire, water, or severe storm damage. To make this happen. Simply call the SERVPRO Disaster Recovery Team Houston office at (281)-419-9796. Or even easier, simply text ERP to (832)-713-6881, and one of their specialists will reach out to you right away.   Brian Webb: We hope that you never experience a disaster that adversely affects your business. But if you do, don't you deserve to know that you can worry less by knowing that you're in the best hands possible? Of course you do.   Brian Webb: Again, call (281)-419-9796, or simply text the letters ERP to (832)-713-6881. You'll be so glad you did.   Brian Webb: So I have a question. I was once taught the principle of the BAT. And BAT is an acrostic. B stands for behavior, A stands for attitude, and T stands for technique. Behavior, in this particular scenario that we're talking about would be making calls, right? Attitude is, if you don't have the right attitude about three things, one, yourself, two, your organization, and three, the products or services that you sell, you're probably going to suffer. And then technique is obviously just getting better and better.   Brian Webb: So I would imagine the entrepreneurs and business leaders listening to this episode will agree that at the end of the day, especially the business owners, one thing that they care the most about is, how many leads did you close? How did you drive revenue? At the same time, I know that doing the right behaviors is usually the best way to predict the outcomes you want to achieve. How do you weigh those two important variables in Agile?   Anthony Coppedge: That's a tension to manage, that's not a problem to solve.   Brian Webb: That make sense.   Anthony Coppedge: Right? So COVID, right? We're all still in this right now. And so one of the things I've heard from salespeople is people aren't picking up the phone, and/or when they do get ahold of them, there are companies not sure how this thing's shaking out or when it's shaking out. The whole world's in flux. We want what you have. We just might not want to buy it right now. We need to see how things work, right? So what we would do is, we would take that feedback and go, so our Q4 might not be as great as we would normally have it be, but welcome to COVID.   Anthony Coppedge: What we are more interested in then is, what kind of Q1 pipe are we building? What kind of Q2 pipe are we building? We're deferring some things, but what we're doing is adding value and we're showing we care and we're responsive and listen. We understand their pain. We want to solve that for them. So when we do that, we're okay with deferring the sale. Not because we don't care about hitting numbers. We're more interested in saying, how do we know if we're adding good value? And do they trust us as a trusted source to come back to us when they are ready to buy? That's more valuable. Because what you want to look at is not the short term closes, right, Brian? You want to look at the lifetime value.   Brian Webb: Absolutely.   Anthony Coppedge: So, in many businesses, once you get them to buy more than once, their lifetime value goes up by an exponential amount. So if you can get them to be a repeat customer or to expand from one offering or services into two or more, their LTV can go up five, six hundred percent, right? So what you want to do is have that long-term view and that client centric view, which is at the heart of Agile. I want to deliver value to my client.   Anthony Coppedge: So let me make this real simple. When I ask my sellers to make calls or to generate leads, what I'm not asking them to do is hit a number. Instead, what I'm saying is, how can you separate the wheat from the chaff so that those people most closely aligned to what we do and the way we do it, to really exponentially help their business be better. How could you get excited about identifying, ding, ding, ding, this person's going to be blown away by what we can do for them. And you are not disinterested in the rest, but you focus disproportionately on those who are a good alignment. And now you're not worried about getting leads, you're not worried at all. What you're now excited about, and that's that B thing, behavior, attitude, right? Now you're looking at, I can't wait for when this is going to make a huge impact on your business. I'm so excited. That is a client centric sales viewpoint, not a, I need to hit my quota because I want to get paid viewpoint.   Brian Webb: Right, right. Yep. Absolutely. Let me ask you this, what are some of the key benefits of having teams and departments working in Agile together?   Anthony Coppedge: So that's one of the fundamental things, is that we are better together than apart. And we all know this to be true. But think about your compensation model for your different people, including sales. A lot of it is focused on individual contributors. And there's absolutely nothing wrong with that. But what would happen if you also said that in addition to your individual compensation, we want to think about how we incentivize the team getting better. How do we build a culture where a rising tide floats all the boats and everybody wins? And I'm not talking about taking the work that I do and carrying the load of five other people who are slacking. That's not what I'm talking about. I am saying when everybody contributes, we should all benefit together. And so what motivates then is the sharing of learnings, the sharing of insights, so that people are motivated and want to. Not just for the paycheck, but because they see the value of learning and benefiting from others as well.   Brian Webb: I would imagine this last question that we have for today, or that I have for today rather, I know the answer to it, but I want to hear what you have to say specifically for our audience, but what kind of company or companies would benefit from an Agile transformation of their culture, their systems, their processes?   Anthony Coppedge: If you want to be focused on delivering exceptional value and you can't wait to delight and surprise your clients, you probably ought to take a look at Agile. And even in spaces where it might not be as intuitive. People are like, Agile doesn't work everywhere. No, you're right. It doesn't. But it could probably work around the areas where it doesn't work.   Anthony Coppedge: I had someone said, a surgeon, if I'm doing the surgery, there's no way that can be Agile. You're correct. As an individual contributor during the surgery, you are the expert. But I bet it took a lot of people to coordinate getting everything ready for that surgery to even happen. And I bet the post-op's going to require a bunch of people. And I bet the insurance follow-up is going to require a bunch people. There's probably plenty of room for Agile there, even though you're the expert in your domain, right?   Anthony Coppedge: So the idea of anywhere where we can say, we're better together, and we can scale up narrowly what works and scale down broadly what doesn't, there's the real value of having your business become far more effective over time by making those small iterative improvements to make big impacts.   Anthony Coppedge: Brian, when I lead my kickoff training, when I first talk to sellers, I say, so I want to introduce you to Agile. Let me ask you a question, how many of you will be thrilled if I increase your quota today by 50%? And of course nobody's hands goes up, right? Like, what?   Brian Webb: Of course.   Anthony Coppedge: But then I talk for a couple of minutes and I say, so let me ask another question, how many of you think it's reasonable that if we work together, we could all get 1% better a week? And of course the vast majority or almost all the hands go up and I say, great.   Brian Webb: Sure, everyone that's reasonable, anyway.   Anthony Coppedge: If you took two week vacation in a standard tier, in 50 weeks you'd be 50% better.   Anthony Coppedge: Now you ask any CFO, any CMO, any COO, any CEO, hey, what would 50% better do to your bottom line, to your customers, into your ability to scale your business? And they would be going nuts for that. Well, there's the idea, right? It's not that we're suddenly so much better, it's that we're continuously improving to get exponentially better over time. And what it requires is that commitment to clarity, the ability to have a shared set of values and a set of principles that align us so that the work we do is not just the work we could do, but the work we should do.   Anthony Coppedge: And I'll leave you with this. I remember talking to a senior executive once when I was talking about the idea of breaking it up into small bite sized chunks of one week at a time to improve, right? And this person looked at me and he says, Anthony, are you telling me we get to tell them what to do every week? And I looked at him and I said, no, they get to tell us what to do every week. There's the difference.   Brian Webb: It's a complete pivot. Yeah. It's a complete pivot altogether. Let me ask you this, and this is my last question, but for those in the audience who are just now even hearing about Agile with a capital A, what would be a first or a next step? Meaning, perhaps 30 minutes ago, that word was not even necessarily as an Agile with a capital A in their vocabulary, or certainly in their sense of what they need to be doing with their business. It wasn't a priority. And imagine the listeners that are hearing this, they're understanding something, they're seeing fire for the first time, what would be a first step for them to take to start moving in that direction for implementation?   Anthony Coppedge: I think we do best when we talk to our peers first. So I would ask my peers, my friends, hey, does anybody know somebody doing anything Agile with their business? Because what's going to help is for you to see a contextually relevant example. So if you are aware of that, that would be the first place to start because people talk to people and that's probably easiest way to learn.   Anthony Coppedge: For the podcast listeners who I'm pretty confident are going to be avid readers as well, I would throw out the book, The Age of Agile by Steve Denning. Remember I told you about that group that got together and wrote the Agile manifesto? Well, Steve has since gone on to talk about business agility, not just software agility. And The Age of Agile is a very practical read that helps kind of explain the thinking behind it. I would point to that as a next step resource. And then if you have specialty, like Agile marketing, that would be Mastering Marketing Agility by Andrea Fryrear. And there's lots of different domains where you can see this. Do a search for it on Amazon and you're going to find a ton of books. There's no lack of content. It's a multi-billion dollar industry.   Brian Webb: Okay. Well, Anthony, I know that we're all better off for having had this conversation with you here today. For those that might want to connect with you online, where's the best place for them to either connect or follow or reach out to you?   Anthony Coppedge: Well, I would point most people to my website, but the truth is, I've really enjoyed connecting with people on LinkedIn. And if you want to follow and see what I say before you connect with me, that's a total viable option. It's very easy to do. You just go to linkedin.com/AnthonyCoppage. And I'm sure you'll have a link somewhere, Brian. But I love connecting with people on LinkedIn. It's my favorite social platform. So that's where I would point people to.   Brian Webb: And again, someone who's known you, Anthony, for two and a half decades, I would be one to urge our audience to do that. Anthony is always a source of encouragement. He's always a source of insight. And I just want to say thank you for being on our show today, Anthony.   Anthony Coppedge: Thank you, my friend.   Brian Webb: Thank you for listening to today's episode of the Houston Business Growth podcast. As always, we're here to help you grow your leadership and your business by making better decisions with fewer regrets. If you've enjoyed the show, please let us know by subscribing to the show and leaving us a review. You can subscribe to this podcast on Apple Podcasts, Google Play, Spotify, or anywhere else you listen to your favorite podcasts. Again, thank you for listening. We'll see you on the next episode. _____________________________________________ Tags: Houston Business, Houston Business Growth, Houston Business Growth Podcast, Brian Webb, entrepreneurs, Houston, sales, marketing, leadership, Servpro, Randy Meacham, Susan Meacham, Disaster Recovery Team Houston, Extreme Team Meacham, Anthony Coppedge, Agile, IBM

In Agile, executing is often prioritised over planning. However, not planning enough can be as costly as planning too much. Herman Swart, Custom Project Development Manager at Tangent Solutions, thinks that rigorous planning is critical, even in Agile. The skill, he says, comes in knowing when you’ve planned enough, and he’s set up a process that helps his team reach the optimal amount of planning for every project.Herman says that the misconception in Agile he sometimes encounters is that teams should jump into execution as soon as they can. Although he doesn’t think the entire project should be spent planning, executing shouldn’t come at the cost of sufficient and structured planning stages.Herman’s team has a six step planning process, divided into two phases, for scoping a project before execution. He talks through each step in our conversation, which can be found at the time stamps alongside:1. THE PROPOSAL PHASE[00:22:22] 1.1 The project proposal: Understanding the client’s wants and needs[00:28:33] 1.2 Scope of work: Laying out the delivery 2. THE DEVELOPMENT PHASE[00:41:00] 2.1 Resource allocation: Finding the right people to do the right things[00:45:12] 2.2 Client briefing session: Setting roles and responsibilities[00:50:21] 2.3 Product backlog and feature list: Planning sprints and deliverables[00:57:51] 2.4 Project setup: Setting up environments and addressing dependenciesCheck out the transcript on the blog here! (https://bit.ly/2VwtXdU)

Read the full Show Notes and search through the world’s largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website.  In Agile teams, Leadership has a different role. In this episode, we talk about the traditional approach to leadership in teams. From the technical lead, to the line manager, and how those roles should change to enable Agile teams.  Featured Book for the Week: How to Win Friends and Influence People, by Dale Carnegie In How to Win Friends and Influence People, by Dale Carnegie, Izis found a set of tools that help her in her daily work as a Scrum Master. The book was written in the 1930’s, on the back of the Great Depression, and shares some of the techniques that successful people used to achieve in their lives. Dale goes through many of those techniques and outlines simple approaches that can help Scrum Masters also achieve their goals and help their teams.    About Izis Filipaldi Izis' mission is to help people to improve their knowledge and professional value inside organizations, applying the agile way of working. She has been working as an Agile Coach for more than 7 years, helping people to deliver products, developing an environment free of judgments where they can fail fast and learn faster. Continuous improvement of: people knowledge, product delivery, and work environment, are her 3 main focus on work. And she loves what she does! You can link with Izis Filipaldi on LinkedIn and connect with Izis Filipaldi on Twitter. 

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:

In Agile always talk about prioritization in Agile. Like it or not, there's always something on the bottom of the list. While at dinner prior to recording, we were talking about how it's a great trust building exercise to not ask a waiter what the BEST thing on the menu is, but what they feel the WORST thing on the menu is. We took the same approach this episode to the Scrum ceremonies, where both Eric and Hernande answer the question as to both their FAVORITE and LEAST FAVORITE Scrum ceremony and why. An honest discussion around reasons for both.

Agile, as a software development methodology, was invented by programmers and for programmers, to make things easier for them and to get a perfect excuse when things go south. In Agile the management is not in charge anymore, can't control things, can't really predict anything, and can't blame programmers for mistakes. If you are a programmer, Agile is your perfect shield against most of the problems in the office. If you are a project sponsor, it's your ticket to failure. The full video is here: https://youtu.be/OOAMNOso46g

Hey Everyone! Sorry for getting this episode out late today! This week at The Standup we're going to be talking about False Sense of Urgency.  In Agile, the ability to prioritize your backlog based off value both to your customers and the business is key. But there are times, and there are people, who try and bypass this process by generating a sense of panic and false urgency around perhaps an item that is only important to them. At this week's episode of The Standup Podcast we're diving into the topic of False Sense of Urgency, what it is, how it happens, how you can identify it, and how you can combat it.

This week Devin Hedge joins Dave Prior for another student question. This time about architecture and if the complexity of it would be better served by a waterfall approach: The Question: "How to plan for the Architecture effectively. With waterfall, we try to figure out all aspects of the business and the technical solution in advance before we start development. In Agile, we discover as we go. It's very likely that when we come to a certain, we'll find either the current business logic or the current technical framework cannot adapt our upcoming demands. There's a high opportunity that we'll need to destroy all the work that we've done. Talking in this perspective, isn't waterfall better than Agile?" Show Notes 00:08 Interview Begins 00:51 This week’s question 02:00 What do we mean by architecture 02:29 The design principles and standards you need in place to support your work 03:35 If it isn’t loosely coupled, neither waterfall or agile can really help 04:17 Challenging the assumption that big up front planning could help you eliminate the risk of having to do rework and whether or not waterfall is actually supposed to do that 07:43 If we can’t eliminate the risk of not knowing everything up front, what can you do? 08:30 Devin puts on his architect hat - guardrails and guideposts 09:53 Reframing the problem 10:40 How physical building architects are still designing even after the building is built - you never know what the tenants of the building will actually want 11:48 The risk of making decisions too early 12:18 Advice from Devin on how to reduce your risk of designing architecture up front and put up the guardrails and guideposts you need 14:14 How architects look at the work and decision making 17:02 Making decisions at the last possible responsible moment 17:43 Having a growth mindset vs. a fixed mindset 19:10 Is there value in waiting to make your decisions until you have all the information? What is your cost of delay of waiting to make the decisions? 20:57 Devin’s upcoming events: Agile Budgeting and Cost Tracking for the PMI North Carolina Chapter on July 11 and PMI South Carolina on July 20 21:57 How to get in touch with Devin 22:47 Interview Ends Links from the podcast Does Agile addresses the 25 point Federal IT Reformation plan? (June 29) PMI Washington DC http://conta.cc/2sov4vn Agile: Budgeting for Agile Financial cost planning/tracking (July 11) PMI North Carolina http://bit.ly/2tmVMZz Jeff Bezos Memo about Cloud Services http://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/ Contacting Devin LeadingAgile: www.leadingagile.com/guides/devin-hedge/ Twitter: twitter.com/agiledevin LinkedIn: www.linkedin.com/in/devinhedge Contacting Dave LeadingAgile: www.leadingagile.com/guides/dave-prior/ Email: dave.prior@leadingagile.com Twitter: twitter.com/mrsungo Personal Blog: drunkenpm.net LeadingAgile CSM & CSPO Classes For information on LeadingAgile’s upcoming public CSM and CSPO classes, please go to: www.leadingagile.com/our-gear/training/ Use the discount code: LA_Podcast to receive a 15% discount on the class. Feedback/Questions If you have comments on the podcast, or have questions for the LeadingAgile coaches that you’d like to have addressed in a future episode of LeadingAgile’s SoundNotes, you can reach Dave at dave.prior@leadingagile.com

Dave Rush, Accenture Managing Consultant and Transformation Agent, is passionate about putting an end to projects, because as Dave puts is, "Projects are dead... because by their nature they have a start and end... and a goal to deliver some unique thing." But in Agile work is always flowing, so it makes more sense to think in terms of product life cycles. Moreover, it's time for businesses to think in terms of funneling work to long-lived, high-performance teams. Projects are constantly bringing together stars who have never worked together and, as soon as they get the hang of collaborating, the team is blown apart and the project process starts all over again. In Agile and SAFe, you want high-performance teams who are highly collaborative and practice collective ownership. To make that work in a business context, says Dave, you have to "fund the people and the trains and keep them stable and bring the work to them." Dave also shares his thoughts on why the English national team can never win. SolutionsIQ's Evan Campbell hosts at SAFe Summit 2016 in Denver, Colorado. About Agile Amped The Agile Amped podcast series connects the community through compelling stories, passionate people, shared knowledge, and innovative ideas. Fueled by inspiring conversations with industry thought leaders, Agile Amped offers valuable content – anytime, anywhere. To receive real-time updates, subscribe! Subscribe: http://bit.ly/SIQYouTube, http://bit.ly/SIQiTunes, http://www.solutionsiq.com/agile-amped/ Follow: http://bit.ly/SIQTwitter  Like: http://bit.ly/SIQFacebook

Listen to the Software Process and Measurement Cast 289. SPaMCAST 289 features our essay on sprint planning.  The essay begins: It is often said that well begun is half done. In other words a good start contributes to a good finish (at least according to Mary Poppins). In Agile projects sprint planning is an important first step towards delivering value effectively. The planning process provides teams with an understanding of what needs to be delivered in the next increment of time and provides a platform for deciding on the approach they will take based on the up-to-date knowledge they developed during the previous sprint. Well started might not be the whole battle but it certainly makes the rest easier. Listen to the rest of the essay on the SPaMcast 289. Also on the SPaMCAST 289 Kim Pries is back with his “The Software Sensei” column. In this installment Kim’s essay is titled Schedule Cycles.  In the essay Kim talks about tasks and scheduling. I have shortened the introduction of the cast this week. I would like your feedback. Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it. Next week we will feature our interview with Jan Beaver, author of the Agile Team Handbook. Jan’s book provides team members with the resources needed not only to become Agile but to practice Agile. Upcoming Events ITMPI Webinar! On June 3 I will be presenting the webinar titled “Rescuing a Troubled Project With Agile.” The webinar will demonstrate how Agile can be used to rescue troubled projects.  Your will learn how to recognize that a project is in trouble and how the discipline, focus, and transparency of Agile can promote recovery. Register now!   Upcoming DCG Webinars:May 22 11:30 EDT – Agile User StoriesJune 19 11:30 EDT – How To Split User StoriesJuly 24 11:30 EDT - The Impact of Cognitive Bias On Teams Check these out at www.davidconsultinggroup.com  I look forward to seeing or hearing all SPaMCAST readers and listeners at all of these great events!   The Software Process and Measurement Cast has a sponsor. As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI's mission is to pull together the expertise and educational efforts of the world's leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.  Shameless Ad for my book! Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: "This book will prove that software projects should not be a tedious process, neither for you or your team." Support SPaMCAST by buying the book here. Available in English and Chinese.