Day 3 was all about Teams and the Scrum Master role. Had a couple of exercises that were pretty simple, but they were probably more simple to figure out after a few days of training. There were a couple of really key points that are going to help me and my company for sure.
To continue the theme, I’ll recap and update as per the format from yesterday’s post. In the interest of saving time, if I don’t list it here, read yesterday’s post as my opinion didn’t change.
The Team should be accountable
Actually, this really isn’t applicable in the sense of what “accountability” means in the business world. IE: mess up and get reprimanded or fired. The TEAM is responsible for what they commit to. If the sprint fails, the sprint fails. Scrum is designed to help teams learn through failure and get better as a team. The sprint does not fail because 1 person on the team wrote bad code or 1 person on the team forgot this or that. No sole person is responsible for that failure. It is important to learn from it and move on. Now if you fail multiple sprints (like all of them in a project) something is clearly wrong. Scrum has no methods for handling this, it’s designed to not fail if applied properly. Take that last statement with a grain of salt, Scrum isn’t the magic bullet and it’s not the only solution but if used right you decrease your chances of failure. If the sprint is interrupted and work is added/removed (the “it’s gotta get done” factor), the Team is no longer responsible for those commitments. Teams is a big discussion, I can’t possibly capture it all here, but they need the authority to succeed as well.
My Biggest issues:
User Stories: Damn, the vote on this optional module was too low so we didn’t talk about it too much but we did talk about product backlog management and I managed to get a couple key questions answered in sidebars. User stories are an approach to phrasing stuff on the product backlog. A backlog item (phrased in a user story or not) is simple the vehicle to a discussion.
The product backlog is only for requirements and features/improvements. Scrum used to teach that everything goes on the product backlog, however that has changed. It’s important that the Team understand that a story isn’t going to tell them the full requirements. The point is for the team to understand the business reason WHY the story is there and how to complete it. That involves talking to the product owner to make sure they’ve got a good idea of what the point is. It’s then up to the team to create the sprint backlog from that story. That includes everything required to mark the story done (remember the team defines what ‘done’ means.
We covered Product Backlog Management via voting on the optional modules. I’m glad we picked that one. It really helped with a couple of things. The biggest being what belongs on a product backlog. Stuff like “deploying the sprint work” doesn’t belong on the backlog. It’s implied that is going to happen because you will be providing a demo at the end of the sprint. Stuff like that can also sit as a sprint backlog item. IE: the product backlog item is “upgrade client 1 to version 2.0” (again, remember you don’t need to use user stories…) Your sprint backlog items could be stuff like upgrade the client project files, change the config, write a batch file to deploy the stuff….etc.
Another key with product backlog is that the Product Owner has the sole discretion to add/remove stuff from the backlog. The Product Owner talks about value, the Team talks about cost. The Team is not able to tell the Product Owner that the can’t do item 1 because of a dependency. It’s up to the team to figure out how to break that dependency, and of course, that only applies to software. Mishkin drew a great diagram that explains this.
And finally, albeit out of order in this post, we talked about the Scrum Master role. It basically summed up the stuff we learned all week, but more specific to the Scrum Master only. The Scrum Master’s purpose is to satisfy the stakeholders and provide visibility into the work being done so there are no surprises. The Team doesn’t report TO the SM, the Team reports to each other and the SM facilitates the learning of Scrum and removing obstacles for the team. We did some great exercises around SM scenarios as well. This module was pretty simple and the class all did well since by this time we all learned quite a bit.
To wrap it up, I managed to squeeze out a couple more questions particular to my situation and am proud to say I’m now a Certified Scrum Master. Now I support I can be one of those wankers that puts a big pile of acronyms after my sig since I’m an MCP and now an CSM!
Seriously tho, this was a great boot camp, tons to learn and I’m really quite exhausted. I have absolutely no problem plugging Mishkin Berteig of Berteig Consulting for a simply fantastic course. If you are new to Scrum, having problems implementing Scrum or need some validation or coaching, I would highly recommend them. The level of knowledge and experience was amazing. The message was clear, Scrum has rules. Follow them and you’ll have a great chance for success. Scrum doesn’t solve all problems and it’s not applicable for all situations or companies, use common sense in your approach to implementing Scrum but above all else, the rules are there for a reason. You should resist temptation to break them because you think it’s the right thing to do.
I’m excited and exhausted all at the same time, can’t wait to get to work on applying this in my company. Keep tuning in, these first few posts were chaotic so I could dump all my thoughts, but there is some great stuff coming.