3 ms·
My current employer promotes scrum/agile, so we have sprints with company-wide sprint reviews. We don't get much value from them because there is little sprint
by oldsklgdfth 6y ago
My current employer promotes scrum/agile, so we have sprints with company-wide sprint reviews.
We don't get much value from them because there is little sprint planning, and 2 days before the review there is a push to figure out what is "done" to present.
I have worked on other teams that embraced the planning aspect better and it was a source of reassurance that everyone was on the same page.
The primary value (when I was on a team that did it "right") was the common context that was shared by all and represented in the kanban (literally, sticky notes on the wall and some masking tape). There was transparency and traceability. I'm not sure it made us more "efficiency" or "productive", but i removed a lot of frustration of being in the dark about what the team is doing.
- kevsim 6y ago> There was transparency and traceability That makes a lot of sense. Do you think you could have achieved the same thing with regular sync ups or prioritization meetings or discussions without worrying too much about what you'd get done the next X weeks?
- oldsklgdfth 6y agoI think it's possible, as long as there is a central place with all this information. > without worrying too much about what you'd get done the next X weeks We didn't worry too much about metrics or progress. We just had everything going on in sticky notes on the wall. You could walk in, look at the wall and get an idea of what's going on outside of what you are working on. Personally, I like whiteboards and sticky notes(gives you an excuse to get up and move around). But it can be jira, trac, a wiki, a textfile in the repo. I like knowing what's going on around me and how things fit together. Others like working in isolation and following requirements. In my experience, understanding the origin of requirements and the context is important to the dev process.