Day 2 – Certified Scrum Master Training
Day 2 was a great one for me and the material today helped quite a bit with some stuff I was struggling with. Of course I now realize I was struggling with some of this stuff because we weren’t really applying the Scrum principals properly.
So let’s recap what I originally thought, plus what I learned in day 1 and add-in stuff I learned today. There’s 1 day to go in the course so I plan on writing more concise and organized posts, but I really want to dump my brain first.
You cannot introduce new scope into the sprint. ever.
Well, I suppose I shouldn’t say never. Shit happens right? It is a strong guideline that after sprint planning and before the sprint review, new backlog items should not be introduced. It’s up to the Team’s discretion to allow this but the Stakeholder and/or product owners must agree to take something out. You should avoid this and it should not happen frequently. If it does, your sprints are too long.
Your velocity should level off
Seems I missed a biggie here. There is ‘planning velocity’ and ‘commitment velocity’ Big difference. You can’t predict the future obviously, but you can get better at estimating. When your ‘commitment velocity’ levels off, the team has success. Both types are really simple to measure and Scrum accounts for that.
The Team should commit to the work
No change in opinion, my assumption was right.
The Team must agree on what ‘done’ means
My assumption was right, but I learned a bunch of ways to deal with this that will help me apply it. There’s different criteria for a task, backlog item and sprint/release. IE: a sprint being ‘done’ means all the backlog items were completed and a demo was held to showcase the functionality completed whereas a task is done when the tests are written and pass or a code review is done etc. It is critical to agree on this however and there is no repeatable forumla that works everytime. Discuss, agree and get to work.
The Team should be accountable
The jury is still out, we ran long today and didn’t get to it.
Communicate and be reasonable
No change here. TRUST is hammered home with scrum. The Team will fail. It is important to TRUST them to fail so they can learn and self-organize better. Scrum has a framework and very well defined rules, but there’s no substitute for communication and reason.
My Big Problem List
User Stories: talked a bit about it, but that’s covered in day 3. A couple key points is that the backlog items (in the form of user stories) are requirements. A user story or backlog item is a vehicle that should lead to a discussion. It is by no means the be-all-end-all of the requirement. I hope we cover this as it’s an optional module on day 3. Another key was that backlog items are estimated whenever the backlog changes, NOT at the beginning of the sprint. Basically you keep a revolving door going so there is no downtime and long planning sessions to estimate stories.
Putting time against tasks: I am happy to report I was completely wrong and now I get it. Meeting goals matter, time doesn’t. There are formulas and metrics (burndowns) and those are all you need. There are some guidelines like 1 person can do 1 task per day. Math will tell you basically how much work can get done. Often time tracking is only used if you bill on time/materials or for bean counters but it became very clear that Scrum has no mechanism for handling time tracking at all or putting time against any backlog item/task.
Priorities and dependencies: similar to what I learned yesterday, but with some additions. Analysis, design, construction and testing happen throughout the sprint, almost chaotically but NOT in a waterfall fashion. IE: if QA is part of the team they don’t wait to test all the backlog items until the end of the sprint. The Team basically decides what their block are and, with help from the Scrum master, they break those blocks. IE: I can’t start this until Joe finishes that, BUT I CAN start the other thing. It’s hard to be idle.
Dealing with Interruptions: When you’re talking about scope creep, it’s simple. Something in, something out and the Team decides whether or not to accept the change. When it’s the unknown due to customer support that may or may not happen and the unknown of the effort to resolve the potential support problem, there is hope. This is a very long discussion, I can’t get into it here but I did learn a couple of ways to handle it.
Team Adoption: we didn’t get into the Team module, but we did talk about approaches for implementing Scrum from the ground up. The key was quick wins by demo’ing shippable software. Once management sees immediate impact, they are potentially more open to it. At the end of the day the best approach came down to “it depends…” which is common to Scrum. Only you know your environment and what works for one might now work for the rest.
Why is the SM doing the sprint planning? Same as yesterday but there was some added insight that helped me understand just how wrong my whole approach was for the sprint structure, planning and estimating. Well, not just MY approach, but the approach I inherited (No offense intended to those who know what I’m talking about but man, we suck ass at this and it’s soooo anti-Scrum it hurts!)
Day 2 retrospective: Day 1 and 2 gave me a lot of great tools for being a much better Scrum Master. I knew quite a bit of these Scrum principles by reading, but there is a huge difference between being Blog smart and actually being TRAINED on what is right. By ‘right’ I mean, ‘right according to what Scrum is and the rules of Scrum’. Scrum is easy. Implementing Scrum is hard and a LOT harder than most people think.
Day 3 we’ll talk about teams since it was bumped today (damn that points exercise!) and get deep into the definition and responsibilities of the Scrum Master. The day will close off with a case study, optional modules (crosses fingers for user stories!) and Q&A.
Day 1 – Certified Scrum Master Training
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.
More Agile Than Agile
Ok, so I ripped off the title from a Rob Zombie tune, however the point I’m making is that I’ve learned Scrum the hard way. I knew a bit of theory and was poured into a Scrum-like environment and quickly found that a lot of what Scrum preaches is just plain common sense.
Since I’ve always taken the common sense approach to project management, even in traditional environments with strict rules, I’ve got the added benefit of being more Agile than Agile.
I’m preparing for my Certified Scrum Master training which starts tomorrow and wanted to make sure I documented a point in time to express where I’m at and what I want to get out of it.
My stance on Agile, and Scrum in particular, is that there is a framework available that you and your organization should build on to define what your project process is and that the Team should be responsible for agreeing on how that process works. The PM or SM (scrumMaster) shouldn’t be forcing rules onto the Team. I also believe there are some core Scrum beliefs that should be the baseline for building your implementation of Scrum:
- you cannot introduce new scope into a sprint. ever.
- your velocity should level off after a few sprints
- agile is not an excuse for lack of planning
- the Team should be committing to the work they will complete. The PO (Product Owner) or SM should not be telling the team what work they will do. The PO should provide a prioritized list and then have the option of taking stuff out and putting other stuff in during planning
- visuals are good. write stuff down and post it on the wall. write notes on story cards, write down steps to demo the functionality in the story, write use cases on the card to help define your tests.
- the team is a democracy. if something isn’t working, find out if it’s not working because of Scrum or if it was just exposed by Scrum. Learn what didn’t work and agree on the output.
- the team must agree on what “done” means (and “done” can vary by story type, just be sure to define it)
- The Team should be accountable for what they commit to.
- Above all else, communicate and be reasonable. Nothing is black and white and stories leave room for interpretation. You should not expect for the team to go away with their 50 stories and come back when it’s done.
What’s the hardest stuff I’ve come up against?
- properly defined stories: “uh, the story didn’t say turn on my computer so I couldn’t do it.” Ok, that’s extreme, but different people interpret a story differently and it’s easy to fall off the rails when a discussion arises. I want to learn how to handle these type of scenarios to minimize the frustration and back and forth.
- putting time against tasks: I believe everything should be and can be measured. I’ve had others tell me that story points translate to effort not time. EVERYTHING is tied to time. If you’re velocity is supposed to level off (which according to Scrum, it should) then you roughly know the amount of time required given the points for a story. You know how much time is available in a sprint. (in an 8 hour day a person has about 5 – 6 hours of time when factoring in lunch, breaks, meetings, email etc) You know what the sprint velocity was at the end of the sprint and you know what the estimated velocity was at the beginning of the sprint. I was really bad at math in college but that ain’t rocket science. Find your formula and track it.
- Priorities and dependencies: Simple in Waterfall, look at the gantt chart. If there are 2 high priority stories and 1 is dependent on the other, do I as an SM really need to spell that out? Isn’t a team member smart enough to figure out that if they want to install this software they need to turn the computer on first?
- Dealing with unknown variables: in small teams where team members are responsible for customer support, how do plan? A support case can be a simple phone call or it can be a 2 or 3 hour distraction that derails the sprint. how do you account for it? how can you measure and estimate potential interruptions?
- Team adoption: here’s a shocker, people are different. Some are more disciplined than others and some are more ‘Agile’ than others. What are some techniques for helping the more disciplined team members be more agile while helping them self-manage more and not dictating how to work?
- Why, as an SM, am I ‘planning the sprint’? Shouldn’t there just be a prioritized backlog for the team to decide what to commit to? I find often we are trying to say “here is the chunk of work for this sprint, let’s point it.”
I’m sure I have more questions, but I’m really excited to start this training to fill in the gaps of what I’ve learned on the job and in books. If at all possible I’ll be twittering at www.twitter.com/jasonlittle
My goal is to become a more effective scrum master and empower the team. The TEAM should be recognized for their successes and as an SM, I should be the one to help them achieve that success by helping them work smarter and by leveraging what Scrum offers.
