Scrum Agile works great. Keep it light and loose and watch the code fly. I don't know much about the other flavors or taking it too far into process but I've seen the amazing things Agile as a philosophy can do.
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.
> 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.
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.
Good point. I have to admit I never actually raised this point in a retro. Also because it's pretty subtle, and the planning meeting is always after the retro, so I forget about it by the time we get to the next retro. I focus on the content of the sprint itself, not the meetings around it.
I hope to address this next time. Or maybe I should just point it out before then.
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.