As the saying goes, Scrum is easy, Implementing Scrum is hard.    My CSM course taught that Teams go through transitions during Scrum adoption and it typically follows the phases of forming, storming, norming and performing:

Forming: doing something new is always fun, shakeups seem to spark more interest and commitment

Storming: the team realizes that it’s pretty hard, management sees the process “failing”, critical that the Scrummaster remains a solid coach

Norming: the Team starts to get into a rhythm, more Scrum rules get adopted, the team starts to self-manage better

Performing: the Team “gets it”, they adopt XP practices, self-manage almost entirely by themselves and really crank out great value

Seems logical enough for me, and having spent the last 4 – 5 months re-implementing Scrum I can say these are the phases we went through.  I constantly refer back to my CSM training and am quite pleased I documented the process as far as where I was before it started and how I could relate what I learned practically.  There are many negative “Smell of Scrum” type of posts everywhere, I am choosing to focus on how we de-funk-ified the smell.

I’m sure most Teams new to Scrum go through these same transition phases, here’s some of the bumps we hit along the way and how we dealt with them:

Forming

We have a small team filling support, professional services and development so there is overlap with the folks in the group.  After some spirited lunch and learns with management and the team to point out what we were doing wrong, we all bought into the process.  That’s the short version, it can be rough to be told you are wrong, but the point is we were ALL wrong.  You fail, then you learn.

The Team was given 2 scenarios for handling the structure of the team, one being more client facing, the other strictly development.  These scenarios outlined the pros and cons for each and at the end of the day the team chose to have 1 team for all of it.  All was good.

Storming

The Team learned pretty quickly that the same people took the client related stuff and the same people took the development stuff.  All teams are different, some people are great at certain tasks, others, not so much but the point was they were resorting back to the way it always was and there was some visible stress amoungst the group.  I preach truthfulness and honesty constantly but it was understandable that folks didn’t want to call out other co-workers who they felt were under-performing.

Management was then starting to see lower productivity and they weren’t pleased, but I was happy the team was learning and re-iterated the importance of letting the team figure this out themselves with my coaching.

I introduced a few processes along the way:

• daily scrum tip: started with the foundations of scrum, truthfulness and then tips based on output of the previous day that would help
• Q&A: encouraged each team member to bring a question each day in “stump the scrum master” type of fashion
• $5 for being late to the standup (to prove a point, I was late on purpose the first day(shhh, don’t tell them!)  to prove to the team I am committed to the process and I am not exempt from this rule.)
• Scrum scorecard: rated how we were following the rules

The Team decided after 3 or so sprints they needed to keep the process, but split the team back into Client/PS and Dev teams.  Our retrospectives revealed some dysfunctional activities but we worked through them.  I could see the clouds clearing up so I knew we were coming out of it.

Norming

The business started prioritizing better and providing more visibility into what was coming down the pipe so the Team could now understand context of what they were building instead of “you tell us what to do, we’ll do it”

Since we were following the rules and clearing technical debt we really weren’t establishing velocity so we started estimating bugs for the sake of getting better at estimating.   I am sort of half-product owner as well as scrum master so I constantly hammered on business value and let the team decide how to achieve it.   As long as they understood the business value, they would do the right thing.

Initially the team wasn’t completing all the tasks in the sprint so there was always spillover but they got better at it as time went on.  We still miss a few tasks, but by and large we’re ‘done’ at the end to the point where it’s shippable and they can show business value at the demo.

Performing

After some pain, arguing, lower productivity and fun retrospectives the Team really started getting the hang of it and at the end of our last sprint delivered substantial business value and managed the sprint themselves.  To put some context around it, the Team originally thought the Scrum Master was a project manager and was responsible for organizing the sprint, creating the agile wall, setting up the demo, reminding the team to wash their hands after they use the bathroom etc.  When they hit this phase, they really understood that THEY are the process.

The business was also pushing for “more, better, faster” and has since learned that’s not the way to go.  Trust the team and you’ll get results.

These are a few of the things the team is doing now that they weren’t doing well or at all before:

• writing their own tasks and breaking their own dependancies
• creating their own agile wall (I always iterated that the wall was for THEM, not me)
• entering their own issues into our tracking system
• adopted TDD and work agreements/rules within the team (that was based on management drive priority of zero defects and “do it right, not fast”  That was based on a release the failed miserably due to “do it fast”)
• given value only, not a solution or a demand by the business
• defined done for tasks, stories, sprints and releases

In the case of the last sprint, the team was given a business goal and accepted the stories into the sprint.  During the sprint our architect came up with something that would provide much better ‘bang for the buck’ and the team accepted their own scope change into the sprint all the while keeping the existing scope intact.  Let’s just say they knocked it out of the park.

The moral of the story is, when applied properly, Scrum works.  I cannot stress this point enough, trust the team, support them and do not give up.  The whole company needs to buy in to the process or it simply will not work.  Scrum is easy, implementing Scrum is very hard and requires a change in mindset.  It doesn’t happen overnight and needs commitment.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

This video is a bit long (just over an hour) but well worth it if you are new to Scrum. Jeff Sutherland is the Co-Creator of Scrum and talks about why it’s so important to properly implement Scrum to achieve success with your projects. It’s a great insight into how Google implemented Scrum for their Ad Words project.

http://www.infoq.com/presentations/Agile-Management-Google-Jeff-Sutherland

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

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:

1. you cannot introduce new scope into a sprint.  ever.
2. your velocity should level off after a few sprints
3. agile is not an excuse for lack of planning
4. 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
5. 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.
6. 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.
7. the team must agree on what “done” means (and “done” can vary by story type, just be sure to define it)
8. The Team should be accountable for what they commit to.
9. 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?

1. 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.
2. 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.
3. 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?
4. 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?
5. 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?
6. 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.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.