For Agility's Sake Kyle Spitzley

In this episode Arlo Belshee, Aaron Coville and Marc Denman discuss how small changes in our coding behaviors can lead to incredible results. Arlo believes we can achieve a bug-free world, Aaron agrees with him on some points of that... Listen to hear the debate and more:
Imagining a bug free worldWhy we waste so much time making and dealing with bugsThe average developer creates 3 bugs a day (even Senior Devs)What is “The insight loop” (16:36)Teaches you how to see code differently and How to refactor legacy code safelyYour engineering culture will create habits, some good some bad.Naming as a process (27:11): using nonsensical names for methods, like Applesauce, forces a habit of refactoring and naming with intentionality, but does it come at a cost?

In this episode, Sameera Moinpour, Sr. Director of Strategy Solutions at Workboard, explains how OKRs (Objectives and Key Results) can help drive better results for your team. OKRs are a key component of Amway's Agile Workflow Model, ensuring teams are clear on what outcomes they want and how they will measure progress against them. Listen to learn:
What are OKRs?How to keep teams aligned to common goalsWhere to integrate OKRs into your current operations cyclesShowing up to review cycles "already informed" instead of "to be informed"How to get started with OKRs on your team2 pronged approach to starting2 OKR Levers: Alignment and Transparency

Rituparna Ghosh, General Manager and head of DevSecOps at Wipro shares her view on Agile Leadership. Ritu will be the first to tell you, she is still on the journey of becoming an Agile and Servant Leader. 
In this episode we discuss:
How leadership styles have changed over the past 15 years - what used to be "nice to have" leader skills are now a "must-have."What it feels like to transition from "command and control" to "servant leadership."The importance of psychological safety in creating the space for team members to dissent.Respecting the hierarchy of competence OVER the hierarchy of authority - being the most senior person in the room does not make you the most competent. Today's leaders need to recognize the value of competence and ensure it is given equal, if not greater, importance to seniority.The importance of spending time developing new skills (too often it is deprioritized to "get something else done."i-shaped, T-shaped and Comb shaped skillsets.Attributing success to the team, but failure to yourself. Conducting blameless post-mortems or retrosBe a just and fair leader: balancing compassion, discipline and accountability. Set high expectations with your team and hold them accountable to it. Shifting between being the leader and being a member of the team.

In this episode Hannes Färberböck shares his rich, 20+ year history of agile and its various methodologies with us. Hannes is the Managing Director of Nagarro's Austrian operations and the had of their Testing Business Unit. He first started his journey by learning and applying Extreme Programming (XP), and then conducting trainings for other teams on XP. 
Hannes recalls hearing about the first ever XP conference, where many of the signatories of the Agile Manifesto were in attendance (before it actually existed).  
Looking back over time and seeing how agile has evolved, here are some of the changes that Hannes reflects on:
+ There is more than one process you can use to be agile+ Companies can (and should) adapt those processes to meet their needs+ DevOps significantly helps reduce silos between dev teams and operations (he sees the next best version as DevTestOps). - Continuous Delivery: while it has the right goals, it can unintentionally turn "burndown charts" into "burnout charts" where teams never get a moment to take a breath. To that last point, we discussed the importance of NOT ignoring or delaying your continuous improvement focus. Whether it be a technical area like refactoring code, or a more interpersonal area like building trust on the team, these things cannot be delayed because we have too many things to deliver. Instead, we need to make them a routine that becomes part of the fabric of the organization. 

Hear from Chris Mastnak, "Global Practice Lead - Agile Testing" at Nagarro, on what it means for QA/Testing team members to work in an agile environment. 
According to Chris, life in QA gets easier with agile. He tells a story of major User Acceptance Test events at the end of a large 9-12 month build carrying a significant amount of risk. It's simply too wide of an area to cover with testing after nearly a year of development. Thanks to agile, QA can be much more confident with testing because they're covering smaller batches of functionality.
Unfortunately, just like in a traditional, waterfall project, the greatest risks are pushed to the end of the timeline. This same cycle shows up sprint by sprint, with QA getting 1 day to test all of the stories of the sprint. The good news? On agile teams, this kind of an issue resolves itself after a couple of retrospectives. 
As your team gets better at delivering features more frequently, you're going to need to get better at regression testing (making sure everything that worked before is not broken by new features/code). Before you were doing this a few times a year, but now you're doing it every 2 weeks. Agile teams remedy this issue by automating everything they possibly can. According to Chris, manual testing is still very important, but automation has to become a priority across teams. Chris suggests starting with automation for regression testing and sticking to manual for exploratory testing to make sure the new features are behaving as expected.
What about teams that "don’t have time" to automate? Chris suggests looking for automation tools and frameworks that fit your team's situation. Aim to automate one story in each sprint, this will slowly build your automation repo. 
According to Chris, an interesting side effect of agile is that it creates a cross-over between Developers and Testers. On the one hand, Testers get more involved with the development and start to understand why a feature was developed the way it was, giving them a better understanding of the behavior they should expect from it. On the other hand, Developers get more involved in the testing and start to become better at spotting gaps in test scenarios or plans. Ultimately, the team's ability to build and test a quality solution significantly improves as they work together more and more. 
What does this mean for a QA Manager?
There's nothing in the Agile Manifesto about the role, nor is there anything in the Scrum Framework for QA Manager, so what do you do now? 
Aside from becoming a QA Coach and working to make your team of Testers the best they can possibly be, Chris suggests elevating your perspective. 
Start looking across development teams and consider how to elevate transparency of testing beyond one team (it's easy for one team, but how is it done across multiple dev teams?)Start advocating for automation beyond one single team to drive quality on a larger scale. Start anticipating what this years' big programs mean for QA. Start thinking about and advocating for what Continuous Integration or Continuous Deployment will require across development teams. Things you may have already been doing, but will help clear the path for your teams: Make sure your QA environments are well cared for Make sure your team is continuously honing its skills Make sure your team has the necessary tools to do a stellar job Still not satisfied? Chris points out that anyone at your company with a few years of Testing experience has likely accumulated a vast amount of knowledge about how your product works; which makes them a potential Product Owner. 

Daniel Eder, Enterprise Agile Coach from Nagarro, talks about the role of a leader in an agile organization (and more). 
When he realized that traditional development was brokenHis first organic agile transformationRole of a LeaderPeople oriented: aka making people awesomeCoach and mentor people to make wise decisionsRelieving the daily pains the team deals withProvide context and broader perspectives to implications of team decisionsEmbrace your technical expertise (but leave your title at the door)The greatest barrier to agile transformation, "uncertainty," and what you can do about itWhat to do when you don't have enough time for a coordinated transformation effort.