Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Finding The Agile Sweet Spot
Similar to Finding The Agile Sweet Spot (20)
Recently uploaded
Recently uploaded (20)
Finding The Agile Sweet Spot
- 1. Finding the Agile Sweet Spot Agile Leadership Series Charles Husemann Agile Enablement Lead / Agile Coach
- 2. My Context 25 years of the software development experience – Dev, BA, PM, SM, Coach 12+ years of agile development -mostly Scrum and Kanban with a dash of XP for flavor Things I frequently say - “Metrics are my jam” - “That seems sub-optimal” - “This is why we can’t have nice things”
- 4. “The future of agility is decreasing the time it takes to get something into production”
- 6. We want agile outcomes • Ability to innovate • Quickly respond to market changes • Leverage change for a competitive advantage • Ability to deliver small units of value quickly • Turn business on a dime (budget of a sprint/timebox) • Ensure we are building the right thing for our customers through fast feedback loops
- 7. Why are agile outcomes important? IT SAVES MONEY REDUCES RISK INCREASES CUSTOMER LOYALTY AND RETENTION HAPPIER EMPLOYEES
- 8. Agile
- 9. Something is missing from some transformations
- 10. What is the agile mindset?
- 11. The Agile Mindset An agile mindset is the set of attitudes supporting an agile working environment. These include respect, collaboration, improvement and learning cycles, pride in ownership, focus on delivering value, and the ability to adapt to change - Susan McIntosh
- 12. Why is the agile mindset critical? • Creates the culture necessary for teams to thrive and grow • Create psychological safety within your organization – failure is acceptable and expected • Leverage data from past experiences (empiricism) to adapt and improve • Teams take ownership and pride in their work
- 13. First steps to the agile mindset Understand the benefits of working differently Recognize that failure is an opportunity to learn Learn the benefits and limitations of empiricism Realize that this is a journey and not a destination Continuously learning
- 19. What does Technical Agility provide? Creates trust in our systems Releases become non-events Release more often Deliver value more frequently Adapt to the market faster
- 20. What’s the most expensive and time consuming activity we do to verify new code?
- 21. How does Technical Agility do this? Foundation built on automated testing Continuous Integration and Deployment (CI/CD) to find issues quickly Pairing/Mobbing to ensure code quality from the minute code enters the system Environment virtualization – allows for testing and experimenting closer to production environments
- 23. Costs of technical agility Code takes longer to write Tests need to be maintained Difficult to add to legacy applications Culture and mindset change
- 24. First steps to technical agility Start writing automated tests for new code Build a CI/CD pipeline Retrofit old code with automated tests as you modify or work near it Adopt a test first mentality Experiment with pairing and mobbing
- 25. Fast and frequent releases – that’s perfect right?
- 26. (Kind of but not really)
- 28. Have we created feature factories?
- 29. What's a feature factory? Features go into production without any regard to if users will get value out of them Focus on outputs (number of features in production/velocity) vs outcomes (actual stuff that users need/want) Technical Agility exacerbates the feature factory problem Feature factories lead to feature debt
- 30. …more than 50% of all software developed is not used or doesn’t meet its business intent Gary Gruver/Tommy Mouser “Leading the Transformation”
- 31. Feature debt Technical debt’s more attractive cousin
- 32. Calculating feature debt Total number of features in production – Features being used
- 33. Calculating feature debt Actual feature usage / target feature usage
- 34. Code in production costs money
- 38. What can we do about this?
- 39. Underperforming features should be targets for improvement or elimination
- 42. Why product management? Track how customers are using your product Identify the features your customers use and don’t use Ensure you are building the right thing for your customers Quickly adapt to the needs of your customer Avoid wasting time and money developing/supporting features customers don’t want or need
- 43. Hypothesis-Driven Product Management- It’s no longer good enough for to say, “I think users want this feature.” Instead, you need to ask, “What outcome do you predict this feature will have?”
- 48. Product Ops “Product ops builds a foundation for excellence by reinforcing product strategy with metrics, infrastructure, business processes, best practices, budgeting, and reporting.”
- 49. Not just for external facing applications Casino operator Caesars Entertainment now has about 260 internal software applications, down from more than 800 about 18 months ago - WSJ – “CIOs Crack Open the ‘Black Box’ of Tech Productivity”
- 53. First steps to product management New features should start with objectives and key results (OKR) Talk to your customers and watch customers them use your application Add telemetry into your application Use the telemetry to see how customers are using the application Talk to your customers some more
- 54. What if I only want to do some of these things?
- 56. Wrapping up
- 57. “The future of agility is decreasing the time it takes to get something into production”
- 58. “The future of agility is decreasing the time it takes to get something valuable into production”
- 59. Takeaways Technical Agility and Product Management are complementary practices – not competing ones The agile mindset is a starting point, but we need to have the ability to experiment and learn quickly Technical Agility is necessary to build trust in your systems and respond quickly to your customers Product Management ensures that you are delivering the right thing to your customers Everything you release should have expectations that you validate once it’s in production These things are great individually but combining practices is required for true transformation
- 60. Helpful resources (books not people)
- 62. Contact Info Charles.Husemann@insight.com / chusemann@gmail.com @chusemann https://www.linkedin.com/in/chusemann/
Editor's Notes
- Good morning – welcome to the Insight Agile Leadership Series Thank you for coming out this morning to learn a little bit about finding how to find the agile sweet spot– today we are going to talk about the intersection of the agile mindset, technical agility, and product management and why you need all three of these things in your agile transformation
- Before we start I kind of want to give you the idea of where this presentation came from
- Presentation somewhat inspired by Bob Galen at Path to Agility 2018 where he talked about how agility is becoming more and more about decreasing the time it takes to get something to production So that got me thinking about all of the things we do from an agile transformation. Along the way I started reading more and more about DevOps (technical practices) and Product management and that’s where this presentation comes from. The more I looked into it the more I realized that these three things are complementary and will lead us to the next level of agile
- Why are we adopting agile? The want to better meet the needs of the market Need to be able to respond to change faster Better relationships with stakeholders who are now part of the process Quality They want to deliver value faster and more often
- https://scrumorg-website-prod.s3.amazonaws.com/drupal/2019-05/EBM_Guide%20January_2019.pdf Have empiricism at the front Re-label Agile sweet spot - agile outcomes
- We had a team that released new features into production and within 10 minutes they were able to get feedback on it and within an hour they were starting to generate revenue Within a day they were able to tweak some features to make it more usable for the customer based on interactions It saves money Eliminates operating expenses by reducing defects Increases the effectiveness of capital spending Reduces risk Financial Technical Move up to why we are doing agile
- When I talk about agile – let’s not talk about a particular framework – let’s talk in generalities a bit
- Agile is more than just adopting a framework and its rituals and ceremonies It’s more than story points and sprints It’s not that hard to get from Zero to zombie agile in a few months – the real value is the adoption of the agile mindset and the culture that comes with it
- An agile mindset is the set of attitudes supporting an agile working environment. These include respect, collaboration, improvement and learning cycles, pride in ownership, focus on delivering value, and the ability to adapt to change - Susan McIntosh
- Agile mindset helps you develop some critical organizational super powers - Good showed this during project Aristotle
- The agile mindset is foundational to an organizations agile journey but it’s just the first step
- We need to have the ability to have experiment quickly in market so we can learn things as soon as possible
- Let’s go back to Bob’s central idea - How often do you release to production? Yearly Quarterly Monthly Weekly Daily Hourly We just released 10 features in the time it took to read this
- Why don’t we release more often? Lots of reasons - Some legal regulatory issues - Regression testing - Lots of teams migrating to production - Don’t want to break something in production? - Don’t want to impact users Customers can’t take frequent releases
- But what about your mainframe? Well IBM has tools to do all of this on mainframes- you can develop automated tests – build pipelines, and have CI/CD Automated tests from the mainframe could even be re-used if you ever want to replatform
- Writing tests takes a bit more time but the additional time it takes to write tests is more than saved in operating costs – 60-90% As your codebase evolves – your tests do as well There are mitigation strategies for legacy apps but that’s a separate presentation – there are ways to do it but it is difficult to
- So we’ve figured out how to deliver stuff quickly – fulfilling the answer from Galen but then something hit me – are we sure we are actually delivering value?
- So you shipped a few features Are your users/customers using it? Are they using it as much as you thought they would? Is it delivering the expected value to your customers? Are they using it like you thought they would?
- Rough count of the number of apps on your phone that you haven’t used?
- 65% of features are never used
- Feature debt - code Automated tests that must be run/maintained Impacts development of new features Cost to support the code Performance impact
- Feature Debt - UX Consumes critical screen/menu real estate Interface clutter – makes valuable features hard to find
- Reasons for underuse Was the feature marketed correctly? Is the feature discoverable? Is the feature usable? Do users need training on the feature? Did customers want/need it?
- IT’s very hard to kill features – sometimes you have to kill your babies?
- Agile talks about delivering value to the business but are we sure that we are delivering value?
- Need to deliver smaller and smaller features and ensure that they are performing as expected Not design thinking https://econsultancy.com/how-top-performing-digital-companies-use-product-thinking-to-succeed-stats/
- How do we get there?
- Talk to your customers It’s relatively cheap! They know that they want* They know what they don’t want
- Telemetry Add metrics/analytics to every part of your application Track how users are moving through your application Product owners/managers should be armed with data about how their application is being used What are your most popular/least used features If you can’t build telemetry into your application look for alternatives – database stats/server logs/ anything that provides information on how your users are using your applicaiton
- Yes this is really a thing and I’m sorry for foisting this on your if you haven’t heard the term before But this is a science and as we roll applications out to more people
- Remember code in production costs you money
- Intersection of PT and Technical Agility Push a feature into production that only certain users can see Test in production against production data
- Can do A/B testing to see if the feature is worth it
- DevTestOps Code coverage isn’t the best metric Continuous testing Product Coverage over code coverage Testing what gives value, based on customer usage
- Going back to the idea that inspired this I think Bob hit the nail on the head but I think we need to make one minor tweak to that phrase.
- If we add the word “valuable” to this I think this gives us exactly what we need for a direction of agility
- Thank you so much for coming out to hear me talk, If you have any questions about my presentation let’s talk about them now