Agile Coffee

leadership

  • What is a ScrumMaster?

    In addition to our regular podcasts, I host a couple lean coffee meetups every month where we get people dropping in who are less experienced yet very curious about Agile methodologies and lean principles. One common theme at these in-person sessions centers around the role of a ScrumMaster, and it’s a topic that engages us old-timers just as much.

    Many of us have been serving as ScrumMaster of our teams, but the job description changes for every workplace and every team. For this reason, I trust the responses from my peers; still, we’re often left with more questions than “correct” answers. Here are a few of the questions with some of my observations.

    What is a ScrumMaster?

    There are many good starts at a definition, but I like Mike Cohn’s for its succinctness:

    The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster is often considered a coach for the team, helping the team do the best work it possibly can. The ScrumMaster can also be thought of as a process owner for the team, creating a balance with the project’s key stakeholder, who is referred to as the product owner.

    One key responsibility of the ScrumMaster is to protect the team from outside interruptions, requests that could potentially derail the team’s focus and increase its work in process (WIP). In this way, the SM is like a sheepdog guarding the flock. In fact, Ken Schwaber uses this analogy often, saying it’s the SM’s role to keep the wolves away.

    Another aspect to the role is to remove impediments, and the best ScrumMasters are those who have the technical or political know-how to recognize a roadblock early and see that it gets removed. Speed and tact are two skills that they brandish, skills that improve the more they are yielded.

    Does a ScrumMaster need to be dedicated to the role 100% of their time?

    The saying is that a good ScrumMaster can take on two-to-three teams, but a great ScrumMaster can only handle one. There’s room to have a debate on this question, but my feeling is that if you’re working with only one team and you find yourself with too much idle time, you may not be looking hard enough. Either that, or the team is mature enough to no longer require a full time ScrumMaster.

    Michael James, in his erudite article at the Scum Alliance’s site, fairly well states this case. He spells out no fewer than 42 items for a ScrumMaster to keep on her checklist. Incidentally, 42 is the same number on Bernd Schiffer’s similarly excellent post on a ScrumMaster’s job (be sure to check out the comments – GOLD!) Maybe 42 really is the answer to life, the universe and everything.

    ScrumMaster competencies assessmentI find both these lists comprehensive and extremely useful when discussing the work of the ScrumMaster. In fact, I built my own assessment primarily from Bernd’s article. (Merci beaucoup to Fabrice Aimetti for translating the document into french: Evaluation des compétences du Scrum Master.)

    If you can honestly say that you’re scoring eights or nines across each of the rows on the assessment, then maybe you are working yourself out of a job. (That is the goal, after all.) It’s likely that your team has benefited to the point that they are mature enough for you to look for another team to lend a helping hand. Which leads nicely to the next question…

    Can another member of the team also be an effective SM?

    My own opinion is “Sure, why not?” If the team member – and the team – are willing to try it, I wouldn’t discourage this automatically. It ultimately depends on the maturity of the team and the willingness of one contributor to give of himself to serve others. But keep in mind: if the ScrumMaster is committing to work in the sprint, their bandwidth (and motivation) to help clear impediments or pick up other responsibilities (eg. evangelize Agile outside of the team) is at a substantial disadvantage.

    I was a coach in an organization that did encourage team members to try their hand at scrummastering (albeit, out of necessity at first). It’s a great way not only to cross train new skills, but also to strengthen the Agile culture within an organization. Just make sure that everyone is on board with the decision – it should never be forced upon a team member. (I still believe that a dedicated SM trumps anyone who is splitting their time with multiple duties.)

    Does the ScrumMaster need to be technically proficient with the software stack?

    I don’t believe the SM needs be technical at all. They can maintain a “beginner’s mind”. It helps to have someone who is terrifically unbiased in many situations – especially if they’re focused on guarding the process. That eliminates a potential conflict of interest.

    On the other hand, some familiarity with the technology can help when clearing impediments. Anticipating the needs of the team based on historical relationships with the ADLC are certainly valuable.

    But the argument can be made that being too knowledgeable is bad because then the SM would be tempted to inject herself into discussions of how, and this could lead to (or be interpreted as) dictating to the team what or how to do their work. Smells of micromanagement arise.

    Do they need to understand the product inside and out?

    Similar to the need to be technically adept, is it important for SMs to be experts on the product they’re delivering? Again, I can see two sides to the debate. On one hand, that’s the role of the Product Owner, and being completely free of bias can prove to be a large advantage for the otherwise engaged ScrumMaster.

    However, everywhere I’ve worked as a ScrumMaster or coach, I realized tremendous value in understanding the product at a moderately deep level. It helped (again) anticipate needs for communication and dependencies, and the PO usually appreciated having someone to back her up from time to time.

    So, as they say, “try it – you might like it.”

    What other characteristics make an effective ScrumMaster?

    One of the most powerful traits is courage. Call it “having kajones” or simply “being comfortable in delivering the message”, this skill sets the effective Scrum Master apart from the many who just go “by the book”. However, willingness alone will not get you there; to be most effective you must also possess a large amount of tact. Being able to deliver news without alienating your audience is critical. (As Ken Schwaber reminds us, “a dead sheepdog is a useless sheepdog“.)

    So don’t be afraid to step onto the soapbox. It’s not “un-Agile”. In fact, it’s not only appropriate, but demanded. Remember that you’re more empowered than you think.

    Situational leadership is a related skill to be mindful of. By speaking up and identifying that the team is off track, you can provide solutions; but always remember that team needs to own them. When team is too dependent on the ScrumMaster, that could be a learning experience. Maybe the SM should walk away and let the team figure out the path out of the woods.

    One final characteristic I’ll mention is to be a continual learner. Our landscape is always changing, and we need to keep abreast of the ebbs and flows. By continuously checking our own orientation, we can become more trusted to guide the team through changes and challenges.

    Additional Resources

    Don’t just take my word for it. As I said, sometimes there are no right answers – that’s why we continue to have the conversations at the lean coffee meetups. And here’s a list of pretty good opinions, well worth checking out to help inform your own opinion:

  • Encouraging a Bring Your SELF to Work Day with your teams

    Most of us work in teams. We go to work and see the same folks each and every day. We check in when we fill our coffee mugs, and we offer a “see ya tomorrow” when we leave. In between, we work with them – either as a group, in pairs or quasi-independently with occasional interactions. We might spend more waking hours with these people then we do with our family and non-workplace friends.

    But how well do we know them?

    If you’re working with or on a team, you have a vested interest in getting to know each other. Doing so develops trust, openness, respect, courage and commitment – many of the values we prize in Scrum and Agile. So here’s an exercise that you might consider: throw a “Bring Your Self to Work” Day. (I’d seen this listed as a topic at an open space, but I wasn’t able to attend, so you’re stuck with my imagination.)

    Before you laugh it off and say “don’t we do this every day already?” or roll your eyes at a seemingly trite concept, hear me out. I’m not about to preach being fully invested in being 100% present in your own daily activities (though that’s a noble goal). Rather what I’m proposing is a team-based exercise, whether on-site or off.

    In fact, despite the name, you might opt to meet at a restaurant or other non-work location. Holding an event after working hours sounds ideal, but it could be hard to pull off if co-workers have their own family- or commute-based constraints. And given the choice of having the whole team participate vs. a convenient time for most of the team, I’d choose the former.

    Here are a few suggestions for pulling this off.

    Keep it Social – meeting at the office always carries connotations of work. Heck, even the word “meeting” is so charged that you might consider referring to the gathering by another name. If budgets allow, consider social activities such as bowling or karaoke – making sure, of course, that the activity is something that all are able to take part in. And even if getting out of the office isn’t feasible, try to find a space far enough away from your work area that there aren’t the normal distractions.

    Share a Meal – something we all have in common is the need to feed ourselves. Whether you and the team decide to brown bag it out at a picnic table or in a bright conference room (preferably with natural light), or you head to a food court or restaurant, the gesture of “breaking bread” together is powerful and commonly accepted. If you splurge and have food brought in (bonus points if it’s not pizza), odds of participation increase greatly 😉

    Start Conversations Small – setting things in motion with a firm demand for all to open themselves up completely is the quickest way to kill the mood. Instead, begin by asking small, basic questions like:

    • what movies are good this season?
    • what was your favorite thing to do as a kid?
    • what was the worst thing about school?
    • hobbies / books / interests / etc.

    You can be creative – more creative than I am – but the point is to get people talking about themselves, maybe even laughing with each other. When this happens, we start to find unexpected connections and create or reinforce our bonds.

    I’ve done this with just about all my teams, and my favorite questions usually relate to our childhoods. Living on the west coast, I find that these teams are so diverse in terms of where they’re from and when they grew up, so the stories from our early years are always filled with new things to learn. Many remarks of “Oh, I remember that/those!” pepper the conversations, and people really open up and respect others more.

    Ask a Keystone Question – if and when the team is comfortable with the conversation, I encourage you to ask a deeper and more meaningful question, something that gets to the heart of your SELF. It doesn’t have to be too deep or serious, but it should allow for each member to see that they’re truly part of a trusting group. Something along the lines of “what’s one thing you have (talent, interest, experience) that you haven’t told anyone at work?”  I’ve heard answers ranging from “I used to sing opera” and “I’ve always wanted to visit Nepal” to much more intimate stories of personal loss or achievement.

    Again, the point isn’t to put people on the spot and be too vulnerable, but to show that it’s safe to share with this group, to show a bit of our true selves. You can’t (and shouldn’t try to) force connections and respect, but these connections are meaningful and usually happen as a result of honest and open conversation.

    Treat the Team as a Family – after the day is over and we’re back in our work routines, it’s very important to keep these bonds alive. Treat your team as an extended family. You don’t have to bring up the stories that were shared, but try to keep that emotion and connection with your co-workers as often as possible. It enables stronger, more natural collaboration and clearer communication. When appropriate, celebrate individual achievements as a team and help each other out with personal goals by occasionally checking in.

    And don’t make this a once-a-year activity. Anytime the team changes adds (or loses) a member, or if the group needs a collective pick-me-up, break out the invitations to another “Bring Your Self to Work” Day.

  • 29. Frederic Laloux and Dr. Clare Graves Walk into a Bar

    Podcast: Play in new window | Download (Duration: 44:42 — 20.7MB) | Embed

    Subscribe: Spotify | RSS | More

    Announcing the brand new Podcast Topic Index. Search and sort to find any topic discussed on our podcasts.

    Victor is once again joined by Dale Ellis (@theDigitalDale), Jason Kerney (@JasonKerney), Zach Bonaker (@ZachBonaker) and Garrett Borunda (LinkedIn) at the Cape Rey in Carlsbad for a lively morning of Agile and Coffee.

    In this episode, our Agile heroes discuss:

    Reach out to Vic (@AgileCoffee) and use the hashtag #tellAgileCoffee to interact with us on an upcoming episode.

    announcements:

  • 28. “Agile” Under the Microscope

    Podcast: Play in new window | Download (Duration: 52:54 — 24.4MB) | Embed

    Subscribe: Spotify | RSS | More

    Victor is joined by Dale Ellis (@theDigitalDale), Jason Kerney (@JasonKerney), Zach Bonaker (@ZachBonaker) and Garrett Borunda (LinkedIn) at the Cape Rey in Carlsbad for a lively morning of Agile and Coffee.

    In this episode, our Agile heroes discuss:

    ACCUSWest 2015 archive at AgileLib.net, courtesy of Tobias Mayer

    Coming soon is Dr. Dave‘s 5 Saturdays program’s Train the Facilitators workshops: May 30th and June 6th. More info at 5Saturdays.org

    Reach out to Vic (@AgileCoffee) on Twitter and use the hashtag #tellAgileCoffee to interact with us on an upcoming episode.

  • Everyday Progress

    Just read @zxed‘s post on skills you don’t have which had me reflect on my own style.

    I believe there are many skills (an unknowable amount and always in flux) essential to elite leadership. More than this, I believe that to become a great leader, everyday must be oriented toward greatness, no matter the increment.

    In my current role (technical project manager / agile coach) I have many opportunities to be great, breaking out like so:

    • competency: It sounds like a minimum requirement, but I feel I’m deficient more often than not. I feel that if off the cuff I can answer 80% – 90% of the questions asked by stakeholders, I’m surviving. Greatness strives for perfection. Time I save by not having my team members attend meetings is looked upon highly.
    • vision: No, I’m not the product owner (PO), but still I must have a clear vision of the goals of the projects that the team is taking on. Knowing what demarcates the path to completion is half my duty.
    • coaching: Pushing the team to be their best is the other half 😉
    • enforcement: I have an obligation to protect my team from distractions. This means not only preventing outsiders to interrupt the progress of the team, but also protecting the team from themselves. When meetings are held, I keep them on point, as efficient as possible so that no one considers their participation wasted.
    • nurturing: You’d expect this at the bottom of the list if only because it sounds like such a soft skill, but it can be a topic of its own. Simply tuning in to where each team member is with regards to their own hierarchy of needs goes such a long way to helping them identify with their own self worth.

    It boils down to this: My job is to stay in touch with what the people are doing and what they need to succeed. I succeed by pushing them toward their success. My goal is for each team member to create meaningful value – both personally and for the organization – each and every day.