CapnDave |
Guess I’m a Scrum But…..and damn proud of it! Once again we go back to my complete dislike of the current state of A… (I still refuse to utter the “A” word) Rules! If you’re truly A.., if you are truly flexible, there are no rules….just guidelines. If you begin enforcing “rules” like iteration lengths, stand-up or no stand-up, etc., then A… just becomes another rigid – my way or the highway – process. Rules? We don’t need no stinkin’ rules!
Yvettefrancino |
Cap’n'Dave! Great to see you out here! I still want to nail you down for an interview! Love to hear from someone who doesn’t mind speaking up for his beliefs!
Shillu13 |
I have to say I agree wtih capndave. I like agile with a small a. We follow the daily scrum but really its not a stand up, sometimes it lasts longer than we want it to. We also tried to follow the rules but then started modifying it to fit what our team needs to do.
Nkannan11 |
I am a proud Scrumbut also. So what’s your objective? Pray at the altar of Agile and get a Certificate that you followed every rule there is to follow or Develop Software in a better way? I propose the term “ScrumFiend” for those zealots who adopt the rituals of Scrum without understanding the Lean Principles behind it. If you understand why Agile works, you would not be so anal about the rituals!
Mschedlb |
I see this quite a bit and often team fail to realize that many of the Scrum practices are risk mitigation strategies. “Cherry Picking” exposes projects to additional risks. So, if you choose not to apply a certain Scrum practice, then you simply need to understand the risk you introduce to your project and determine some way to mitigate the new risk. Short iteration lengths, daily meetings, co-location, and so forth are there for a reason — ignore them at your own peril.
Yvettefrancino |
I love to see the comments and debate here! Which rules (if any) do you think are the most important in Scrum?
Shillu13 |
Mschedlb – I agree with [I]‘Short iteration lengths, daily meetings, co-location, and so forth are there for a reason — ignore them at your own peril.” [/I]
The struggle we are having in our team is that we are moving from extreme waterfall to agile and the transition has not been easy for everyone in the team. We have to give in (or give up some rules) to get the best we can from the team.
Vszalvay |
Yvette, and others,
I think you’re mistaking Cohn’s (and [A href="http://blogs.danube.com/scrum-is-hard-and-disruptive"]others’[/A]) warnings about ScrumBut for over-rigidity of the Scrum process. The expectation is that Scrum/Agile will be tailored. Eventually. What’s problematic is when people tailor Scrum before they’ve mastered the underlying principles. The “rules” are actually designed to cause some pain and thereby surface organizational issues and impediments that need addressing. Many companies will simply predict that XYZ rule will cause some pain and promptly remove it from the process without realizing that they’ve done themselves a disservice.
I’ve seen plenty of organizations take early shortcuts that lead to trouble down the line. Some of which include:
- Ignoring the call for collocated cross-functional teams because “QA is all located in India”
- No single person named to “Product Owner” role since no one wants to sit in the hot seat (or because people are too busy)
- No ScrumMaster because the role is not well understood and management considers it wasteful
- No timeboxing b/c we have “complex” problems to solve here
- No clear “done” criteria on Stories/Backlog Items since that “takes too long”
- this list goes on and on
There is a difference between doing these things from a place of understanding their full consequences and doing these things on day one because you can’t think of a convenient way to do it. I think that’s general warning call against doing “ScrumBut”.
Good luck to all of you embarking on Scrum.
Ethele |
Our “ScrumButs” that seem to work: (1) We have short discussions during the stand up. The whole team has been good about self-regulating these into meetings when needed, and 1 minute of discussion with the whole team often saves hours of work without the overhead of a separate meeting. (2) We report how we spend our time in our daily scrum meeting as part of “what did you do” – just how many hours spent on each Scrum task. It’s greatly helped with identifying weak spots in estimation. (3) Our iterations are only 3 weeks. I’m not sure why, since that policy was started before I joined the team, but it works fine. (4) We have one remote team member who never attends anything in person, as he is a couple time-zones away. He attends every scrum meeting by phone, and is good at maintaining open lines of communication with the team. He also used to be co-located, which does seem to help, since most of the team once worked with him in person.
The one “ScrumBut” that I think has bitten us is accepting unclear “done” criteria for a Sprint. No one likes making specs, so often we end up working out specs with the chickens as we go . . . which often hurts QA velocity, since any tests written early on have to be checked over and often rewritten as the spec changes. Our team has started being pretty insistent on reviewing the spec before accepting a feature for a sprint, and that has helped tremendously. Avoiding “verbal specs” in favor of a wiki page with a Q&A section for every sprint story has also helped deal with small details that weren’t foreseen when the specs were written
I think there’s a point where teams realize that Scrum is helping them a lot, but they still need to tweak processes to fit their people. Scrum seems to naturally encourage this, even, through the “retrospective” meeting.
rules, Scrum, ScrumBut
Comment
RSS Feed
Email a friend
