Comments (7)
Hi @ming13 ,
@artem-zinnatullin Mentioned that at Juno you have an great agile/scrum working process.
Maybe some day you will write an post about how sprints are usually going in your team (from planning to review).
I'm sure your insights will be very helpful for our (and many others) team ))
Thanks!
from thecontext-podcast.
Hey @VasileUngureanu, sorry for late reply (I need to be better with my emails)
I've tried to describe my experience in the podcast, a blog post can be a good reference though, I've added it to my todo list, but can't give no ETA nor guarantees :)
from thecontext-podcast.
@artem-zinnatullin, you are still under NDA, better make someone to describe Lyft style in the engineering blog.
@VasileUngureanu, like Artem mentioned basically the whole process was described by him and Alexey during the podcast. For a developer it is usually visible as refinements, plannings and retrospectives, plus reasonable backlog organizing during these sessions. If you have any questions — please ask, I’ll try to answer them.
from thecontext-podcast.
Hi,
-
You play "Scrum Poker" with all team (android, iOS, frontend, backend) together or by platform?
In our case we are small team (1 member for each platform) and we play "Scrum Poker" together.
Our results are not so good because for example i (Android) need to decide (to guess actually) what amount of time is necessary for an backend task. -
You keep "non business" feature tasks (technical depth, tooling ...) in the same backlog or in separate one or even in separate backlog for each platform? Also that backlogs can be filled with new tasks/ideas freely or tasks should be sent to dedicated persons who will decide if that task can be added to backlog and it's priority?
-
"Story points" really works for you?
We tried to use them but without success, maybe is need to start with an more simple variant like "Shirt Sizes". -
You allow to add/remove tasks in already running sprint?
-
You leave some time (1 day in each sprint for example) for support, critical bugs, or other unexpected things?
-
You have dedicated person for "sprint demo" or each platform members demonstrate what they achieve during last sprint?
-
You have "daily standup" meetings daily? :D
-
You send to stakeholders or write somewhere (on dedicated Slack channel for example) "daily standup" meeting statuses?
-
How strict if for your team to log time correctly and set statuses on time?
-
You follow some rules, conventions or templates about how to name or describe an task or to describe logged work?
Thanks! )))
from thecontext-podcast.
@VasileUngureanu, OK, that’s a lot!
You play "Scrum Poker" with all team (android, iOS, frontend, backend) together or by platform?
We have an experience with doing refinements with both platform teams which was pretty good actually. Two teams together can provide a better product feedback than a single one. Regarding plannings — nope, we have a different understand of tasks complexity since we have different implementations. Oh, and don’t involve backend into this, they have a totally different understanding of issues. Try to do a mobile-only one but still, the implementation and points would differ.
You keep "non business" feature tasks (technical depth, tooling ...) in the same backlog or in separate one or even in separate backlog for each platform?
Everything is in the same backlog. Using plannings we decide what will be picked in the next sprint. That’s it. Oh, and features of course have priority over tech tasks, but nobody will stop you from doing something from backlog if the current scope is done.
"Story points" really works for you?
Yep, it works pretty well. It might not work for you because the goal of points from my perspective is to share your abstract complexity estimation within the team and you pretty much don’t have one if you are working alone. Anyway, just try to make your own gradation and iterate over time.
You allow to add/remove tasks in already running sprint?
Generally no, it is a bad idea. But, again, if the current scope is done, nobody will stop you from doing something extra. At the same time, nobody will force you to do something extra, especially from features backlog — it will just lead to lesser focus and worse quality.
You leave some time (1 day in each sprint for example) for support, critical bugs, or other unexpected things?
Nope, that should be put in estimations. For example, if you have an important improvement — create a story. The quality suffers — something is wrong with the process or you need some time to improve the codebase. Unexpected things are bad and cannot be solved this way, it is a long-run strategic goal.
You have dedicated person for "sprint demo" or each platform members demonstrate what they achieve during last sprint?
Generally it is a single person but anybody can do it if necessary or wanted.
You have "daily standup" meetings daily? :D
We do, but we moved it online in a form of Slack QA sessions via a bot which reminds you to post an update.
You send to stakeholders or write somewhere (on dedicated Slack channel for example) "daily standup" meeting statuses?
Product owners generally don’t really care about technical tidbits and all statuses can be tracked via a tracking platform (JIRA or whatever).
How strict if for your team to log time correctly and set statuses on time?
No way we are gonna do time tracking, it is too stressful and useless with story points and all that. Time tracking basically means that people don’t trust you and force you to be efficient which fails horribly every time and there is a shelf of books proving that.
You follow some rules, conventions or templates about how to name or describe an task or to describe logged work?
Generally none, just a common sense.
from thecontext-podcast.
@ming13 Thanks for such detailed response to all these questions ))
From your responses i see that we do many things differently and we can improve our flow considerably.
from thecontext-podcast.
@VasileUngureanu, the general suggestion I can make is to simplify everything and react to painpoints iterating over approaches. There is nothing really perfect. Also, you have to be in sync with the product roadmap — if management pressures you to make new releases with new features ASAP without a glimpse of retrospective, unfortunately nothing will save you. On other hand, pointing weak sides generally helps. For example, 10 % of our userbase have crashes which leads to its shrinking, that might happen because our sprints are too short with too many tasks to do. But, again, not everybody actually listens. Project management involves people and that’s the hardest thing to solve in software development.
from thecontext-podcast.
Related Issues (20)
- Episode 22: Women in Tech
- Episode 23: Rise of the Machines
- Episode 24: Ok Multiplatform with Jesse Wilson and Egor Andreevich
- Publish on Spotify? HOT 9
- Transfer the repository to the dedicated organization HOT 5
- Episode 25: How It’s Made — Freeletics HOT 6
- Episode 26: How It’s Made — Juno
- Episode 27: Reusable Components with Sebastian Kaspari from Mozilla Firefox
- Episode 28: Fun with Canvas with Rebecca Franks HOT 3
- Interested in participating in a "How it's made" interview - Babylon Health HOT 4
- Episode 29: How It’s Made — Babylon Health with Sakis Kaliakoudas
- New feature request: publish to Google Play HOT 12
- Discussion Episode 16: Tools HOT 10
- Rename Markdown files so they're sorted by numbers HOT 3
- Update <itunes:owner> to mention Hannes and Artur.
- Discussion Episode 17: Switching Gears to C# and .NET
- Discussion Episode 18, Part 1: Android Everywhere
- Discussion Episode 19: Model-View-Intent HOT 1
- Discussion Episode 21: Rx Must Die HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from thecontext-podcast.