I love it when someone who was in one of my workshops sends me a message saying something from the workshop worked well for them. Recently I have started telling people in my Certified ScrumMaster training workshops that far too many ScrumMasters talk too much. I tell them they need to learn a new skill – being silent! The graphic makes the point perfectly. In fact, it adds that if you can’t stay quiet, buy some duct tape!

Below is a message from a recent workshop attendee that really hit home and made me realize adding this little segment to the CSM workshop was well worth it! He had the patience required of a good ScrumMaster and the result was worthwhile.

Bob,

I wanted to share a story with you that I think you’ll appreciate.

First, some background:  I’m leading a large project that can hardly be called agile.  It’s basically fixed-scope waterfall with short development cycles, but I’m trying to take as much advantage of scrum principles as I can.

Coming out of my CSM class, my biggest takeaway in terms of things I could be doing better within the constraints of my non-agile project was to hold regular sprint retrospectives.  The first thing I did when I got back in the office was to put one on the schedule.  That first one took a little bit to get going, but I was careful to remember to keep my mouth shut and let the team do the talking, and they eventually identified a variety of things that had been working well and not so well.  I was particularly pleased with the fact that they came up with the same list of “not good” issues I would have identified if I had been doing the talking.

Since the CSM class, we’ve now held three sprint retros following very closely the guidelines you laid out, and the results have been incredible.  With each one, the team has identified the top 1 or 2 issues they want to work on, laid out a plan for addressing them along with a team conscience to keep them honest and followed through to become more productive and successful as a result.  They have fixed all of the issues I was initially concerned about; and although new ones have come up, they’re now quick to identify them and put a plan in place to fix them.

Here’s the kicker.  In our latest sprint retro completed last week, one of the items on the “working well” list was, you guessed it, the sprint retros themselves!  The team loves taking that time to figure out how to get better at what they do.  There’s no longer any prompting or patience required on my part to get the discussion going.  All I have to do is sit back, take notes and watch the team figure out how to succeed.  How cool is that?

From Brennon M. to Bob Hartman on November 15, 2011

Until next time I’m hoping I’ll be Making Agile a Reality^® for more of the people who attend my workshops!

Related posts:

1. The ScrumMaster Diaries: #3 – Becoming a CSM Dear Diary, I completed day 1 of my 2-day Certified ScrumMaster course...
2. New to agile? What does the ScrumMaster do anyway? I often have people ask me what a ScrumMaster does.  Interestingly, today...
3. The ScrumMaster Diaries: #2 – Making the Case to Become a CSM Dear Diary, Tomorrow I am going in to speak to Henry about...

Dear Diary,

I completed day 1 of my 2-day Certified ScrumMaster course today and I’m feeling a little bit overwhelmed.  I didn’t have any idea there was a prerequisite of reading a particular book.  Luckily not a lot of other people knew about that either so I didn’t look too stupid.  Nothing we covered today was particularly difficult, it was just new to me.  A whole lot of it seemed like common sense, but as was pointed out, common sense isn’t so common, especially in software development!

I thought it was interesting to cover the history of agile and scrum and then to compare/contrast different methodologies.  I wish we hadn’t spent an hour on it, but it was interesting.  I just don’t know how it will help solve the problem.  Maybe if I was still in the mode of “selling agile” to the company it would have helped.

On the other hand the parts about how the Scrum Master role differs from a traditional project manager role was VERY useful.  Changing from command and control to serving, leading and facilitating will be challenging for some people.  It won’t be hard for me since I never had any control anyway <ha>!

I also liked the estimating part a lot.  Again, it makes sense, but it is so different from what we normally do that I wonder how it will work.  I’m not so sure management will approve of playing poker, even if it is Planning Poker!

The last thing we did was a Scrum simulation.  That was a ton of fun, but I wish it did more to advance my learning.  I guess I got to see Scrum in action, but on such a small scale I’m not sure I learned as much as I would have liked.

Well, on to bed now.  Another full day of CSM training tomorrow!

- Nick

Dear Diary,

I am almost a Certified ScrumMaster (CSM) although I’m not sure why.  It seems too easy to sit in a class for 2 days then take a test you can’t fail.  Oh well, 60,000+ CSMs can’t be wrong.  It must be useful.

Today we dug into the Scrum process including the meetings, artifacts and roles a bit more.  We also discussed scaling Scrum and how to start up new Scrum implementations.  I learned quite a bit – I think.  It still seems like too much common sense, but I have to admit I probably wouldn’t have thought of most of it on my own.

I am glad that we covered all of the Scrum process in detail.  I now have a much better idea what each role is supposed to do.  They don’t map so directly to traditional roles.  I’ll need to keep that in mind when I talk to the group as a whole.  It will also be interesting to see how QA reacts when I tell them about estimating as a whole team and things get completed EVERY sprint which means testing more than just at the end of a project!

Tomorrow I meet with the rest of the team to fill them in.  It should be an interesting meeting!

- Nick

Related posts:

1. The ScrumMaster Diaries: #2 – Making the Case to Become a CSM Dear Diary, Tomorrow I am going in to speak to Henry about...
2. The ScrumMaster Diaries: Chapter 1 – We stink Dear Diary,   This is Nick.  I’ve never been much of a writer...
3. The ScrumMaster Diaries: Introduction to the series Back on September 23, 2009, I posted a blog entry titled “New...

Dear Diary,

Tomorrow I am going in to speak to Henry about becoming a Certified Scrum Master.  I’ve done more reading about it and it appears there are more than 60,000 people in the world who have done it before me.  Those kinds of numbers have to help me with my argument.  I also know the popular abbreviation is CSM.  Apparently I just have to attend a specific course for 2 days then pass a test and I get certified.  Who knows, maybe I’ll be certifiable instead!  Ha, ha!  The good news is we can’t get a whole lot worse than we are right now, so I hope Henry is open to the idea.  We’ll see.

-Nick

Dear Diary,

Henry asked me a lot more questions about becoming a CSM than I anticipated.  Luckily I caught him first thing in the morning.  He told me to take a few hours and do some more research.  The whole group is going to meet at 3pm to discuss all of our dev department ideas before another all hands meeting at 4pm.  I decided to take lunch here at home and do the research here.  I doubt anyone will miss me.  I just couldn’t take being at the office any more.  It is a bit of a downer right now.  At least I’m still excited, I just have a lot of questions to get answers to in the next 3 hours!

-Nick

Dear Diary,

Wow!  That was interesting.  To say the least!  We had our department meeting and everyone got to give suggestions about how we could improve.  It seemed like a total blame game.  Someone even used the phrase “blamestorming” which I found hilarious.  Anyway, we went around the room and I ended up being last.  Developers ended up blaming QA and ME!  QA ended up blaming developers and ME!  Managers ended up blaming QA, developers, marketing and ME!  It was totally crazy.  I felt like I had been set up.  Then someone made the suggestion that we wouldn’t be in this mess if I were a better project manager and maybe I should become a PMP so I could do my job better.  Well, that was the last straw!

At that point I totally lost it.  I AM A PMP!!!  Grrr.  Fortunately I was somewhat ready for the abuse and the blame game.  I kept my cool and told everyone I already was a PMP.  I also told them we had done pretty much everything by the PMBOK and still failed.  The person who said I should become a PMP had the nerve to ask what the PMBOK was!  Again, I stayed calm and told him it was the set of practices you had to know in order to become a PMP.

For some reason, remaining calm was working because I had everyone’s attention.  I decided to go for it.  I told them I thought we had to consider completely re-doing the way we created products.  We needed to think about using agile, in particular Scrum.  I then told them of my 3 step plan for implementation:

1. Convince them this could work (at least convince them enough to go to step #2).
2. Have me attend a Certified ScrumMaster course and get certified.
3. Start using Scrum with me acting as “coach” for the team to make sure we did it right.

Lots of questions, but some others, particularly devs were onboard right away.  They had friends using agile and/or Scrum and all were pretty positive about the experience.

Only one problem remained – we had to convince Bob it was the right thing to do since the course would cost $1200.  Fortunately there is a course right here in town starting in 2 days, so we all hoped Bob would get on board quickly.

Well, we didn’t have to wait long.  We had our all hands meeting and spoke about what we did during our week of vacation.  Cindy won the $2500 prize – easily.  She said she decided to relax by seeing a different old friend each day and just catch up on life. She did it by driving 2-4 hours each day since they all lived in different cities, and during those 2-4 hours she listened to books on tape she had been building up for years.  It sounded like she had a lot of fun.

Then it was on to the good stuff.  How were we going to improve.  Marketing started and said their plan was to have development increase resources so software could be released faster in order to keep our customers happy more often.  Bob pointed out the obvious – our problem isn’t the release cycle time, it is in how our releases are perceived.  Marketing then got nasty and said they felt if we did four releases per year at least one of them would be “good enough” for us to keep our customers.  Bob started his career in development, so this argument just didn’t cut it for him.

Then it was our turn to present for a few minutes and the department decided I should be the one to speak since it was basically my plan.  No pressure, right?  Ha!  I decided to be short and brief.  As best I can remember, here is what I said:

In development we’ve decided we aren’t interested any more in playing the blame game.  We want to be able to do something different which will make a big difference.  This is fundamental change which will involve everyone, but which will start in engineering.  If we can’t do our part, the rest of you don’t have to worry because it won’t work anyway.  But if we are able to do something different and better, then we think the company as a whole can dramatically improve.

What I’m talking about is something called agile development.  In particular a product development framework known as Scrum.  I know the name sounds silly, but please get past that.  From what I have read and what people in our department have heard from friends who have made this switch, Scrum can make a company more productive, improve quality and increase stakeholder and customer satisfaction.  In many cases it does all of these things by dramatic amounts.

Bob, we’ve put together a simple plan for adoption.  It is probably way too simple, but it is based on what we know today.  We want the company to spend just $1200 to send me to a 2-day course later this week to learn how to do Scrum.  Next week I would take that knowledge and start leading our group down that path.  We would like 6 weeks to see if it works for us.  We consider this time well spent and we will do everything in our power to make sure after 6 weeks we are in a position to say “this is working, keep going” or “we’re no better, so stop.”  Furthermore, we’d try to ensure the “failure” mode would not only be “we’re no better” but also “we’re no worse.”  This is basically a $1200 investment and trusting us to do our best.

I know trust has been hard to come by in this company lately, but I personally think that may be part of our problem.  Bob, unfortunately in order to make this happen fast enough I need to put you on the spot and have you say “yes” or “no” right now.

Then I stopped and held my breath.  Bob stood up and asked, “Henry, are you on board with this plan?”  Henry said he was.  Bob then asked, “Nick you asked for trust, and I’m going to go out on a limb and give it to you.  I know I’m going to upset a lot of people in this room by saying this, but go do it.  I don’t know enough about Scrum to be able to say no.  This points to a decision I made while we were on break – if I don’t have enough personal experience to say no, I’m going to say yes.  I need to trust all of you to do your jobs well because that is what we hired you to do and I know we only hire the best.”

Phew.  I did it.  Now I have to do it.  What the heck did I just get myself into???

-Nick

Related posts:

1. The ScrumMaster Diaries: #3 – Becoming a CSM Dear Diary, I completed day 1 of my 2-day Certified ScrumMaster course...
2. The ScrumMaster Diaries: Introduction to the series Back on September 23, 2009, I posted a blog entry titled “New...
3. The ScrumMaster Diaries: Chapter 1 – We stink Dear Diary,   This is Nick.  I’ve never been much of a writer...

I often have people ask me what a ScrumMaster does.  Interestingly, today it came up on a mailing list I read on a regular basis.  So, naturally that means it is time for a blog entry to talk about it!

I am a big believer in simplifying things, so let’s start with an overly simplistic definition for what the ScrumMaster does:

“A ScrumMaster removes impediments for the team”

It seems many people believe this to be the only thing a ScrumMaster does.  Maybe it was the way they were taught.  Maybe they misinterpreted something.  This is definitely not all a ScrumMaster does.  If it were, then a ScrumMaster could work with many teams at once.  While some do in fact work with multiple teams I agree with whoever said “A good ScrumMaster can work with multiple teams at once, a GREAT ScrumMaster will only work with one.”  In other words you can be successful working with more than one team as a ScrumMaster, but it won’t be possible for you or the team to reach greatness!

This definition is extraordinarily and unnecessarily narrow.  A great ScrumMaster can and should do so much more!  Let’s expand the definition a bit:

A ScrumMaster is a servant leader helping the team be accountable to themselves for the commitments they make

Hmm, a servant leader?  Accountability?  Commitments?  Uh oh, Houston, we have a problem!  Let’s take this one piece at a time:

is a servant leader - According to Wikipedia, in order to be a servant leader, you need to have to following qualities: listening, commitment to growth, foresight, and the ability to build community.  In addition there are several common characteristics of servant leaders including collaboration, trust, empathy, and the ethical use of power.  Notice in hear there is NO mention of management.  Let’s be very clear about one thing: leadership is NOT the same as management (see an earlier blog post on this topic)!  If the ScrumMaster doesn’t manage the team who does?  This is one of the beauties and difficulties of Scrum – the team is self-managing.  This leads us right into point 2…

helping the team be accountable to themselves – A team that is accountable to themselves implies they are managing themselves.  This is very important for agile teams in general.  Not having the ability to hold each other accountable causes friction.  Accountability is not micro-management.  It is the opposite.  It is the ability to EXPECT someone to do their work and if they don’t deliver, to hold them accountable and work together if necessary to improve the situation.  In most situations someone is given a task and then a task master of some sort continues to check progress.  Accountability means giving someone a task and expecting it to be completed unless an issue is raised.  Not doing this implies a person is not a team player which leads to lots of other problems.  Since we are talking about the ScrumMaster here let’s bring this full circle and focus on the word at the front of this piece – HELPING.  The ScrumMaster doesn’t do it, they help the team do it themselves.  HUGE DIFFERENCE!

for the commitments they make - Notice the ScrumMaster is not responsible for helping the team meet external commitments.  They are responsible for helping the team meet the commitments the team themselves made.  This may involve the team working as a cross-functional unit (breaking down silos).  It may involve significant collaboration among groups.  It may (and likely does) involve removing impediments (so this is where that came from!).  It may involve holding the team accountable to their commitment to the Scrum framework!  In the latter case this can often involve coaching the team in how Scrum works.  Finally, this may involve holding the team accountable to creating the highest value product possible (high value combined with high quality combined with high productivity).

How do you do all of this?  Well a good starting point is a checklist of things the ScrumMaster can look at and work on.  Michael James from Danube has an excellent ScrumMaster Checklist available for download.  I suggest downloading it and seeing how you are doing.  If you are a ScrumMaster are you up for the challenge of becoming a great one?

Now that I’ve said my part let me point you to the Scrum Guide available for free download from the Scrum Alliance website [update January 18, 2010 - the Scrum Alliance website now links to Scrum.org which hosts the Scrum Guide as published by Ken Schwaber, one of the original creators of Scrum].  In the Scrum Guide it states the ScrumMaster is one of three Scrum roles.  In addition it says:

“The ScrumMaster is responsible for ensuring that the Team adheres to Scrum values, practices, and rules. The ScrumMaster helps the Scrum Team and the organization adopt Scrum. The ScrumMaster teaches the Team by coaching and by leading it to be more productive and produce higher quality products. The ScrumMaster helps the Team understand and use self-management and cross-functionality. However, the ScrumMaster does not manage the team; the team is self-managing.”

I think my description is in line with this definition.  Good thing since I’m a Certified Scrum Coach!

Until next time I’ll be Making Agile a Reality^® by helping ScrumMasters recognize their full value to the team they help.

If you wish to become a Certified ScrumMaster be sure to sign up for one of our CSM courses at www.agileforall.com/csm.

Related posts:

1. The ScrumMaster Diaries: #3 – Becoming a CSM Dear Diary, I completed day 1 of my 2-day Certified ScrumMaster course...
2. As a ScrumMaster silence can be golden! I love it when someone who was in one of my workshops...
3. The ScrumMaster Diaries: #2 – Making the Case to Become a CSM Dear Diary, Tomorrow I am going in to speak to Henry about...

Question:  Which is better: a) Working nights and weekends to meet iteration commitments, or b) Admitting the commitment was too much and working normal hours regardless of the commitment?

Many people would say answer (a) is better.  I might even say that if it were a one-time anomaly, but too often it doesn’t happen just once.  The team ends up setting an artificially high velocity and are then asked to keep a similar velocity in the future.  As a result there are more and more iterations with impossible deadlines and the agile team begins to feel they are on a death march.  I even had one person in a course tell me their management had them all sign a document saying they would work nights and weekends as necessary because the company really needed the product as soon as possible.  Seriously?!?!  On an agile team???  Ouch!

99 times out of 100 my answer to the original question would be (b).  Work at a sustainable pace (no sandbagging allowed), determine a realistic velocity, and go on from there.  During the iteration retrospective an obvious discussion question would be why such an unrealistic commitment was made in the first place.  Sometimes it is just an anomaly caused by uncertainty.  That can happen occasionally and is no cause for alarm.  However, more often than not it is caused by a team trying to meet an artificial deadline and convincing themselves they can do it.  Don’t fall into this trap.  Death march projects are no fun and they may even be less fun when done in an agile way.  Seeing failure or ridiculous overload every two weeks can get to be horribly depressing!

Remember, a sustainable pace is one at which the team can perform for very long periods of time – forever basically.  I like to add the team takes pride in how much gets accomplished each iteration.  This helps prevent sandbagging because you can’t take pride in the amount completed if you sandbagged it.  Also remember sustainable doesn’t mean no vacations!  It is necessary for downtime to recharge.  Sustainable could even mean occasional overtime if the team chooses to meet their commitment in order to help them feel proud of the iteration – however this should not happen very often – if ever!

Project managers and Scrum Masters need to watch the mental and physical health of the team.  Be the conscience of the team when it comes to maintaining a sustainable pace.  Re-read that last sentence and ask yourself when the last time a project manager asked a team to reduce their hours because it wasn’t healthy!  If the pace of the team is not sustainable several undesirable effects are likely to occur:

1. Defects will increase.  Tired teams let more defects through.
2. Work output will decrease.  Tired teams do less work in more time!
3. Morale will drastically decrease.  This may lead to employee turnover at a most unfortunate time in the project.
4. The blame game will become common.  (Not our fault you didn’t say X.  I said X.  Did not.  Did so…)
5. The team starts to abandon good practices for those that “seem” faster.  Sorry, but test-driven development (TDD) is actually faster than just writing the code and throwing it over the wall to QA!

Do you have any funny stories about sustainable pace or a lack thereof?  If so, please post a comment.  I’d love to have examples to use in the future!

Until next time I’ll be monitoring teams I coach for use of a sustainable pace because there is no other way of Making Agile a Reality^® for the long term!

Related posts:

1. Agile antipattern: Moving work from one iteration to the next All agile teams start at something less than the completely proficient level. ...
2. Agile antipattern: Changing the definition of done Ever see a burndown chart like the one to the left?  I’ve...
3. Agile pondering: How does agile work with a team of 1? See that picture off to the left?  That is me and my...