Rilasciamo rilasciamo
2 likes170 views
The document outlines the transition of a development team from releasing three times a year to biweekly iterations, detailing the challenges, fears, and successes encountered during this shift. Key points include the team's adaptation to a more flexible release process, improved responsiveness to user feedback, and growing agility within the company. The emphasis is on the importance of collaboration, planning, and continuous improvement in delivering scalable and production-ready features.
![Similar to other
iteration builds
“The target date for GA is
approaching [...] so we merged from
dev to master and published in beta
[...]. This for us is the GA candidate,
and we’ll move it to production as
GA [...] unless something bad
happens”
And the Release?](https://image.slidesharecdn.com/rilasciamorilasciamo-181116094438/85/Rilasciamo-rilasciamo-22-320.jpg)
Rilasciamo rilasciamo
- 1. Rilasciamo Rilasciamo How we moved from 3 releases / yr to biweekly releases, and stuff
- 2. About ● Francesco Mapelli (it’s me!) ○ Android Dev @Funambol ○ Certified Scrum Master ○ Prof of Lean Development & Agile Methodologies @ Uni Insubria ● Funambol ○ White Label Cloud Solution ○ B2B2C ○ Zefiro.me if you want to try it
- 3. Context ● Company ○ Scrum ■ feature & platform teams (squad / chapter) ○ 3 Big Releases / Yr ● Android Team (Chapter) ○ Control of our processes ○ Mature team
- 4. ● We go in production 3 times / year. ○ Issues discovered late or after release ○ Release Date -> Stress & Fear ● After: bugfixing ● Can we do better? ○ We should release every iteration… can we do it? Stress
- 5. Courage We can do it!
- 6. Planning ● Goals, Steps, Expectations ● Document ○ For mgmt (?) ○ It seems we know what we’re doing ■ We don’t :-)
- 7. Goals ● Release every iteration a new production-ready build ● Keep retrocompatibility with old server version ● Use production to gather information & adapt
- 8. Steps ● Migration to git ● Better automation of release process ● Different approach to US & Iterations ● Adapt our code practices
- 9. Expectations ● Team growth ● Better product ● Potentially shippable product increment ● Faster reaction to issues / feedbacks (Team)
- 10. Expectations (Company) ● Better User Stories ● Better feature selection and split ● More focus on delivering value at every iteration ● Backward compatibility of a client with older version of the server ● General increment in agility
- 11. Drawbacks ● Initial overhead ● Help needed by POs, UAs, Graphics etc ● Feature toggles / hiding / disabling ● Risk of bugs in production
- 12. Fears Bugs in production There is something very important we’re missing We will deliver something half-done We will skip iteration builds We will have to fix things immediately We will have compatibility issues with server We will get bad reviews on the store Everything will crash and burn and we will be doomed forever
- 13. Let’s do it!
- 14. ...15 days later... ● Ugly icon in production (the designer was not aware we needed a new icon, we went with a suboptimal version) ● Missing message (bug!) ● Wrong empty view (bug!)
- 15. Fears ✔ Bugs in production There is something very important we’re missing We will deliver something half-done We will skip iteration builds ✔ We will have to fix things immediately We will have compatibility issues with server We will get bad reviews on the store Everything will crash and burn and we will be doomed forever
- 16. But.. ● Learned to think in advance about UI and book the designer ● Release script publish in beta ● Bugs fixed and released in two hours ● CTO saw a UI solution and discussed with POs ● Team tried a new feature and discussed timing & frequencies of notifications ✔ Bugs in production ✔ We will have to fix things immediately
- 17. in 3 months ✔ Bugs in production ✔ There is something very important we’re missing ✔ We will deliver something half-done We will skip iteration builds ✔ We will have to fix things immediately We will have compatibility issues with server ✔ We will get bad reviews on the store Everything will crash and burn and we will be doomed forever
- 18. ● The review highlighted a real issue ● We fixed the issue and replied to the user that the fix was coming soon ● He changed the review to 5 stars even before receiving the fix I had a problem, but the developer contacted me and he fixed this issue. Thanks for excellent support! ✔ We will get bad reviews on the store
- 19. ● We discovered we didn’t have a plan to handle the upgrade of the server to the new version with a client already on the newer version ● We discovered it before the upgrade happened so we were able to handle the issue with a couple of possible options ✔ There is something very important we’re missing
- 20. ● We released a feature that was half done. No big issue but this was unexpected. ● We added a few safety nets to prevent partially done features to be released in production ● Recently (last week!) we added Experimental Feature mode: the user can try the experimental feature even when it’s not completed ✔ We will deliver something half-done
- 21. From fears to opportunities 👻 We will deliver something half done 👻 We will have bugs in production 👻 We will get bad reviews on the store 👻 There is something important we are missing 👻 We will have to fix things immediately ☆ We can deliver features iteratively ☆ We will discover bugs earlier ☆ We can react quickly to user feedbacks ☆ We can discover what we’re missing ☆ We have the opportunity to fix things immediately
- 22. Similar to other iteration builds “The target date for GA is approaching [...] so we merged from dev to master and published in beta [...]. This for us is the GA candidate, and we’ll move it to production as GA [...] unless something bad happens” And the Release?
- 24. ● We’re still delivering every iteration ● Impacted positively the company processes ● The company expects us to release every iteration ○ For good and for bad :) ● Other teams started releasing more often ● Team earned respect Inside the company
- 25. ● Three scenarios ○ Sometimes it helps a lot ■ If we’re both focused we can iterate fast ○ Sometimes we have to figure out how to release them a recent version ○ Sometimes better to give them an older version ● It poses questions ○ For some we don’t have yet figured out the answers. That’s good. ● The value stream sometime has some waterfalls in it With customers
- 26. ● Team was key ● Remember the values? ○ Courage ○ Respect ○ Commitment ○ Focus ○ Openness ● No pushback from mgmt Some takeaways
- 27. ● It’s easier to take courageous decisions after you took one ○ In the last year: RxJava, Kotlin, pull requests “The worst thing that can happen is that it does not work” Wider takeaways
- 28. ● Cross pollination of practices - sometime moving team members helps ● Just one team can be your trailblazer or benchmark: others will follow, if it’s worth ○ In this way you can try different things in different teams, if you want ● Practices and different approaches are tools your company has in its arsenal. Availability of practices is good Change by example
- 29. Questions?
- 30. Credits ● The amazing pictures I used are courtesy of Clement127 - https://www.flickr.com/photos/c lement127