|
Different teams handle Scrum in totally different ways. On my previous project, it actually felt quick and light and agile. From one sprint to the next, we could switch to an entirely different sub-project, planning poker was quick, we never got around to backlog grooming, but somehow that wasn't a problem. We got lots of stuff done. My current project feels more sluggish. Long planning meetings where just one or two people decide on the story points. Somehow we never really get all our stories done in our sprints. This isn't a big problem, but it makes you wonder how we plan this, and why we plan this. The main differences I can tell between the two: this project we have a lot more documentation. All on wiki, but on the previous project, be barely had anything, and just asked people what the idea was and then did it. But my current project is at a bank, so it makes sense they want more planning and documentation, and less just figuring it out as we go. At another job, our Scrum wasn't really Scrum. We had standups, but that was it. No sprints, no poker, no scrum board, no burn down charts. But what this article makes me realize is that that project may actually have been more agile. Very few formal planning meetings, lots of informal communication and programmers just doing what they're good at and calling the shots. |
When you raise this at retros, what sort of response do you get? I believe you can measure the health of a Scrum team by a) what issues get raised in a retro and b) do they get addressed?
The iterative aspect of Scrum is also very much about iteratively improving process.