A lot of development organizations use Scrum as their preferred Agile process. Sometimes that's just what you'll have to go with. I was part of development teams before Agile was "en vogue" - we still delivered software in useful bits on time and within budget and with minimal preexisting specification. I'm not going to critic Scrum. Instead I will focus on how to change it to make it more pleasant for everybody involved. This is in-line with the Agile culture, which allows for adaptations and changes which benefit the team and the resulting product. Of course it will earn you some snide remarks from your Agile coach and you won't be allowed to call the process "Scrum" anymore, but maybe work will be more fun.
Stand-ups
Don't talk about the past unless it really has value. Coordinate for the day ahead instead. I don't want to know what you did yesterday or which meetings you're going to have. Tell me what you plan on working on next, what challenges you expect, where you might need some help. If you learned something valuable yesterday, let everybody now. Don't just tell me that you did, what you yesterday told me you would do.
Estimates
Don't estimate points, try to cut tickets into roughly the same size and just go by ticket count. Use grooming / estimation meetings to have deep technical discussions about how to evolve your product, instead of arguing about if it's 3 or 5 "points". Your development team's meetings should be used for design work and planning. Track your design decisions inside the ticket.
Sprints
I like a 2 or 3 week rhythm, but only if you really work on product features. Situations where you mostly have a bunch of random tasks and no clear goal to reach (maintenance work, ops tasks) are better handled with a Kanban-like process. Since your tickets should be the same size, try to figure out how many tickets you usually close per sprint. It'll take some sprints to settle and it's just a general goal post to indicate the amount of work you can perform in a set time-frame. Don't argue about burn-down charts, you will all know when you messed up a sprint and everybody will know why it happened. If not, discuss this during retro.
Reviews
The point should be to show your stakeholders the progress you made. This depends on how interested your stakeholders really are, I've seen nobody show up. If this happens, use the time for presenting parts of software to each other and present your learnings to the team. It's great if this turns out to be a knowledge sharing session. Either technical knowledge with your co-developers are maybe the stakeholders can teach you about the business.
Retros
Don't talk about things that you can't directly influence, that will just frustrate everybody (e.g. don't vent about management or your company culture). Otherwise these talking points will be part of almost every single retro, even though nothing can currently be done about them.
If you can improve the way you are working together, talk about that. Don't feel the need to improve, if everybody is fine with how it's going. Keep it short if no major points come up. I have seen teams "make up" constant "improvement work" and feeling uncomfortable when no follow-up actions where defined. I think there is a point of diminishing returns.
Conclusion
Most importantly, use your time wisely and make progress on your development goals. The "process" is supposed to help you get there faster. So please don't spend a significant amount of time arguing about "the best way" to be agile. There's none. Get started, see what works, throw out what doesn't, repeat (and don't forget to have some fun along the way).
Top comments (0)