The most important thing I learned today is that Scrum is NOT a best practice. There are rules for properly implementing Scrum and if you don’t follow these rules because you don’t like them, you are not doing Scrum. You may still be Agile, but it’s not Agile using Scrum. I previously thought the exact opposite. There are 3 basic fundamentals (the Scrum Skeleton) you must follow, basic rules you should implement as quick as you can and then there are optional rules above those. So you CAN define your flavour of Scrum with the optional rules, but you CANNOT break the skeleton or basic rules.
I also learned that it’s important to not force Scrum onto a team. Scrum works for certain types of projects that involve unknown or variable work like new product development, major software revisions or projects that require you to try stuff first. Projects involving teams of 5 or less people and a projected duration of less than 2 months probably won’t benefit from Scrum as it may be too heavy of a process. Other Agile approaches like Crystal or XP might work better in those situations. So here’s an update on my assumptions and questions before I started the course:
You cannot introduce new scope into a sprint. ever.
Correct. If the sprint must be interrupted, the product owner must take something out to put something in only if the Team is willing to accept the change. Mishkin gave us a great real-world example of this.
Your velocity should level off after a few sprints
We didn’t get into estimation and planning today, but touched this a few times. Yes, you should be able to measure and predict your throughput through a variety of methods (more on that in a future post)
The Team Should Commit to the Work
Correct. The PO prioritizes the backlog and the Team decides what to commit to.
The Team must agree on the definition of “done”
Correct. There is different criteria for different backlog items and it must be defined and agreed upon.
The Team Should be Accountable for What They Commit to
The jury is still out on this one. The Team members are responsible for what they commit to but is the PO or SM actually accountable? We didn’t get through answering this.
Above all else, communicate and be reasonable
Correct. The key is trust. Trust is implicit in Scrum. You must be able to trust your Team to do the right thing. There was a fantastic role-play exercise that demonstrated this. The whole class failed this exercise but learned a valuable lesson.
As for my biggest problems, we haven’t covered some of the material yet, but here’s where it’s at:
User Stories: We’ll cover this on day 3.
Timeboxing Tasks: We’ll cover this tomorrow but we did talk about strict enforcement of timeboxing sprint planning and daily standups, I assume there is a technique for timeboxing tasks.
Priorities and Dependencies: Simple, there are no dependencies in Scrum. The goal is to be able to work in parallel, not serial. Efficiency is lost when hand-offs need to happen as was demonstrated by one of the exercises we did. Priorities are simple as well, the PO prioritizes the backlog and any defects that happen during the sprint are the top priorities next sprint.
Team Adoption: We’ll talk about that in Day 2
Why am I, as a Scrum Master “planning the sprint”: Well, I shouldn’t be. I should be facilitating getting the work done, the Team should be involved in planning the sprint and setting the goals.
On tomorrow’s docket is planning/estimating and working in teams. Those are the biggies on my list, can’t wait.