Project management without meetings.
Meeting driven process is a roadblock to delivering better software.
Uclusion is a new way to communicate and track stories at the same time.
You make a few points, by example, that I'd like to address:
A) Sprint plans are not very flexible
B) Too many meetings
C) ROI on code reviews is not always there
A) causes many of the problems you talk about because when stories are blocked or need review your inflexible Sprint plan forces you to address everything immediately even if it ultimately wastes time context switching. Similarly being afraid to pull a story into the Sprint is again an artifact of sticking to a plan made a week or two ago.
B) - you mention a design review meeting as well as several resources you need stuck in meetings. Again as with A) stories in Scrum don't "pause" so everything is immediate and it's difficult to stay unblocked. But on top of that a face to face design review isn't a good use of time. Design is complicated and sticking it into a real time meeting isn't likely to help anything.
C) Where's the heat on these code review meetings really coming from? I'd guess there aren't many ways to get other's opinions on implementation before coding (other than the problematic design review meeting) so the code review becomes the whole shebang. That's unfortunate because if anything really wrong is found that late in the game it's a huge waste of time re-code.
All of A-C is a result of Scrum being designed when meetings were the only way to solve anything. I work on software that challenges meeting driven process and would love to see if it can help your team.
Full-stack developer working mostly with Laravel and Angular at my day job. I share stuff I'm learning by writing articles and posting videos on YouTube!
Pulling new work into "in progress" doesn't have to equate to being "not in the current sprint".
Code review can still raise issues even if everyone thought they agreed to a direction before work began. People misunderstand or misinterpret people all the time. People miss edge cases. They underestimate complexity. Ultimately if the code wasn't built in collaboration, there will be disagreements with the end result from time to time.
This doesn't even have to be a SCRUM team, they could have been working with KanBan or any other play on "agile" that involves releasing continuously in small increments.
There are so many things this team could try to improve on but what I think is interesting is that a lot of the issues really stem from this idea that work needs to be broken up to be worked on in parallel by multiple individuals as apposed to a group.
I still have to finish the follow up post to this (in the middle of getting ready for a move right now so I'm pretty busy 😅) but my idea is to try and communicate the benefits of mob programming.
Project management without meetings.
Meeting driven process is a roadblock to delivering better software.
Uclusion is a new way to communicate and track stories at the same time.
That fits in well with the meetup I am trying to organize on team structure meetup.com/san-jose-collaboration-... If you have time pop in and we can discuss your idea.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi @danjfletcher
You make a few points, by example, that I'd like to address:
A) Sprint plans are not very flexible
B) Too many meetings
C) ROI on code reviews is not always there
A) causes many of the problems you talk about because when stories are blocked or need review your inflexible Sprint plan forces you to address everything immediately even if it ultimately wastes time context switching. Similarly being afraid to pull a story into the Sprint is again an artifact of sticking to a plan made a week or two ago.
B) - you mention a design review meeting as well as several resources you need stuck in meetings. Again as with A) stories in Scrum don't "pause" so everything is immediate and it's difficult to stay unblocked. But on top of that a face to face design review isn't a good use of time. Design is complicated and sticking it into a real time meeting isn't likely to help anything.
C) Where's the heat on these code review meetings really coming from? I'd guess there aren't many ways to get other's opinions on implementation before coding (other than the problematic design review meeting) so the code review becomes the whole shebang. That's unfortunate because if anything really wrong is found that late in the game it's a huge waste of time re-code.
All of A-C is a result of Scrum being designed when meetings were the only way to solve anything. I work on software that challenges meeting driven process and would love to see if it can help your team.
Hey David, thanks for the thoughtful comment!
This is all hypothetical of course 😊
There are so many things this team could try to improve on but what I think is interesting is that a lot of the issues really stem from this idea that work needs to be broken up to be worked on in parallel by multiple individuals as apposed to a group.
I still have to finish the follow up post to this (in the middle of getting ready for a move right now so I'm pretty busy 😅) but my idea is to try and communicate the benefits of mob programming.
That fits in well with the meetup I am trying to organize on team structure meetup.com/san-jose-collaboration-... If you have time pop in and we can discuss your idea.