implementing scrum

High Performance Comes When the Team Really Gets It

November 20, 2008 by Jason in implementing scrum | Leave a comment

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. Read More

Recovering from a bad estimation session

August 18, 2008 by Jason in implementing scrum | Leave a comment

Recently I posted about an estimate session that went off the rails. The next day I decided to cancel the daily stand-up and did an exercise to try and help us all learn about what went wrong.

First of all, there was a ‘brainstorm’ session where a supposed breakthrough happened about the feature that was to be built but I wasn’t at that meeting and for some odd reason nobody actually took down the minutes.  In lieu of that, I had the stakeholder, product owner and all team members write down their interpretation of what that breakthrough was as it related to the business problem and the agreed upon solution.

Each person read their selections aloud and then the team voted on whether or not they strongly agreed, somewhat agreed or didn’t agree at all.  To make a long story short, everybody wrote basically the same thing and they all agreed on what the value of the feature was and how they planned on implementing it at a high level.

I didn’t plan it that way, but we ended up walking through a story writing session using the same method I actually wanted to do a lunch and learn about.

What did we learn?

  1. Write down notes at all meetings.  I usually facilitate all meetings since I’m the scrum master and resident anal personality
  2. Do rough sketches of designs
  3. Enforce timeboxing
  4. The product owner doesn’t need to work in a silo, the team can help in story writing sessions to make sure everything is clear
  5. Most importantly, understand the business value.  That is the key

I wanted to wait until the sprint was over to post an update and I’m happy to report that the development for that feature was bang on.  It was actually one of the best practices of leveraging the Scrum practice we’ve used since I started.  The team understood the business value and executed the feature (which the goal was to show a proof-of-concept only) and most importantly a team member reeled in a couple of discussions to keep the story on track while the Scrum Master was dead. Well, dead to the sprint while being re-assigned on another short project.
I’m very pleased with how it all worked out in the end and we have more work to do to get this right.

Truthfulness on an Agile Team

July 14, 2008 by Jason in implementing scrum | Leave a comment

Great article on InfoQ about truthfulness on an Agile team.    I don’t think this concept is unique to Agile teams (or at least it shouldn’t be) and truth should be the foundation of any great team or company.   Having said that, I think Agile is particularly successful in raising these types of problems sooner rather than later.

Retrospectives are a great way to let problems rise to the surface quickly and there should be lengthly discussion and conflict in a retrospective meeting otherwise what’s the point?   It’s the job of the Scrum Master to get this stuff out in the open for discussion.  Given the chance, people will always do the right thing more often than not but a good technique I like to use is the ’5 whys’.    Keep asking”why” to widdle the complaint down to what the REAL problem is.

Obviously some Team members will see this as being told “you are wrong”, and that’s fine.  It’s more important to figure out what the problem is and whether or not Scrum exposed this problem, caused it or had nothing to do with it.  If an organization or team can implement a truthful and open culture, it will be successful.

← Older posts
Newer posts →

Switch to our mobile site