Cross post from tcollins.dev
Recently our development team switched to scrum. Before we adopted scrum we were using a more ad hoc process. We had ...
For further actions, you may consider blocking this person and/or reporting abuse
In my opinion, agile methodologies are not black and white; you can choose to incrementally adopt parts of scrum, or choose parts of scrum that benefit your team the most while leaving everything else the same, if it works well. Each team, and each development environment, is different.
The point of process isn't in mindlessly following the process, it's a guide to improve the underlying work. Ideally, you can wake up one day, decide "no more scrum", and hopefully, if the process you've been following wasn't a facade, you'd continue to keep doing more or less the same thing if it actually works.
I don't strictly follow any one agile methodology but I agree with the points OP mentioned in his article. Two of the most useful things I've taken from scrum is: a definition of ready, and, breaking up large tasks into "1 day" tasks.
Establishing a definition of ready is a huge success when it comes to communication. It allows you to actually establish what you need to do to deliver value, and facilitates breaking up the task, if needed. I've been on the wrong end of tasks that kept seeing scope creep, and kept getting stalled because after each hour of work we'd reach a point where we needed more clarification.
I also saw great benefit in breaking up large tasks. This allowed for more accurate estimates and working on features in parallel. One thing I learned is that you shouldn't break up a large task arbitrarily. Pick logical "seams" in the task, so that each unit of it still delivers value.
Very well put. I couldn't agree more!
I am not really a fan of SCRUM so much (stribny.name/blog/2018/05/why-scru...), so I wanted to ask you - why did you switch to it in the first place? Usually it is a management idea to implement SCRUM in the team (without understanding it), was that your case as well?
The change from us came from the developers on the team. We had used Scrum in previous companies and saw the advantages it brought. Before adopting scrum we found it difficult to triage late changes to a project. There was friction with gathering specific requirements. Progress on a project was difficult to track. For these reasons, we decided to adopt Scrum.
The main goal we had was to improve communication with stakeholders specifically around the gathering of requirements.
Another aim was to provide better estimations. We have external dependencies around our releases so accurate estimations are important to us.
I very much believe you get what you put into scrum. I agree that you need to have team members buy into the process for it to succeed. You need to follow the ceremonies and adapt them to your own team.