Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Implementing Dual-Track Agile :: Lessons from the trenches @ITSpring.by May 2019
Similar a Implementing Dual-Track Agile :: Lessons from the trenches @ITSpring.by May 2019 (20)
Último
Último (20)
Implementing Dual-Track Agile :: Lessons from the trenches @ITSpring.by May 2019
- 1. Dual-Track Agile Lessons from the trenches Pedro Teixeira May 31, 2019 @_pteixeira https://linkedin.com/in/teixeirapedro http://napkin-talks.com
- 2. About ● 15 years working in Product-led companies ● First encounter with Agile was in 2008 ● Co-organizer of AgileConnect Lisbon ● What this talk is not Pedro Teixeira Product Agility Coach Engineering 160+ people @_pteixeira https://linkedin.com/in/teixeirapedro http://napkin-talks.com
- 3. A typical journey of a Team bulding a Product
- 4. A typical development Journey Why is this taking so long?
- 5. Single-Track 1. Surely they started with their best idea 2. Build+Learn Cycles 3. Misfit Product, Technical Waste and Team is Demotivated
- 7. Dual-Track Agile Earlier and Faster Feedback-Loops Fast Learning and Validation Can they use this? (Usability)Do our customers need/want this? (Value) Can we build this? (Feasibility) Shippable working product credits to Jeff Patton and Marty Cagan
- 8. Do the users need/want this? (value) We assume ours customers wants this Let’s experiment! If we have 1000 clicks our assumption is right #1
- 9. Can they use this? (usability) Can we build it? (feasibility) #2
- 10. Happy Path credits to Ant Boobier
- 11. Happy Path Everything happens at same time credits to Ant Boobier
- 12. Learn and adjust With different speeds and costs Adapted from Ant Boobier
- 14. Dual-Track Pitfalls 1. Discovery for everything 2. Decision-Making is hard and slow 3. Development is in idle, waiting 4. Dual-Track duel
- 15. Single-Track Dual-Track Build Product while doing Fast Discovery
- 17. Start with your customers Have a good understanding of the problem before jumping into a solution
- 18. Have a right-to-left approach Outcome over output Mike Burrows Agendashift.com
- 19. Have a right-to-left approach House needs first, which parts second
- 20. Race for the Minimum-Viable-Product (MVP) Minimum working-wow-Product Wow-Factor Usable Valuable Feasible Wow-Factor Usable Valuable Feasible Wow-Factor Usable Valuable Feasible This one
- 21. Race for the Minimum working-wow-Product Take an informed decision
- 22. vs Work a few experiments at a time Time and resources are limited
- 23. Be smart in collecting data Time-boxed, actionable. It will ease the decision-making
- 24. Keep the pace Soft-enforcement for decision-making Discovery Build Discovery Build Build Discovery Discovery Build
- 25. Experiment in your process High-Performance does not come for free Celebration is important … but don’t forget to be leaner in your ways of work (e.g. invest in achieving the same outcomes with less process)
- 26. Be a team of grown-ups Scale if you are in trouble Decision-making deadlock No continuous-improvement unfit process
- 27. Takeaways
- 28. Outcome over Output-factory Problem Validation before Optimizations Adaptive Plan over Strict Roadmaps Speed over perfection Learning over right and wrong Right Data over opinions Build while doing Fast Discovery Dual-Track Agile
- 29. Discovery is not optional But do it fast Be intentional in your experiments They should be actionable, time-boxed with a clear question to be answered Plan everything for a given cadence You keep the customer interest, the constant feedback flow-in, measure progress and have better alignments on dependencies.
Notas del editor
- Hi everyone My goal for today is to Give you a small introduction on Dual-Track Agile Share some lessons I’ve been learning in my teams that in Dual-Track Agile Who is not familiar with Dual-Track Agile?
- I’m one of the co-organizers of the AgileConnect Lisbon that happens every month, If you happen to be in Lisbon have a look on the meetup and feel free to come by And I love to share my experience and thoughs either on meetups, conferences like this one and on writing on LinkedIn and my blog Currently I help a Engineering department to be deliver the right product and on time.
- Come with me to a typical journey of a Development Team. Let’s call them the orange team
- Orange Team, Scott, Paul and Peter 6 Months ago they started Working in a new Product Running perfect sprints where their velocity was steady and increasing over time Over nights to deal with perfrmance issues First release after few months - experience New apikes, PoC and embarked in a serie of code refactorings. This is the approach #1 that I call Single-Track
- This is what I call the Single-Track Development They started with their best idea. Perhaps the only idea that came out from their most senior person in the room Validate the idea with product Leads to technical waste, misfit product and a demotivated team that lost the trust of their leadership.
- On the top layer the we have the fast learning and validation of ideas.
- First you talk with a customer, you take 2 months to have a stable version at the ends of the customer, and then we wants something different You need to do Continuous Discovery to lower the risk and validate those three aspects. Specially the revelante of what you are building
- Discovery for everything => Everyone wants to get backed-up with data to validate all their assumptions Decision-Making is hard and slow => This causes having too many data pointers to analyse, process, debrief and act up on Development is in idle, waiting => Leading to delay releases, because we are aulted waiting Dual-Track duel => and because managers start to ask, why is this not done yet we become having finger-pointing between people, specially between the tracks. And this breaks the team in two. WHen
- Let’s put the designations Single-Track and Dual-Track aside. What do we really want?
- Now I want to share my lessons until now, and I want to start by trying to use what you really want instead of using this metaphor that can be misunderstood We don’t want to Discover. Must sometimes we need to validate some ideas sooner.
- You had data a certain feature was not being used You assumed the experience was not good You changed the exprience and the data was still low If you had spent time with the customer you could verify the link was hard to see on the homepage - and that was the reason!
- I got introduced to this approach by Mike Burrows at Aginext London this year and aí found it a simple and elegant way to ensure we are being outcome driven. Why? Because we first neet to identify what are the outcomes, how we validate their accomplsiment and then we go backwards creating the backlog to ensure this happen. Let me explain with Legos.
- The minimum working-wow-Product important but it will allows us to focus our work and then take a decision based on the the customer acceptance.
- There many representations for what work cycle, I like this one because is simple and captures the important steps. I think we all agree that a development team has a limited capacity to work and focus. To do all the activities they need to fulfill all this cycle.
- Incorporating Fast Discovery is not easy The best teams I know are the ones that do experiments in their process. Try new ways to store the information from the interviews of yours customers They have someone who is accountable to make it happen and brief the results with everyone. New way of estimate New format for Sprint Reviews A new virtual board for remote teams A new technique for A/B testings High-Performance does not come for free.
- Brings a early stage called Product Discover That Marty Cagan, one of the most inspiring and though Product Coaches define as a …” Basically to help us avoid having a misfit product after 6 months coding.
- Let’s put the designations Single-Track and Dual-Track aside. What do we really want?
- Two tracks, two mindsets that work side-by-side within the team One that is focused in discovering which are the most important problems to solve today And other, that once those problems are captures, make sure they are built right, performant, securely and with a great experience. Everything happening at the same time.
- Orange Team, working in their product backlog in a serie of Sprints. This is what I call the Single-Track Development They started with their best idea. Perhaps the only idea that came out from their most senior person in the room Validate the idea with product Leads to technical waste, misfit product and a demotivated team that lost the trust of their leadership. This is the approach #1 that I call Single-Track