New Scrum Master: Problems to solve in your first days

In the previous two posts. First day as Scrum Master and Second day as Scrum Master, I talked about you as a new Scrum Master to a team and some steps you can take to ease yourself into the team's world. The first post talked about a group meeting with all team members including Product Owner. That meeting set up some introductions and gave you some clues as to how the team interacts and possibly some team dynamics. You followed that up with some one-on-one talks with each member of the team. In this post I'll talk about interpreting the results of your one-on-one discussions with the team members.

Once you've finished your talks with the team it's time to pull all the information together and begin planning your actions. The problems mentioned by the Product Owner, developers, testers, BA's, UXD, and others on the team will likely fall into several categories. What's listed below can be used as a guide but doesn't take the place of your own analysis based on your unique set of circumstances.

Team's ability to self-organize and be cross-functional

One Team, One Goal.

This will be by far the most common area of weakness based on the many discussions I've had.  The clue to this will be problems brought up by the team that they can clearly solve themselves but they'll need your help. Some comments might include:

• "Requirements are poorly written",
• "Working on things before we know what to do e.g. UX Designs incomplete",
• "Too many hand-offs", and
• "Definition of Ready and Definition of Done missing".

I'll look into the first comment, "Requirements are poorly written" in some detail. When the Scrum Development Team say this, I'm thinking there's both a communication issue and possibly some role based barriers in place. The comment given by the Development Team makes me think they're not feeling completely responsible for making sure the user stories are backed with heaps of conversation. Both communication and not feeling it's their job can be resolved through well facilitated grooming sessions. The team can become better at self-organizing by tackling head-on the issue of shared understanding of the customer problem documented in user stories. The team can also build their cross-functional capabilities through greater contributions to the user story including the acceptance criteria. For a developer whose experience may be waterfall and where the sole contribution of the developer was code, helping to write the requirements can be a new and possibly frightening turn of events. You as Scrum Master are there to help facilitate this transformation.

Business or company culture as impediments

We do it that way because that's the way we do it.

Problems or issues cited by the team that fall into this category might include:

• "Too many sign-offs and approvals (Designs)",
• "Little interaction between test and other departments",
• "Business emergencies and no way to stop them", and
• "Fixed end date regardless of start date"

It's clear the company culture is not controlled by the development team but they can have an influence. The comments above could make you think the company is a top down Command & Control shop and you'd be right. One thing I've seen in this kind of environment is nothing is written down, it's all done based on memories of past practices. One way to begin affecting this culture is to document how current work is done paying specific attention to the time it all takes. The Scrum Master and team can do this documenting of existing process and then present an alternative process with the now documented benefits and savings. As Scrum Master, you should also seek out and secure executive support or at least, a powerful mid-level manager who can support change. Without support, you're chances of success are severely limited as I've recently learned first hand.

Technical challenges or knowledge gaps that are impediments

Thomas Edison - Incandescent light bulb

This is something I usually note as a result of listening to the development team but it's rare that the team will directly say something with the exception of how testing is done. What I commonly see is a team hampered due to:

• Specialist on team that can't assist in other technical areas
• Test treated as a separate group or sub-team
• Testing always done at the end of sprint

These fall under a team being cross-functional but to get there will require specific training and strong guidance from the Scrum Master.  I once had a team with one tester doing all the testing. I suggested that the developers help out with the testing to speed it up and relieve the pressure on the sole tester. Luckily there wasn't a rope handy as I'm sure the developers would have hung me then and there for speaking such blasphemy. One developer suggested to the managers that they needed to hire more testers. The managers, GM of Product and GM of R&D both told the developers that hiring wasn't an option and that they would need to better support test. Once the management support was established, I was able to help get the developers to run acceptance and system tests. Baby steps. It was the opening needed to begin the longer term goal of spreading a little knowledge throughout the development team. When I left that company, the Scrum Teams did all the UX, testing, and infrastructure work themselves whereas in the beginning, each of these areas had specialist teams doing this work.

How this helps

After my first days and weeks with the team, I continued doing one-on-one talks with all the developers and Product Owners, noting what changes they felt had occurred in the previous month or two, how exactly these changes affected them, what further changes they wanted to see, and what makes them happy to come to work. I often find myself listening to the team chatter but asking the team to tell me their struggles and their delights helps me focus better on serving them. That's my role as Scrum Master, to serve the team.

I welcome your thoughts and comments.

Tweet

Second day as Scrum Master

In the first post of this series, First day as Scrum Master, I talked a little about he first day with your new team. In this post I want to talk about conducting your first one-on-ones with the team members.

After your first day or so with your new team, it's time to get intimate and personal through one-on-one discussions - I don't call them interviews because I want an informal atmosphere for a discussion and not one where people feel they're playing a role.

I use one-on-one to gain insight into the team members world in a non-threatening way. This is a three step process, setting up an one-on-one, conducting the one-on-one, and making sense of the results. For the team members, this process generally gives them a chance to voice their concerns and issues but it almost always leaves them with a sense that someone cares. For you as a Scrum Master, you do care but it's important the team gets the idea that you are there to serve them, that you actually care more about them than yourself.

Setting up the one-on-one

To get started I approach each of the team members and simply ask if I could have 30 minutes of their time to talk about what's working and what isn't from their unique point of view. This establishes a few things:

1) I value their time by setting a time limit,
2) I value their opinion because I want it from their point of view, and
3) I hold out hope and optimism that I might be improving their personal situation.

Most often the person will give me their time right then but if they're too busy, I don't press too hard but ask when would be a better time and suggest a time. This gives them lots of space in case there's apprehension but also lets them know I'm respectful to their time.

For the one-on-one session, select a neutral, non-threatening, private, and casual space. You should avoid meeting rooms if you can as these are usually sterile and a bit too formal for your purposes. At one company they had a room with sofas where I did these and it provided a very relaxed atmosphere.

Conduct the one-on-one

I open the discussion with a promise of non-attribution and ask if it's ok for me to take notes. If you can do this without notes that's better. I have a standard set of questions that ask, worded appropriately for the context. I ask these specifically in this order starting with what are their expectations of me followed by things that might be slowing them or the team down. I finish with a very personal question that almost always is a surprise to the team member. Examples of these are:

1. Why do you think I am coaching your team?
2. What difference do you hope I'll make?
3. What do you want to learn from me?
4. What outside influences hold the team back?
5. What internal barriers/impediments hold the team back?
6. What can we continue doing or do more of to make life on the team better?
7. How can we work more effectively?
8. Why did you come to work this morning?

The first question is important as it sets up all the followup questions but it also sets the tone. I might specifically say, "My job description says to implement Scrum but I didn't get a strong sense of team's perspective of what that means. Why do you think I'm here?" The tone I'm trying to set is I'm here to learn and not coming in with an agenda.

It's also important that however these questions are put forward, use the exact same structure if not word for word, with each team member. This makes it better and easier to compare and consolidate their responses.

At the end of 30 minutes, conclude the session with a very sincere thank you, repeating the key results and promises to follow up.

Spend a few minutes after the person's left to collect your impressions. Clearly note the issues brought up and what you may have promised to do.

Making sense of the results

Once you've gathered your notes from all discussions with team members, including the Product Owner, begin consolidation and looking for common threads. Use this to help prioritize you contributions for improvements. How to do this with examples will be the topic of my next post coming soon.

Thank you for reading and I welcome your comments and suggestions.

Tweet

First day as Scrum Master

If you've been hired as a Scrum Master, you'll most likely have a vision of the future state of the team based on interview questions. But do you really know what's going on? Here's what I have done to start integrating myself with the team and building my knowledge.

The very first thing to do after you get a brief tour of the place, it always starts with a tour, is have a general meet and greet session with your team. Tell them your story, invite questions, and if appropriate, like the team is new to Scrum, discuss why you're there. This is a light-weight meeting more about introductions than any deep understanding. But, you're not just saying hello, you're watching and listening closely. The team will almost certainly be on their best behavior at this first meeting so the clues of how they interact will be subtle and mostly come from body language. Watch how the others react when someone speaks.

Start by asking each team member in turn what their most recent proudest moment, greatest success, or greatest satisfaction was as a member of the team. As you go, note the introverts and extroverts, the cynics and optimists, and note how many shared the same positive experiences. If everyone shares the same experience as their best then this becomes your target of understanding later, that is, what about that experience pulled the team together. If there are several 'greatest' moments then you'll need to dive into this during the one-on-one meetings with the team after to figure out how each person measures success.

Ask each member in turn what their biggest issue or impediment is. Write this down. Be seen as writing it down. This is important as you need to follow-up. The first question is about past successes but the second question is about the team's future and although not explicitly stated, it's setting the goal of more successes in the future.

On your first day, you're looking to set the tone as an open and honest person, as someone who cares about the team, as someone the team can be open with, and as someone there to help. You can do this following these three steps:

1. Telling your story with some personal details, family, pets, an awkward moment but use caution to not go too far. You want to leave the team yearning to learn more about you, not for them to make final judgments.

2. Ask a question about team successes that helps to reveal team dynamics and ask it of each individual. Listen and watch closer for clues to the team. Be cautious that you're not judging but ask any follow-up questions to draw out the experience they felt.

3. Ask the question of what the team expects or hopes you can do for them. You make it clear that you serve the team. Resist any temptations to "solve" problems here, this is not the setting. Do follow-up on any issues or problems, you need to establish that you're there to actively help.

The next thing to do is conduct a one-on-one interviews but this is another topic.

Have a supremely successful week.

Tweet

Leadership and Vision

If you want to build a ship, don’t drum up the people to gather wood, divide the work, and give orders.  Instead, teach them to yearn for the vast and endless sea. – Antoine De Saint-Exupery,  Author of The Little Prince

When you’re working to change the way things work, always strive to provide a strong and compelling vision. If you’re simply telling people to do ‘A’, ‘B’, and ‘C’, and you have the authority to do so, then you’ll most likely get compliance. You’ll also probably get something done in the near term but it’s very unlikely that the change will sustain itself.

Instead, share the the vision of a better world with the team, share the hoped for impact of the change and share why it might be better. Share too the idea that it’s an experiment to be better. If the team can see the vision, have them provide the way to achieve it. Then, serve the team by helping them achieve it.

Try these three steps: Vision, Actions, and Outcomes.

Vision: As a Scrum Master or as a Product Owner, I see the Team talking with customers, understanding their pain points; getting to the heart of the problem the customer most wants solved.

Actions: Create an interview script that has the interviewer asking some questions. Pair off the team members so that only two meet with the customer. Identify what customers to talk to and arrange a casual meeting over coffee. Conduct the interview using a pull technique to get their number one problem and what their world would look like with it solved.

Outcomes: A Lean Business Canvas to make visible the hoped for business outcomes, a release plan if the the business plan is feasible

The Vision in the example above doesn't specify what happens afterward but only after the vision is established do the Actions and Outcomes become apparent.

Tweet

Agile: Don’t Sell It, Demonstrate It

There are many things you can sell including some ideas but you can’t “sell” behavior and you should not try to sell Agile to people. Both of these are learned and become part of what you are; they become the standards of behavior by which you live. Because these are learned, try substituting “demonstrate” for “selling”. This is not to say you don’t persuade your C-Levels of the merits of Agile so you can experiment but selling alone isn’t going to be enough. If you approach your C-Levels about being Agile you might start at a disadvantage because, unless they're planning on becoming an Executive Scrum team, their main interest in Agile will most likely rest on results and outcomes, not theories. To put another way, if the business needs a hole, talking about the merits of using a shovel over a spoon won’t get the hole dug and won’t bring any value to the business. Instead, demonstrate a great and mighty hole can be dug quicker and more efficiently with a shovel, then do it again just to show it’s repeatable.

The Experiment

When I first started using Agile, the CEO & company were faced with a particularly challenging business opportunity requiring an innovative software solution in 3-months. The CEO asked if development could meet a hard commitment in 3-months but the answer was no. We followed a Waterfall paradigm at the time but we knew we couldn’t execute successfully in the short time available using our current methods and practices. Being in the right place (the business needed an alternative) and at the right time (we had just completed research into the various Agile methodologies), and of the proper Agile frame of mind (we were eager to experiment with Agile), I was able to implement a variant of Agile Scrum that allowed us to pivot 180 degrees and build a software solution within that 3-month window. Agile and Scrum made it possible for Development and Product Management to capitalize on our business opportunity quickly and efficiently. Did the CEO want us to do Agile? The simple answer was he really didn’t care what means or tools we used to be successful; what he wanted was for us to be successful. Adopting a flavor of Agile gave him and the business the result and success they wanted. And once he had seen a positive result, he asked why all the development teams weren’t using “that Agile thing”.

The Demonstration

The CEO was never “sold” the idea that Agile was anything special but instead we demonstrated that Agile could bring special results. The CEO, the board, and the shareholders want the company to be successful and profitable. If the way to achieve success is both repeatable and sustainable, all the better. If they had that success using Waterfall or Agile or any of the dozen or so other software methodologies, everyone would be happy. The R&D Manager and Head of Product Management suggested to the CEO that the only real possibility of success lies with using an Agile Scrum framework and practices. This was essentially the only executive coaching needed. The high visibility resulting from using Agile Scrum and Agile’s built in ability for the team to absorb changing requirements, gave the company a fighting chance to take advantage of the opportunity which, in the end, was met, exceeding most expectations.

To move the business at its highest levels often requires a demonstrable success. A business may still choose not to change after a demonstration (or two) but what are your chances for change if all you have are theories and anecdotal data from other companies?

Tweet