I owe this one to one of the attendees of a recent Agile Concept class I delivered a couple of weeks ago.

Most folks are probably familiar with ‘the penny flip’ exercise to demonstrate the differences between waterfall and agile development.  For those who don’t it basically goes like this.
Part I

1. break the class into team sizes that make sence, 4 or 5 is good
2. give each team a bunch of pennies, designate a time keeper and identify the ‘goal’ where they need to put the pennies
3. have the 1st person flip the first penny and then pass it to the next person in line
4. repeat step 3 until the penny has been passed through all team members.  The final team member places the penny in the goal
5. record the time.

Part II

1. follow the same setup as the first part
2. give the team the goal of getting the pennies into the ‘goal’ area but tell them they can do it however they want.  Make sure they still flip them first.
3. record the time

Observations:  In part I you will notice all the people in the room are looking at you and asking you for direction.  In the 2nd part, you will notice the teams huddle together quickly and form their own plan.

Results: empowering the team allows you to go faster, less time wasted in handoffs and you are focusing on the value of the goal instead of telling the team how to get to the goal.

Everytime I do this exercise most teams approach it the same way and the results are usually similar.  The 2nd part is done much quicker and the team works together.  They usually observe the same behaviour and both teams improve even though they may employ different techniques in Part II.  One team took an interesting approach that I haven’t seem before.

In part I the first person decided to stack all the pennies in a pile and flip the whole pile and then pass it to the next person.  KA-BOOM!  Big Bang happened and all the pennies ended up on the floor.

So here are some ideas I was thinking about trying next time:

• Modify part 1 so there is a ‘done’ area and then a ‘production’ area.  After they flip all the pennies, they need to stack them in a pile on ‘done’ and flip the stack into ‘production’.  If it blows up, the team needs to pick up each penny, flip it and then do the same thing again until it works.
• Introduce some changes mid-way through – decide that the product owner wants to have all the tails of the pennies facing down.
• Simulate the differences in releasing small piles of pennies over time as opposed to the whole stack at once.
• Have a QA period in part I where the last person in line is told they need to make sure all the heads are facing up, but don’t tell the folks that are flipping them.  Have the last person pass any defects back to the team.

Overkill for this exercise?  Would love to hear your thoughts!

Related posts:

1. Learn the Secrets of Collaboration…From Your Kids One of the simulations I like to facilitate during...
2. Simple Exercise to Demonstrate Value of Collaboration This is a quick and simple exercise I ended...

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

I’m glad to see the Scrum Alliance is taking steps towards a better testing process to designate certification, especially with the recently released CSM exam objectives.

There are some widely varying opinions on the validity of Scrum certification but I think, much like any education, it’s not the sole means of determining qualification for a position.

The naysayers will argue that a 2-day (which is now 3-day by the way…) CSM class only serves to dilute the quality of Scrum Masters in the industry and is somehow de-valuing and undermining the Agile world.  Their argument is that “Agile” is being mis-represented by giving folks a designation that is being misconstrued by companies that are hiring these folks.  These companies get a false impression of Agile because they ‘hired a CSM’ without experience and ultimately Scrum or Agile fail which leads them to believe that the Agile myths are valid.

When I first drafted this post, the tone was more about companies getting what they deserve if they hire someone with no experience, regardless of what job they are filling.  After re-reading it a couple of times, I decided to ‘be more agile’ and put my energy into suggestions that could help improve the value of the certification.

What Companies can try:

1. Get educated on what Agile is and understand what they are in for.  They need to understand one ‘certified’ person isn’t going to come in and wave the magic wand.  It’s a team effort to make a new agile adoption work or fix a failed one.
2. Understand what CSM means.  Sure it’s just a 2-day course, but it means the person has received a quality education and understands the Scrum process even though they might not have practical experience.  As with any education, it’s only as good as how it’s used after being obtained.
3. Shouldn’t only interview CSM’s, don’t put the sole value on a piece of paper.  IE: put “preference given to someone with CSM designation” instead of “CSM required”
4. Bring in a panel of cross-functional folks to interview the person, make sure they will fit in the environment.
5. Have them participate in a real-world scenario.  A true scrum master would thrive on an opportunity like this to prove themselves.  Any reluctance and you know they aren’t the person you want.

The Noob CSM

1. Be Honest.  Yes I realize you can’t get experience without having some experience, but don’t pretend you are something you are not.  Setting an expectation upfront that your are capable only for the company to find you are not is far worse for you AND them than it would be to maybe look for a more junior role with a smaller team/company.
2. Focus on helping the company understand you have the knowledge and tools to make Scrum/Agile succeed but that it’s a team effort
3. Take the time to understand Agile adoption successes and failures and you will notice there is a common theme to them.
4. Learn, learn and learn.  Join Agile communities, participate in Agile forums, start or join a local Agile user group.  Being a ScrumMaster is not a 9 – 5 job, it’s a learning job that requires dedication.

So am I in favour of certification?  Well, as usual, it depends.  In certain circumstances, I am.  I believe having an education from a qualified trainer/institution gives you a solid foundation to start with.  The reverse is also true, I know some folks plenty smarter than me that have no certifications so I don’t take too much stock in it.  You can read  books/blogs and get the same knowledge but be wary of “scrum-but” or “agile-but”. Those are much worse and do far more damage to the industry than someone without practical knowledge and experience does.

No related posts.

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

6% left on my battery and no power cord in site so I’ll be brief.  The workshop didn’t get into tactics or execution details but it gave me and the team members a great insight into the product owner role.  The biggest statement that stuck with me was that early on Jeff mentioned that it is impossible for one person to fill the ‘product owner’ role.   Sure there is ‘one’ product owner, but that person needs to be supported by a team and not locked in room to figure it all out themselves.

My takeaways:

- mapping user stories to a ‘narritive’ or timeline to help understand the product and how users use it
- how to build a better product backlog and plan releases

More to come….now where’s that power cord…

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.