Podcasts about with agile

Agile in Hardware: Agile Transformation in a Hardware Organization, Wärtsilä Case Study with Henna Torkkola nd Maarit Laanti In this Agile in Hardware episode, Henna Torkkola and Maarit Laanti share the pioneering journey of integrating Agile practices into Wärtsilä's Marine R&D, particularly within the ambitious New Product Development (NPD) program for advanced engine technology. From fostering collaboration across the value stream to embracing simulation and hybrid Agile approaches, they offer insights into how Agile has reshaped R&D processes. Henna and Maarit explain how bringing Agile to hardware isn't about imposing frameworks but adopting a collaborative, flexible mindset that inspires productivity and innovation across teams. Starting with a Vision for Agile in Product Development Henna and Maarit delve into the origins of Wärtsilä's Agile journey, recounting how the NPD program, initiated in 2018, was envisioned to deliver faster releases, co-create with stakeholders, and establish a more satisfying work culture for program teams. Moving beyond traditional project stages, the company embraced Agile methods to accommodate real-time adjustments and maintain a competitive edge. “Agile success in hardware starts when you focus on the values behind the practices—not just calling it Agile.” Expanding the Agile Mindset Across the Value Stream Originally designed as an R&D initiative, the program expanded to engage the entire value stream, including sourcing and manufacturing. Henna explains how cross-departmental collaboration was achieved through inclusive events and ceremonies, bringing in diverse stakeholders from the start. This broad integration marked a shift from isolated R&D to a holistic approach involving the entire value chain, creating a product developed with inputs from every angle. “Cross-functional collaboration is crucial; bring everyone to the table early and celebrate wins together.” Integrating Manufacturing for a Smooth NPD Transition To bridge the gap between R&D and manufacturing, the team included design-for-manufacturing experts from the outset, ensuring seamless transitions and early feedback. The addition of quick real-world testing strategies like using a single-cylinder prototype and rolling-wave planning enabled the NPD program to adapt plans incrementally while collecting feedback earlier in the process compared to previous programs. “Invite manufacturing to R&D's early stages—you'll tackle issues before they escalate.” Blending Traditional and Agile Models for Hardware Innovation The team adopted a hybrid model that merges Agile's flexibility with traditional gate-check models, evolving over time as teams moved away from rigid milestones. By focusing on early feedback and iterative adjustments, they avoided process bottlenecks and fostered a product-centric mindset. “Don't get stuck on milestones; prioritize feedback loops to keep product goals aligned with real-world needs.” Simulation and Small-Scale Testing: Essential Tools for Fast Feedback Both simulation and small-scale testing proved essential to the program's agility, facilitating rapid feedback and enabling team alignment. With testing and simulation experts working alongside designers, the process quickly highlighted practical improvements, creating a more effective pathway from R&D concepts to production-ready components. “Invest in simulations—they give you insights much faster, aligning design with manufacturing realities.” Synchronization and Common Planning: Enabling Transparency and Efficiency Henna and Maarit underscore the benefits of synchronization and common planning cadences across the R&D teams, enhancing transparency and team spirit. These synchronizations empowered teams to independently manage priorities while aligning with organizational goals, creating an ecosystem where collaboration and autonomy coexist. “A synchronized cadence empowers teams, letting them take charge of plans within a unified vision.” Pivoting to Sustainable Fuel: Adapting Agile to Changing Requirements As the market focus shifted towards sustainability, the NPD program swiftly integrated sustainable fuels like ammonia into development. Thanks to the Agile-inspired adaptability, the program adjusted its trajectory, positioning Wärtsilä to lead in environmentally conscious engine development with a product-first mindset that welcomed change. “With Agile, your process adapts to change—making room for innovations like sustainable fuel in real-time.” Resources for Agile Enthusiasts in Hardware and Product Development For listeners eager to dive deeper, Henna and Maarit recommend: Flexible Product Development: Agile Hardware Development to Liberate Innovation by Preston Smith White papers on Agile in hardware, particularly those available on WikiAgile About Henna Torkkola and Maarit Laanti Henna Torkkola is an Agile coach at Wärtsilä's Marine R&D, focusing on Future Fuels and New Product Development. With expertise in banking and Agile transformations, she holds a Master's in Human Resource Management and is passionate about the cultural impact of Agile. You can link with Henna Torkkola on LinkedIn. Maarit Laanti, a pioneering Agile coach and co-founder of WikiAgile, is the author of the first PhD on Agile in a scaled environment. She has led transformative Agile initiatives at Nokia and contributed to the SAFe framework. A global authority on Lean and Agile, she is recognized for advancing Agile scaling in hardware. You can link with Maarit Laanti on LinkedIn.

Ben Webster, founder of Agile Underwriting Services, joins Dexter Cousins to discuss his journey as an entrepreneur in the insurtech space. With a passion for developing innovative insurance platforms, Ben has successfully built and scaled multiple bootstrapped insurtech startups from the ground up, turning them into profitable businesses. His extensive experience spans over 15 years, making him a true veteran in the industry. His deep understanding of the insurance landscape, combined with his technical expertise, enables him to drive transformative change and create meaningful value for both insurers and policyholders."The hardest problem is distribution. You can launch a product after 18 to 24 months of development, and then it's tumbleweeds." - Ben WebsterAbout AGILE UnderwritingInsurance brokers are being asked to do more with less with a range of tasks that drain time and eat profit.  With AGILE, brokers are discovering a more profitable way to sell insurance. AGILE Underwriting Services is a Lloyd's cover holder and insurtech MGA specialising in Casualty, Construction, Cyber, Financial Lines, Retail Travel, Wholesale and more. Find out more - https://www.agileunderwriting.com/About Todays showWe reflect on the impact of the COVID-19 pandemic on Ben's previous venture, Insured By Us, and the hard lessons he learned from that experience. Ben explains the success of the AGILE model focusing on niche insurance products and the benefits of having a diverse portfolio as he struggled to keep Insured By Us alive.Ben also shares insights into the challenges of finding the right people, navigating distribution and dealing with regulation in the insurance space. Some founder insights Ben shares in this episode:- Agile's diverse portfolio has helped the business ride the wave of market fluctuations.- The insurance industry is highly siloed, making it challenging to find people with expertise in specific niches who can be successful in a startup.- Distribution is the most difficult aspect of launching an insurance product, and AGILE has developed strategies to validate products early on.- Ben emphasises the importance of a growth mindset and the need for entrepreneurs to be comfortable with uncertainty and feeling uncomfortable.​"The writing was on the wall, and I knew that I was going to have to make redundancies. I wanted to do it as early as possible to make sure that people got a good payout." - Ben WebsterSubscribe Newsletter: https://www.linkedin.com/newsletters/fintech-leaders-7092732051488980992/Apple: https://apple.co/3D7NsPtSpotify: https://spoti.fi/3IzSViQSubscribe and like on Youtube: https://bit.ly/3tBlRmEConnect on Linkedin: https://bit.ly/3DsCJBpFollow on Twitter: https://twitter.com/DexterCousins

The next wave of aerospace is just around the corner, and a lot of that innovation is happening thanks to new, faster methods of development. “What's happening now is that companies are trying to understand how they take the lessons from Agile software development and apply those to Agile product development,” explains Dale Tutt, vice president of Aerospace and Defense Industry for Siemens. With Agile software development, you can build software and test it relatively quickly. “When you start talking about an airplane or an air taxi,” Tutt says, “it's expensive to build a prototype and test them, so you have to think about it in a different way and take a different approach. It really takes good program planning.” This new type of product development, where planes and other kinds of air transport are developed faster than ever, still needs to incorporate safety as a top priority, which creates new kinds of challenges. These kinds of products are different than smartphones or other consumer electronics, Tutt explains. “Part of it is driven by the safety and reliability you want to have—so that when you're flying around, you can safely operate the vehicle. There's a certain amount of durability and reliability that's built into the design of the product. The amount of investment that these companies or that an individual would make in buying one of these aircraft means there's an expectation that it's going to last a while, and that you're going to have value in that asset. It's a little bit different than some of the consumer goods that we buy, and it's more expensive to repair them than it is to replace them.” Balancing speed and efficiency of development is no easy feat when it comes to flying through the air. But Tutt believes we're living through incredible times where things we can't imagine now will soon become part of our daily lives.   “Whether it's high-speed aircraft and companies working on the next presidential hypersonic aircraft, or space exploration companies, or urban air mobility and air taxis—there are hundreds of startup companies that are going to transform how we move around large urban areas. And we'll be moving around in a more sustainable manner because it will be electrically powered. Pretty cool stuff. It's been a long time since we've seen this much innovation going on in aerospace.”

A defined way of doing projects is fine when you don't anticipate the requirements to change. The reality is, however, that a project with all requirements known upfront just doesn't exist. With Agile, you're reflecting and adapting on your process frequently throughout the entire project. You can adjust course rapidly (and cheaply). One framework for implementing the values and principles of the Agile Manifesto is Scrum. In this episode, we interview Peter Hundermark, Mentor at agile42, about his decades of experience with what works and what doesn't with Scrum. Join us as we discuss: - How being a jack of all trades taught Peter empathy - How Agile, Scrum, and Kanban relate to each other - Why you don't need Scrum everywhere - The necessity of finding a mentor and being a mentor - How to “grow a pair” of Scrum Masters within your org Check out these resources we mentioned during the podcast: - The Agile Manifesto - Humankind by Rutger Bregman - Plato's Republic - Peter's article about growing internal Scrum Masters Keep connected with The Agile CTO at Apple Podcasts, Spotify, or our website. Listening on a desktop & can't see the links? Just search for The Agile CTO in your favorite podcast player.

In this Big Fish episode, we are showcasing a learning session from #RPOACON2020 Virtual Conference in which Erin moderates a panel discussion with three Big Fish of the RPO world: Cory Kruse of Orion Novotus, John Hess of Advanced RPO, and Jason Krumwiede of Broadleaf Results. With Agile methodology from the world of software development as the backdrop, these leaders make the case for recruitment process outsourcing as a solution to the extreme volatility in demand caused by the Pandemic of 2020. In this honest and fun conversation on how the challenges of this crazy year have forced everyone - including RPO providers - to rethink the way things are done, Cory, Jason, and John discuss their challenges and solutions openly. Everything from using daily stand-ups to stay organized and nimble, to project-based RPO to remove risks, to using new technology in ramping down and up support quickly. It’s a wild ride, and we think you’ll enjoy the banter between these experienced competitors and “frenemies”, including their predictions for 2021! Other topics Discussed: Sourcing innovation to drive diversity wins Nimbleness with ever-changing roles and responsibilities Aligning tactical actions with strategic goals in an agile way Finding comfort in the chaos & learning to be okay during a lack of control Leveraging technology and balancing in-person interaction with clients The importance of self-awareness & self-reflection Connect with our #RPOACON2020 Speakers Cory Kruse - https://www.linkedin.com/in/corykruse/ John Hess - https://www.linkedin.com/in/john-hess-58a5532/ Jason Krumwiede - https://www.linkedin.com/in/jasonkrumwiede/ Connect with Erin Peterson Erin is a Global Talent Acquisition Consultant, Interim Leader, and RPO Advisor with PeopleResults. She has led TA and RPO globally for some of the most successful organizations in the world including Accenture, Aon Hewitt, and Amazon. She translates her unique global experience to help clients with TA strategy, employment branding, onboarding, candidate experience, and recruitment process outsourcing (RPO) decisions. Connect on Social Website: https://www.people-results.com LinkedIn: linkedin.com/in/erinpeterson Twitter: https://twitter.com/ErinMcPeterson

In this week’s podcast, Dan Neumann is speaking with Charlie Guse, the lead organizer for the Global Game Jam event in South Bend, Indiana. And today, they’re talking about going from zero to game in 48 hours!   With Agile teams — especially Scrum teams — they’ve got the notion of creating an increment within a timebox in Scrum between 1-4 weeks. Though this event is only 48 hours, there are many similarities and overlaps with one another. So in today’s episode, Charlie talks about how they go from zero to game in 48 hours and the facets of Game Jam that translate back into the work software developers do in their day jobs!   Key Takeaways What is the Global Game Jam? A global event where everyone starts at the same time and has 48 hours to create a game based on a certain theme (this year’s theme is “repair”) A great way to meet new people and have lots of new ‘aha’ moments! Not a competition How the Global Game Jam overlaps with day-to-day software development: Having a theme/concrete idea to rally behind makes it easier to make informed decisions about building stuff and helps everyone come together and contribute ideas A framework was developed for this year’s event so that next year they can iterate on the framework based on the feedback they receive There is an emphasis on trying to find what each person’s interests are and having them focus on those as opposed to ‘shoving’ them into a position based on their availability, skill, and need Cutting scope for the timebox (i.e. working together to find the core of what you’re trying to do and cut the excess until you have a core you can deliver on) If people are spread out in their own rooms there is less collaboration so open areas are better There is rapid prototyping, iterations, and cycles Lots of opportunities for networking and making connections   Mentioned in this Episode: Global Game Jam Charlie Guse Kintsugi AWS Lambda EVE Online   Charlie Guse’s Book Picks: Reamde, by Neal Stephenson   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

One of the sessions at D365 Saturday Philadelphia this past weekend was "Managing a D365 CE Project" by Jennyfer Hogeland, it was a great session. On one of her slides she described "Definition of Done", and that phrase stuck in my head. Done I don't know about you, but when I hear the word "Done", I assume something has completed. When I am "done" with a meal at a restaurant, they take my plate away, bring me my check, and the wonderful relationship I developed with my server comes to an abrupt conclusion. When the service manager at the car dealership leaves a message on my voicemail that my car is "done", I go down there and get it, and our relationship has concluded, hopefully forever, even though he seemed like a really nice guy. "Done" means something different in the software deployment world. Done times 100 With Agile methodologies, big projects are broken down into smaller parts. Fellow MVP Neil Benson can fill in all the details around this for you, and will probably correct everything I write here. For this post I just want to say, that for each of these smaller parts, there is typically a concept of "Definition of Done". Some people call this "Exit Criteria", which sounds equally terminal. Regardless, if your project gets broken down into 100 parts, you will get to "Done" 100 times. Kind of like when you complete your appetizer, and they take that plate away and put another one in front of you, except it would be a 100 course meal. Done as a Beginning It is not uncommon for a development team to feel they have met the "Definition of Done", only to find that the customer did not understand the definition in the first place. "What do you mean Done? What about xyz...?" It is not that hard to come up with a definition of done that your team understands, it is exponentially harder to come up with one that your customer understands. Their advance agreement is not a reliable signal that they actually understand what they are agreeing to. Why would a customer agree to something they don't understand? Often, it is because they don't want to appear like they don't know what you are talking about. They are content to understand what you mean, after you get there, and then renegotiate if necessary. Done as a Flag in the Ground One of the key advantages to your development team is creating several points along the path where they can plant a flag and say "This thing is done". It should protect both sides from misunderstandings, or at least limit the damage to either party when there are misunderstandings. If we waited until the end of a year-long implementation to say "Done", all of those misunderstandings will be a wave that will wash over everyone involved. Another fellow MVP Gus Gonzales recently did a podcast outlining these very issues using a real world case... case as in law suit. SOWs When engaging an implementation partner, it is quite common to have your discussions conclude with a "Statement of Work". A typical statement of work will attempt to define the deliverables and the costs associated with delivering them. It may have been created pursuant to a list of requirements from the customer, or several pre-sales phone calls or meetings. The lazy SOW says, "We will deliver all of the requirements from your list, which is attached, for $X dollars." A customer who signs off on that is an idiot, and the project is already doomed. A better SOW does not even reference the customer's list, but rather replaces it and covers each aspect, broken into chunks with a "definition of done" for each chunk. But, I would never give a customer one of these either. In fact, we don't give customers SOWs at all. Why SOWs don't work anymore I think SOWs were always a shitty way to create a contractual relationship, but never more so than today. All SOWs are ultimately agreed to at a "point in time". Back in the day, that point remained fairly static throughout the life of the engagement. Not so anymore, not even close. A month after that SOW was memorialized, new features were released that the SOW did not contemplate. Now what, do we continue down the path, or maybe look at whether any of these new features make more sense for one of more aspects of this SOW we are both bound by? If they do, do we both mutually agree to change the scope. Does that change in scope require a change in cost? Are we going to argue over that because you think I have you over a barrel? Am I going to be a dick about that because I actually do have you over a barrel? If we ultimately agree, what are we going to do next month when it happens again? It is little wonder that so many of these relationships turn out sour in the end, or worse, in litigation. Fed Up Several years ago, I got fed up with the broken SOW process. While I never put my foot on a customer's neck, they frequently assumed I was, because I could.  My Dad once told me that, "Leverage always exists, there is no such thing as neutral... who has it at the time, may not be clear". I can certainly recall being on the phone back in the day with customer making all kinds of demands, assuming he had some leverage, when in fact he did not. It is not a good place for the customer to be, and I did not like it either as you may have gathered from my last post. Our Pivot I decided that we were going to take a business risk, by no longer responding with SOWs... or fixed cost agreements. They create an antagonistic relationship from the jump. Our "risk" was whether customers would go along with the idea. We did not invent this idea, but at the time, it was pretty novel in our space, and still is. We developed a two-page agreement, where customers could pre-purchase blocks of time, the larger the block, the lower the rate. What could be done with this "time"? Anything the customer wanted. We also simplified the tiered rate structure into a single blended rate. The whole concept could be digested in about 3 minutes, without the legal department having to look for "gotchas". Many other partners told me that no customer, particularly large ones, would ever move forward on this basis. They were wrong. Since we launched it, we have helped hundreds of customers, including multiple Fortune 500 customers, and the freaking United States Navy. In fact, there as been virtually no resistance at all. Selling Time Blocks I still had many partners not believing that customers would engage this way, being unable to imagine their customers going along. I have also talked to some who said they tried, and had limited success. Compared to our 100% success rate, I decided that this was a sales problem for these partners. I know their customers would go for it, if they presented it the right way. The key point is that every customer who ever did an SOW or "Fixed-price" agreement was not happy with that model either. That trend is getting worse, which can easily be seen by searching for example "Accenture Lawsuit". Not to pick on Accenture, their current woes are just fresh in my mind, but SOWs and Fixed-price agreements are ending in litigation at an alarming rate today. How about instead of going down a path with a high possibility of failure, you instead try something that minimizes the risk to everyone. In our case, the maximum size block a customer can buy at one time is 80 Hours. Why? This means that every week or two, we both get to reassess our relationship. While leverage may still exist, it is more equalized. If you are not happy with us, then you can go another direction, the block was consumed, and we owe each other nothing. On the other hand, if you are a raging asshole, once the block has been consumed, I can say adios. But another thing I have noticed in this arrangement is there is seldom a need for the customer to become a raging asshole. In fact, I don't recall off-hand ever saying Adios to one. Agile-ty This concept dovetails nicely into Agile frameworks also. You can't get much more "Agile" than being able to redirect all energies in a new direction when new features are launched or other realizations are made by the customer along the way. No change-orders to argue over, no hard feelings, the river of effort just flows down whatever tributaries the customer wants it to. Hey, wait a minute "Steve, you seem to be glossing over a huge aspect for partners. Where we make the big money is when we come in way under cost, in your scenario this windfall would not exist!" First, I would say that you need to subtract from your windfalls on the winners, all of your losses on loser projects, and come back to me. If you ever chatted to a gambling addict, all they talk about are the times they won. But, if your winners do vastly outnumber your losers in dollars, then you would be right. This model assumes that your customer will actually get an hour for every hour they purchased. Which, by the way, is a other huge selling point! We obviously generate a margin on each hour sold, but there are no opportunities for a huge windfall with this model. Conversely, it is also impossible to end up upside-down on a project. Since customers pre-pay for the blocks, we also have no account receivable department and zero collection effort. A Win-Win? I think so, if the profitability of your business is dependent on windfalls from winners to offset losses from losers, then moving to this model will help you at least sleep. You can also move from having a few key customers who will sing your praises, to have every customer doing so. This certainly makes getting more customers a lot easier. When your prospect asks for a reference, it feels good to be able to respond with: "Sure, how about every customer we have?". I get that this approach is not for all partners, though I am not sure why. I also get that not all customers will go along, but I have yet to run into one. I am happy to discuss with any partner how we make this work, or any customer who wants to explore it as well.  

The O’Reilly Security Podcast: Shifting secure code responsibility to developers, building secure software quickly, and the importance of changing processes.In this episode of the Security Podcast, I talk with Chris Wysopal, co-founder and CTO of Veracode. We discuss the increasing role of developers in building secure software, maintaining development speed while injecting security testing, and helping developers identify when they need to contact the security team for help.Here are some highlights: The challenges of securing enduring vs. new software One of the big challenges in securing software is that it’s most often built, maintained, and upgraded over many years. Think of online banking software for a financial services company. They probably started building that 15 years ago, and it's probably gone through two or three major changes, but the tooling and the language and the libraries, and all the things that they're using are all built from the original code. Fitting security into that style of software development presents challenges because they're not used to the newer tool sets and the newer ways of doing things. It's actually sometimes easier to integrate security into a newer software. Even though they're moving faster, it's easier to integrate into some of the newer development toolchains. Changing processes to enable small batch testing and fixing There are parallels between where we are with security now and where performance was at the beginning of the Agile movement. With Agile, the thought was, ‘We're going to go fast, but one of the ways we're going to maintain quality is we're going to require unit tests written by every developer for every piece of functIonality they do, and that these automated unit tests will run on every build and every code change.’ By changing the way you do things, from a manual backend weighted full system test to smaller batch incremental tests of pieces of functionality, you're able to speed up the development process, without sacrificing quality. That's a change in process. To have a high performing application, you didn't necessarily need to spend more time building it. You needed better intelligence—so, APM technology put into production to understand performance issues better and more quickly allowed teams to still go fast and not have performance bottlenecks. With security, we're going to see the same thing. There can be some additional technology put into play, but the other key factor is changing your process. We call this ‘shifting left,’ which means: find the security defect as quickly as possible or as early as possible in the development lifecycle so that it's cheaper and quicker to fix. For example, if a developer writes a cross-site scripting error as they're coding in JavaScript, and they're able to detect that within minutes of creating that flaw, it will likely only require minutes or seconds to fix. Whereas if that flaw is discovered two weeks later by a manual tester, that's going to be then entered into a defect tracking system. It's going to be triaged. It's going to be put into someone's bug queue. With the delay in identification, it will have to be researched in its original context and will slow down development. Now, you're potentially talking hours of time to fix the same flaw. Maybe a scale of 10 or 100 times more time is taken. Shifting left is a way of thinking about, ‘How do I do small batch testing and fixing?’ That's a process change that enables you to keep going fast and be secure. Helping developers identify when they need to call for security help We need to teach developers about application security to enable them to identify when there’s a problem and when they don't know enough to solve it themselves. One of the problems with application security is that developers often don't know enough to recognize when they need to call in an expert. For example, when an architect is building a structure and knows there’s a problem with the engineering of a component, the architect knows to call in a structural engineer to augment their expertise. We need to have the same dynamic with software developers. They're experts in their field, and they need to know a lot about security. They also need to know when they require help with threat modeling or to perform a manual code review on a really critical piece of code, like account recovery mechanism. We need to shift more security expertise into the development organization, but part of that is also helping developers know when to call out to the security team. That's also a way we can help the challenge of hiring security experts, because they're hard to find.

The O’Reilly Security Podcast: Shifting secure code responsibility to developers, building secure software quickly, and the importance of changing processes.In this episode of the Security Podcast, I talk with Chris Wysopal, co-founder and CTO of Veracode. We discuss the increasing role of developers in building secure software, maintaining development speed while injecting security testing, and helping developers identify when they need to contact the security team for help.Here are some highlights: The challenges of securing enduring vs. new software One of the big challenges in securing software is that it’s most often built, maintained, and upgraded over many years. Think of online banking software for a financial services company. They probably started building that 15 years ago, and it's probably gone through two or three major changes, but the tooling and the language and the libraries, and all the things that they're using are all built from the original code. Fitting security into that style of software development presents challenges because they're not used to the newer tool sets and the newer ways of doing things. It's actually sometimes easier to integrate security into a newer software. Even though they're moving faster, it's easier to integrate into some of the newer development toolchains. Changing processes to enable small batch testing and fixing There are parallels between where we are with security now and where performance was at the beginning of the Agile movement. With Agile, the thought was, ‘We're going to go fast, but one of the ways we're going to maintain quality is we're going to require unit tests written by every developer for every piece of functIonality they do, and that these automated unit tests will run on every build and every code change.’ By changing the way you do things, from a manual backend weighted full system test to smaller batch incremental tests of pieces of functionality, you're able to speed up the development process, without sacrificing quality. That's a change in process. To have a high performing application, you didn't necessarily need to spend more time building it. You needed better intelligence—so, APM technology put into production to understand performance issues better and more quickly allowed teams to still go fast and not have performance bottlenecks. With security, we're going to see the same thing. There can be some additional technology put into play, but the other key factor is changing your process. We call this ‘shifting left,’ which means: find the security defect as quickly as possible or as early as possible in the development lifecycle so that it's cheaper and quicker to fix. For example, if a developer writes a cross-site scripting error as they're coding in JavaScript, and they're able to detect that within minutes of creating that flaw, it will likely only require minutes or seconds to fix. Whereas if that flaw is discovered two weeks later by a manual tester, that's going to be then entered into a defect tracking system. It's going to be triaged. It's going to be put into someone's bug queue. With the delay in identification, it will have to be researched in its original context and will slow down development. Now, you're potentially talking hours of time to fix the same flaw. Maybe a scale of 10 or 100 times more time is taken. Shifting left is a way of thinking about, ‘How do I do small batch testing and fixing?’ That's a process change that enables you to keep going fast and be secure. Helping developers identify when they need to call for security help We need to teach developers about application security to enable them to identify when there’s a problem and when they don't know enough to solve it themselves. One of the problems with application security is that developers often don't know enough to recognize when they need to call in an expert. For example, when an architect is building a structure and knows there’s a problem with the engineering of a component, the architect knows to call in a structural engineer to augment their expertise. We need to have the same dynamic with software developers. They're experts in their field, and they need to know a lot about security. They also need to know when they require help with threat modeling or to perform a manual code review on a really critical piece of code, like account recovery mechanism. We need to shift more security expertise into the development organization, but part of that is also helping developers know when to call out to the security team. That's also a way we can help the challenge of hiring security experts, because they're hard to find.

Speaker: Melissa Perri Over the past few years there’s been a push in the product development world to “make products that people love”. A great User Experience is now essential to creating a successful product. While many companies focus on having the best design and the greatest experience, they are still missing the most important step in product development - learning about their customers.With Agile and Lean gaining popularity in more companies, we talk about techniques to get things out to users faster. At the core of this has been the Minimum Viable Product. Unfortunately, many people still do not understand the MVP. Some see it as a way to release a product faster. Others are scared of it, viewing it as a way to put broken code on your site and ruin products.The sole purpose of Minimum Viable Product is to learn about your customers. This step that has been so overlooked and yet it is the most essential part to creating a product your customers will love. The more information you can uncover through experimentation, the more certainty there is about building the right thing. In this talk, Melissa will go over how to design the most effective product experimentations and Minimum Viable Products. She’ll explain how to get the rest of the organization on board with this method of testing, and how to incorporate it into overall Product Strategy.

Phil Abernathy is an Agile Leadership Coach as well as the founder and CEO of Purple Candor. His talk at the first-ever Business Agility 2017 conference is called "Structuring Your Business for Agility". Phil walks us through the maze of systemic organizational structures and processes of today's businesses. Seeing IT's successes with Agile, business and leadership are pulling it in and layering it on existing structures without realizing that they are setting themselves up to fail. With the KPI madness that gave rise to heads of innovation and service, Phil imagines "we will have a head of Business Agility". And at the bottom of all these heads is a single person, a Bob or Mary, who is completely lost. In this maze there are maze runners: individuals who know the bureaucracy and processes so well, they "know how to chase the work through the maze to get it done". Phil commiserates that "we still stick with the manufacturing, industrial era models to run in the knowledge-based economy" - but change is happening. With Agile, leaders are finally able to see the maze for what it is and, Phil believes, we're all in a good place to do something about it.SolutionsIQ Chief Technical Officer Evan Campbell hosts at the inaugural Business Agility 2017 in New York City.About Agile AmpedThe Agile Amped podcast series brings Agile news and events to life. Fueled by inspiring conversations, innovative ideas, and in-depth analysis of enterprise agility, Agile Amped provides on-the-go learning – anytime, anywhere. To receive real-time updates, subscribe!Subscribe: http://bit.ly/SIQYouTube, http://bit.ly/SIQiTunes, http://www2.solutionsiq.com/subscribe...Follow: http://bit.ly/SIQTwitter Like: http://bit.ly/SIQFacebook