Author: Cherie Silas

(This post is by guest blogger, Kenny Barnes.)For our latest retrospective, I created a jeopardy board using JeopardyLabs – Online Jeopardy Template.   I used a mix of Agile related categories (Scrum, Agile), items related to the team [Working Agreements, Sprint (more details below)] and something the team is really passionate about (Star Wars).  It took about an hour and a half to come up with the questions/answers and setup the board.

“If you want to be a CST, do something about it. Get out there. Join the Agile community. Go to user groups. Go to conferences. Speak at conferences. I want to see you and know who you are. And you can never stop coaching.  You can’t be a good CST if you aren’t coaching. That’s where everything you know comes from. That’s where you gain your credibility and true expertise that can help people.”

This week I was walking past a conference room where a Scrum Master was preparing for the team’s retrospective.  I had to stop and take a picture because I really loved what I saw.  Here are a few of the things that really impressed me.

This is me.  I’m an agile coach and I love being a scrum master whenever my path allows me to step into that role for a few months in order to start up new teams and develop scrum masters.  I’ve been scrum mastering a few teams for the past couple of months and having the time of my life!  But now comes the real test – mentoring a few brand new scrum masters.

This is Mark.  He challenges me.  He confronts me.  He inspires me.  I think he is amazing.  Mark doesn’t do things because someone like me who claims to know a bit about agile says so.  He looks at the world from every perspective. I love this about him because he forces me to think deeper than I’ve ever had to in many areas.  He stretches me as a coach and forces me to keep growing.Definition of Done was an area where Mark really inspired me to dig deep.  This was his concern …“I hear and see people teaching Definition of Done like it is a checklist of all the things a team has to do in order for a user story to be done.  I think this undermines ownership of quality code by the team because the checklist becomes a crutch and an excuse to be mediocre.  It causes people to say things like, ‘Well it meets the definition of done,’ when they know that the code still isn’t as good as it could be.  It develops the attitude of, ‘Oh well, it wasn’t on the list so I don’t have to do it.'”

At an open space event the other day a group of people were pondering the topic “Getting people to be engaged during meetings.”  Inevitably the conversation turned to retrospectives.  People described how some teams complained about being forced to have retrospectives and how others went without complaint  but didn’t really participate.  Some of the frustrations were that introverts never want to participate and have fun conversations with their teammates.In short, some scrum masters were describing ways that they have been trying to pull their teams into a place of participating but weren’t being successful.  Teams were feeling forced to do something they didn’t want to do and scrum masters were frustrated because no one wanted to play this very important game with them.As I stepped back from the conversation I began to realize that what was missing was the understanding that there is an art to being able to facilitate an effective retrospective that starts long before the meeting.  The scrum masters role in the retrospectives isn’t simply to facilitate while people to talk about what went well, what didn’t go well, and what will we do to improve in the next sprint.  It is about creating new awareness.  It isn’t about pulling people into the conversation.  It’s about creating space for them to learn and grow and innovate in order to become higher performing.

Over the past several weeks I have encountered multiple people from completely different companies that are implementing scrum.  Some have been trying this for a few weeks.  Some have been doing it for a couple of years.  Others are somewhere in between.  Some received formal training.  Some read books.  Others supplemented with You Tube videos.Everyone I spoke to had a different reason for meeting with me, an agile coach.  Some were people I was interviewing for clients to hire onto their full time staff.  Some were clients and potential clients.  Others were people in the agile community that asked for mentoring.They all had something in common – doing it alone.  In each case, they got information about scrum and tried to implement change.  In each case they are struggling.  Half of the struggles they are facing are around simply understanding how to implement the scrum framework properly.  This stems from brain overload and trying to cram too much understanding into their minds from a two day class or a book and attempting to remember it with no context to their real world.  Then, trying to implement the things they learned in their own environment while not forgetting anything.  Yeah, right.

How can I keep the daily scrum from becoming a daily status meeting? But if we are all answering three questions then who is supposed to be asking the questions?  If we are gathering to give our updates on these three questions every day on what we are doing then that sounds like a status meeting to me – what am I doing wrong?These are all questions that I have heard new scrum masters ask.  The daily scrum seems like it should be the simplest thing we do, right?  The team self organizes daily for a time box of no more than 15 minutes and talks about three things:  What I did yesterday, what I am going to do today, and what is standing in my way.So, why is it so hard?  In my experience … mindset.  Often, scrum masters learn a process to implement but they don’t recognize the mindset that must change in order for the process to have any value.  Being self organizing and collaborative, like being agile, is a mindset.  It’s not just something you do – it’s something you are.  It’s something you become.  It’s about individuals and interactions over process and tools. What I’m finding is that when teams are struggling with the daily scrum it’s about them putting the process and tools over the individuals and interactions.