Discussion Episode 20: public final Agile

[sockeqwe]

No description provided.

[ghost]

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!

[artem-zinnatullin]

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 :)

[arturdryomov]

@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.

[ghost]

Hi,

1. 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.

2. 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?

3. "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".

4. You allow to add/remove tasks in already running sprint?

5. You leave some time (1 day in each sprint for example) for support, critical bugs, or other unexpected things?

6. You have dedicated person for "sprint demo" or each platform members demonstrate what they achieve during last sprint?

7. You have "daily standup" meetings daily? :D

8. You send to stakeholders or write somewhere (on dedicated Slack channel for example) "daily standup" meeting statuses?

9. How strict if for your team to log time correctly and set statuses on time?

10. You follow some rules, conventions or templates about how to name or describe an task or to describe logged work?

Thanks! )))

[arturdryomov]

@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.

[ghost]

@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.

[arturdryomov]

@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.