Blog

Scrum Roles Q&A Recap and Recording

By: Agile Velocity | Sep 25, 2017 |  Product Owner,  ScrumMaster,  Team,  Video,  Webinar

Image of the 3 Agile Roles" ScrumMaster, Product Owner, and Dev Team

On a Scrum team, there are three roles: ScrumMaster, Product Owner, and Development Team. For teams transitioning to Agile, there can be a lot of confusion around how individual Scrum roles and titles might change to fit into a new environment.

Recently, our Agile coaches Braz Brandt and Brian O’Fallon sat down and addressed questions on Scrum roles and how each role affects the individual and their organization. Check out the webinar recording and Q&A transcription here:

 

 

Q: What’s the difference between a Product Manager and a Product Owner?

Brian: This comes up fairly often. The real similarity, of course, is that both are responsible for understanding the product, setting its vision, and getting buy-in. However, the PO is much more hands-on with the execution of the product. They help with the communication between the team and the stakeholders.

Braz: Right. We’re expecting the Product Owner to have two very distinct skill sets. The first being a clear, customer-focused vision of the product. The second being they have that same expertise and availability they give to customers for the development team as well.

Q: Can you combine roles (PO and SM, PO and developer, SM and developer, etc)?

Braz: You can do anything. The question is will you be effective? It can be difficult to change hats so often. So make sure that the individual who wants to play more than one role has a very firm grasp on each role. However, even then, I wouldn’t recommend it.

Brian: It’s also important to consider the motivation. Is this an HR move to cut down on employees and save some money? Or is this an individual who wants to learn about another role and develop some new skills? I’m always more willing to let someone learn new skills because they’re interested in teamwork and building interpersonal relationships than I am to combine roles just to cut down on costs.

Now, can a ScrumMaster be a developer? Absolutely, but it works best on mature teams.

Q: What if we have missing roles, like no dedicated ScrumMaster? Can we rotate roles?

Brian: You’re best off finding someone to permanently fill that role. When it comes to rotating roles, I don’t advise it. Each role, particularly ScrumMaster, requires practice and attention so the individual can build up the necessary skills.

Rotating the ScrumMaster usually means there is always someone new in the role, meaning skills aren’t fully developed, and the team doesn’t get what they need out of the ScrumMaster. If you need to rotate, I wouldn’t recommend doing it any more often than quarterly. That at least gives the team a bit of stability.

As far as rotating the Product Owner role, please don’t. It never leads to good results because that Product Owner needs to have such a long-term understanding of a product’s development.

Q: Does the ScrumMaster need to understand the business/technical aspects of the product?

Braz: The ScrumMaster doesn’t really need to understand the business or technical aspects. Of course, it can help the ScrumMaster recognize problems or inconsistencies at times, but it’s definitely not necessary.

Q: Should the Development Manager be on the Scrum team as an advisor?

Brian: This is something we see all the time. It’s very common to walk into an organization and find that an HR person or someone in a position of authority has been assigned to each team. That person usually writes performance reviews and takes care of professional development.

The truth is that it’s very hard to be honest and open when there is someone else in the room responsible for judging your performance. It can also make people defensive of their work as opposed to being open to suggestions and feedback.

Braz: Yeah, I agree. The Development Manager should definitely not be on the team. It runs the risk of creating an unsafe environment for the team.

Q: I’ve run into a lot of uncertainty in organizations with newly minted Agilists asking “where does my career path go from here?” Could you talk a bit about moving up the ladder, starting from a Product Owner or ScrumMaster?

Brian: On the PO side, it’s a little more straightforward. When Product Managers are transitioned into Product Owners, their path doesn’t change all that much.

For ScrumMasters, it’s not really a traditional “ladder” career path. It becomes more about skill acquisition and how effective you are as a facilitator. You can play the same role but maybe move up to play the role for a higher level team. There are also options like the ones we took: a ScrumMaster could evolve into an Agile coach at some point.

Q: How about Tech Leads? Is there a strategy to equalize them with the Dev Team when promotion/career tracks require it as a stepping stone?

Brian: Traditional roles like Lead positions can get really interesting when we start to implement Scrum. The old ways of measuring people in terms of their ability to push a project through or help manage the project is not as effective as it once was. Now we have this self-organizing team and that skill set is subsumed by the process.

To be blunt, it’s a hard question. If you mean in terms of the team perspective, meaning how do we equalize them with the leads, we lean on the ScrumMaster to do that in a grooming or refinement meeting. Leads or authority positions often have a tendency to take over the conversations in the meetings. There needs to be an understanding that the ScrumMaster is there to intervene and all voices are heard.

It can be tricky, because Leads might start to feel a bit devalued. However, they can very well exist in an Agile environment as long as they’re more descriptive than they are prescriptive of what happens on the team.

If your career path requires it, it’s important to be careful not to let that drive the processes that Scrum implements.

Q: Scrum roles are a work function, not titles, right?

Brian: You’re right. Your HR title doesn’t necessarily define your work. We always recommend that folks let the title that they get promoted and paid on exist in a slightly different space than the role they play in the team. Your title is not particularly indicative of what you’re doing on a day-to-day basis for the Scrum team. I’ve been called a Development Manager while playing the role of the ScrumMaster.

Braz: Absolutely. I would love to see that more often. One of the big things in Agile and Scrum is the idea of servant leadership, and it would be great to have more managers in roles that develop those skills.

It can be beneficial to include HR as soon as we begin our Agile adoption to help them better understand and help with the transition.

Q: Do we still need a Technical or Dev Lead, when we have a ScrumMaster?

Braz: I think sometimes you do. Like we mentioned earlier, the ScrumMaster doesn’t always have the technical expertise, so they’re often going to need deep technical and business experts that they can lean on when they have questions.

Now let’s be clear, that expertise doesn’t have to come from a Technical or Dev Lead. Not all teams need to have that role filled, but Leads can definitely come in handy.

Q: Should the role definitions be shown within the Scrum team’s working agreement(s) as a reminder/information radiator?

Brian: I have to admit, I haven’t tried that.

Braz: I haven’t either, but I don’t think there’s a problem with that. It might be helpful that have the 3 Scrum roles (Product Owner, ScrumMaster, and Dev Team) clearly defined and displayed to help individuals find their place on the team. It reminds everyone not to create new roles or silos, which in turn, encourages collaboration.

Brian: Yeah, I think that would be a great idea, especially for new teams. It can’t hurt to be very transparent about what each of these roles entails.

 

Watch our previous webinar recordings here: Sprint Planning Q&A and Sprint Retrospectives Q&A.

Blog

Webinar: Sprint Retrospectives Q&A

By: Agile Velocity | Aug 29, 2017 |  Article,  Scrum,  Video,  Webinar

Review mirror on a car that represents looking back and retrospecting on a sprint

One of the great things about Scrum is its focus on continuous improvement. The Sprint Retrospective, or Retro, is just one of the ways Scrum bakes in opportunities for progress. Sprint Retrospectives happen last of all the Sprint ceremonies and is technically scheduled after the Sprint Review and before Sprint Planning of the next Sprint. The prescribed timing allows the team to review what happened and also gives them time to make changes and prepare for the next Sprint.

A few weeks ago, Agile coaches Reese Schmit and Braz Brandt got together and fielded questions about Retrospectives. You can find the video below as well as a transcript of the Q&A portion.

Sprint Retrospective Video

Sprint Retrospective Q&A

Q: When do you hold Retrospectives? Before Sprint Planning?

Reese: Definitely before Sprint Planning. There’s a reason why most of the books say to do Retros as the last activity. This is an opportunity to look back at the Sprint and see what held you back, what kept you guys from being awesome. So if you do that after Sprint Planning, you don’t have the opportunity to place these things in your backlog and you miss out on the opportunity to create actionable items and follow through with them.

The other thing is what if your biggest issue is predictability? Predictability is the main focus of your Sprint Planning sessions. If you hold your Retro after Sprint Planning, you have to wait another two weeks before you can really dig in and work on those things in a Sprint Planning session. You want Retros to be your cap on your Sprint.

Q: As the Product Owner, should I come to Sprint Retrospectives? I want the team to be able to speak freely about what they need from me. I think they could do that better if I’m not there.

Braz: There’s a couple layers to this question. As a ScrumMaster, it makes me start to wonder: Who comes to a Sprint Retrospective?

This takes me back to basic CSM classes: How many roles are there on a team? Three: A ScrumMaster, a team member, and a Product Owner. The Product Owner is a part of the team, and the whole team should be at the Sprint Retrospective. If we are going to get better as a team, if there are issues going on with how available my Product Owner is or his lack of authority, then I need to be able to talk to my Product Owner about that. If the Product Owner isn’t there, then we go from an introspective Retrospective to an extrospective Retrospective– meaning we’re looking for people outside of the room to solve our problems.

Then there’s another layer to this: As a Product Owner, I have this feeling that my team will function better if I’m not there. That’s where the ScrumMaster should ask, “Why don’t we feel comfortable when the Product Owner is here?” Then the Retrospective can focus on solving that issue, because without the PO there, you won’t have effective Sprint Retros.

Q: It seems like Retros become less effective over time. How do you keep them effective?

Braz: Non-effective Retrospectives can, in themselves, be a Retrospective topic! Part of your role as an effective ScrumMaster is to be that mirror for the team, to say “This is what I see happening, so what’s going on?” A Retrospective is a place to have those hard conversations.

So, make your Retrospectives more effective by retrospecting on your Retrospectives!

Reese: So meta.

Braz: Very meta.

Q: Are outside stakeholders and/or managers involved/invited? If not, who provides the download?

Reese: First, let’s talk about the download. Who is the Retrospective for? It’s for the team. There is no download. If the team wants to take notes or pictures of the board, that’s fine. But that’s for them to decide. This should NOT be a download for the managers. If they want to understand what’s going on, it should be a conversation.

As far as stakeholders or managers getting involved, that’s a slippery slope. I mean, I have no problems with my boss getting involved with my Retros because I feel comfortable saying things to him. But, not everyone is. Remember, you want to create a safe environment for everyone to speak freely.

If people don’t feel comfortable, they might have trouble talking about where they went wrong. They might skirt around the hard topics if the manager is in the room. So it should really only be the team in the room (Team, ScrumMaster, and Product Owner).

Q: I’m on a big team. 90 minutes tends not to be enough time for a Retro. What should I do as a ScrumMaster? The team is 12 people.

Braz: Big team–that’s my first red flag right there. Twelve people is too big. The size of the team should really be seven, plus or minus two. If you’re looking to have everyone involved and to have really vibrant and inclusive discussions, 90 minutes for a team of twelve probably isn’t enough.

So here’s my first question: Is your team really twelve people? Is everybody on the team really invested or are they just interested? Are some really just managers or stakeholders or outside folks that don’t necessarily need to be a part of the Retrospective? If we are actually a part of the team, my next question is are you actually one team? Maybe there’s some opportunity to split into two teams with two separate Retros.

Now, is 90 minutes enough for a Retro? If you’re having trouble with that, you need to start looking at the whether or not you’re actually following the five part format. Are you getting to everything you need to get to? Is the ScrumMaster flexing their facilitation skills, setting good time boxes, and driving those parts to conclusion? If we are doing all of these things, then maybe it’s a question of extending the time you spend in your retro. Take that question to the team, and see how the team wants to fix it.

Q: What strategies should we use if the team is not getting their action items to completion? What if the same issues keep coming up in your Retrospectives?

Reese: Be sure to check in at the beginning of your Retros and see where the team is at with previous action items. Make sure that those action items get put into the backlog so that you can keep your eyes on the prize. If you’re not following up on them, then come up with a solution to that as a team.

Q: What do you do if the team doesn’t participate?

Braz: Again, as the ScrumMaster, you don’t have to solve that problem. But, you do have to ask that question. The ScrumMaster needs to say, “Hey team, what’s going on? You guys aren’t asking questions or coming up with solutions,” or “You guys are saying everything is fine, but it doesn’t seem that way. What’s really happening here?” Ask those hard questions. Or ask individuals about why they aren’t speaking up.

Reese: At the same time, make sure not to alienate people that are more shy or introverted. Those people might not feel super comfortable in a room full of people. Remember, creating a safe space is key to an effective Retro.

Braz: Of course. You can find time outside the Retro when you can speak to that person one-on-one. And finally, the ScrumMaster can offer help. Ask the team (or the individual) about what you can do to help increase participation.

Q: Should the action items from the Sprint Retro become part of the backlog for the next Sprint?

Reese: Yes, absolutely. Now, make sure that you’re limiting yourself to only a few items. Not everything will fit in the backlog.

Q: What tools would you recommend for remote team members to become more effective and collaborative during Sprint Retros?

Braz: This is one of my favorite questions. My first tool isn’t a tool, it’s a mindset. How many Retrospectives have we been in where the entire Retro is spent with everyone on their laptops, not engaging. We have to be mentally co-located. If we aren’t mentally co-located then nothing is going to get done. It’s important for ScrumMasters to ask the team, “Are you guys actually here? Are we all fully present?” Once everyone is mentally checked in, everything else will get easier.

Now as for actual tools, I’ve used several. One way is to have everyone, whether they are physically in the room are not, message their thoughts directly to the ScrumMaster using whatever internal messaging system your company has. They can then sort through them and make sure everyone’s thoughts are being addressed. Also, take advantage of things like virtual whiteboards to give everyone on the team a visual. Innovation Games has some great tools to use in Retrospectives as well, with templates or the ability to create your own.

Q: How do you handle a team that believes they are high-performing and there is nothing to improve?

Reese: Sometimes, as a ScrumMaster, you have to ask the team to pretend for a second that they aren’t the best team. Now, what’s the most amazing thing, the silver bullet, that the team could do to really dig in and reach the next level?

Another thing you could do is a team health check. Atlassian has some tools out there to help you gauge the health of your team. Or you can use the team health check from the Agile Coach over at Spotify, Henrik Kniberg, which uses cards to create a visual of issues the team might be having.

Q: Do you think it’s a safety violation if the ScrumMaster makes it mandatory for each team member to answer every question on status updates?

Braz:  Safety is so easy to break. The best way to ensure you’re not violating anyone’s safety is to ask. As a ScrumMaster, you should ask if the team is comfortable with you reminding them when they forget to answer a question. Asking for that permission, asking for engagement in finding a solution, is huge. If you don’t have that engagement, you’ll run the risk of making team members feel uncomfortable. Discomfort can inhibit the team’s ability to really dig into their Retros and get real value from them.

Q: Do you recommend using Retro time to reevaluate working agreements and establishing/building team charters?

Reese: Again, take it to the team. See if they feel comfortable taking another look at those working agreements and team charters as a topic during the Sprint Retro. They might feel like that’s more of an action item to be worked on during the Sprint itself, in which case you want to make sure that you’re leaving space in your Sprint.

Usually when kicking off a team, you’re going to spend a lot of time in your first few Sprints figuring out things like team charters, definition of done, and so on. However, there might come a time when these need to be reevaluated. If the team thinks it’s a high priority, then using Retro time to do that is just fine.

Q: What do you do when the team assures you that there’s nothing in the Mad/Sad/Stop/Negative category?

Braz: This might be a good time to look at other types of Sprint Retrospectives. Try exploring other formats for gathering this data and generating insights.

You can also do a root cause analysis, like the 5 Why’s, on the statement “There’s nothing we could do better” to uncover some of the assumptions behind that sentence. (We talk more about the 5 Why’s in our article, Lessons Learned From an Ice Cream Social.) This gives the ScrumMaster the opportunity to challenge some of the assumptions and help the team uncover areas that could use improvement.

Q: Do you recommend Sprint Retrospectives before or after Sprint Review?

Reese: Again, I’m definitely in the camp of Retro after Sprint Review. You want Retros to be your cap on your Sprint so that you are able to implement what you learn from your Sprint Retrospectives immediately into your next Sprint.

Q: Reese mentioned a book earlier. What was it?

Reese: We’ve mentioned a few books on Sprint Retrospectives that you can reference, including Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen and The Retrospective Handbook, by Patrick Kua.

Q: Is there a format or agenda for a targeted Retrospective? For example, when you know there is a problem that needs to be addressed that may not come up in the start/stop/continue format.

Braz: There are a lot out there. You can look through the books that we’ve mentioned or explore resources like Tasty Cupcakes.

More importantly, is the ScrumMaster setting aside the time to research all of these methods and find one that fits the best. Make sure the activity you choose gets to the heart of the problem you’re trying to uncover. If you have a lot of comfort in your team environment and you have strong facilitator skills, the best tactic to get to these tough problems might be to just call out the elephant in the room. Ask your team directly about particular problems.

Q: Other than timeline, what are some other activities that are good for project Retros? What are the typical guidelines or standards for running a productive post mortem?

Braz: One of my favorite activities is the Amazon Review game. It helps you dig into what looks good and what doesn’t from a customer standpoint. The timeline works well for comparing the internal workings of a team and the external events (like holidays, weddings, or babies). Timelines let you see how the team is affected by external factors and learn how to prepare for the external factors.

Q: What are the typical guidelines or standards for running a productive post mortem?

Braz: First, I’m not a fan of the term post mortem. It implies that we’re looking at a project that is dead and no longer relevant. If we’re doing Scrum and Agile right, then we’re focusing on building vibrant teams not one-and-done projects. So don’t call it a post mortem, because the team is still there and still invested.

Q: Would love to hear ideas, possibilities, and pitfalls around scaling Agile–it would likely would fill another webinar.

Reese: It would probably fill an entire webinar! In fact, we’ll probably do an entire webinar on scaling Agile in the next few months! Our companies are growing and scaling is becoming more and more important. There are so many frameworks and techniques out there to help you with that.

If you’re doing Scrum, you can start holding Scrum of Scrums meetings. Make sure you start small and build from there. SAFe® is a very prescriptive Agile framework. It’s got everything figured out for you, you’ve only got to plug in and play. The framework for you depends on your team and your organization.

Q: What are your biggest takeaways from Agile 2017?

Reese: My biggest takeaway is that all those people who write all those book are real people. They’ll sit down and have a beer and a conversation with you. They’re coming up with new ideas and looking for real feedback. They’re just human beings just like us, they’ve just been doing Agile longer. They’ve just had more time to learn about what works and what doesn’t.

There was also a lot of focus on safety and team culture as a tool to create high-functioning teams.

I personally took what I learned about sketch-noting and visual meetings. Images are retained much better than words.

Braz: I’ve been amazed by these large conferences and the broad spectrum of people there are around this idea of agility. Whether they’ve been at it for awhile or they’re just dipping their toes into Agile, it’s amazing to see that we have such an inclusive community. You really can have a meaningful conversation with some of the biggest thought leaders in our sector. Being able to connect on a human-to-human level is so empowering. So thanks to everyone that’s a part of this wonderful community.

Blog

Smoother Agile Transformation For Point-of-Sale Provider

By: Agile Velocity | Aug 03, 2017 |  Agile Transformation,  Case Study

A supplier of point of sale systems for the retail and commercial fueling industry faced an immovable deadline from a major client. While their teams were said to be practicing Agile, getting a working, shippable product was a constant struggle.

 

Agile Velocity was asked to assess their current practice and find ways for Teams to truly become Agile.

Unique Team Challenges

The assessment uncovered way process, culture, and organization structure prevented true agility. Big challenges included:

  • Poor backlog management

    Continuous drip of new features into the backlog led to project scope creep.

  • Distributed Teams

    Teams were distributed across four continents and multiple time zones.

  • Priorities Thrash

    Key team members were asked to move to different priorities at critical times.

  • Limited User Feedback

    Lack of understanding for users’ needs led to faulty product vision and waste.

  • Lack of dedicated Product Owners

  • Lack of alignment between business stakeholders and teams.

    Led to resource waste and mismanaged expectations.

  • Struggling Agile Technical Practices

    Integration threat due to individual teams working on separate branches of code and lLack of testing during Sprints

Our Solution

Agile Velocity Scrum coaches worked on location and implemented the Scrum framework with the team. At the completion of the assessment period, coaches worked with all levels of the organization to accomplish the following:

  • Product Owner Training and Coaching

    Worked alongside Product Owners to define the scope of the release and groom product backlog to only items needed to deliver a minimum viable product (MVP).

  • Fostered collaboration between home base and distributed teams

  • Led Release Planning Workshops

    Led a release planning workshop to educate teams, gain alignment across all levels, and create buy-in for the release scope of MVP.

  • Staffed Product Owners & ScrumMasters

  • Supplemented current system with tools that increased visibility

  • Provided technical coaching for improved integration and test strategy

Key Takeaways from the Client

Release management is intended to involve all of the teams contributing to the release and  starts with a shared understanding of the goals. Visibility and frequent communication through Scrum of Scrums and better tools supported decision making and resulted in a quicker resolution of issues. In addition, Continuous Integration, a good branching strategy, and a well-planned testing strategy are important when working with multiple teams who may be distributed across different locations.

Measurable business outcomes include:

  • Tighter product vision
  • Measurable business outcomes to help set expectations and measure activity
  • Improved trust between business stakeholders and development teams
  • Better decision-making and improved expectations
  • Decreased Scope Creep
  • Predictable and accelerated Release Cycles
  • Sustained Agile technical practices

Want to see what Agile can do for your company?

Learn details about this particular engagement with a product company and other examples of our work.

Blog

Smoother Agile Transformation For Point-of-Sale Provider

By: Agile Velocity | |  Case Study

A supplier of point of sale systems for the retail and commercial fueling industry faced an immovable deadline from a major client. While their teams were said to be practicing Agile, getting a working, shippable product was a constant struggle.

Unique Team Challenges

The assessment uncovered way process, culture, and organization structure prevented true agility. Big challenges included:

Poor backlog management
Continuous drip of new features into the backlog led to project scope creep.

Distributed Teams
Teams were distributed across four continents and multiple time zones.

Priorities Thrash
Key team members were asked to move to different priorities at critical times.

Limited User Feedback
Lack of understanding for users’ needs led to faulty product vision and waste.

Lack of dedicated Product Owners

Lack of alignment between business stakeholders and teams.
Led to resource waste and mismanaged expectations.

Struggling Agile Technical Practices
Integration threat due to individual teams working on separate branches of code and lack of testing during Sprints

Our Solution

Agile Velocity Scrum coaches worked on location and implemented the Scrum framework with the team. At the completion of the assessment period, coaches worked with all levels of the organization to accomplish the following:

Product Owner Training and Coaching
Worked alongside Product Owners to define the scope of the release and groom product backlog to only items needed to deliver a minimum viable product (MVP).

Fostered collaboration between home base and distributed teams
Led a release planning workshop to educate teams, gain alignment across all levels, and create buy-in for the release scope of MVP.

Staffed Product Owners & ScrumMasters

Supplemented current system with tools that increased visibility

Provided technical coaching for improved integration and test strategy

Key Takeaways from the Client

Release management is intended to involve all of the teams contributing to the release and starts with a shared understanding of the goals. Visibility and frequent communication through Scrum of Scrums and better tools supported decision making and resulted in a quicker resolution of issues. In addition, Continuous Integration, a good branching strategy, and a well-planned testing strategy are important when working with multiple teams who may be distributed across different locations.

Measurable business outcomes include:

  • Tighter product vision
  • Measurable business outcomes to help set expectations and measure activity
  • Improved trust between business stakeholders and development teams
  • Better decision-making and improved expectations
  • Decreased Scope Creep
  • Predictable and accelerated Release Cycles
  • Sustained Agile technical practices
Blog

Insurance Provider Meets Health.gov Deadline

By: Agile Velocity | |  Case Study

A leading health insurance provider was faced with the challenge of offering online benefits enrollment through Healthcare.gov.

Unique Team Challenges

The baseline assessment uncovered ways in which process and culture contributed to slow value delivery. Challenges include:

Large number of requirements

Changing Regulatory Requirements
Teams had to be aware and be able to adjust to meet changing regulatory requirements.

Struggling technical practices
Integration challenges due to poor documentation and availability of test environments.

Our Solution

Agile Velocity Scrum coaches worked on location and implemented the Scrum framework with the team. At the completion of the assessment period, coaches worked with all levels of the organization to accomplish the following:

Focus on users
Focusing on users creates a bias towards action and the delivery of highly valuable solutions. The use of story mapping, dedicated UX team members, and frequent usability testing were effective in keeping everyone focused on what’s really important.

Rehauled communication between product management and stakeholders
Commercial tools can easily be supplemented with custom tools to provide the appropriate visibility to the health of the release. This helped to make the tools support the process and not the other way around.

Testing a shared responsibility
Making testing a shared responsibility led to creative and effective solutions that can satisfy broad scenario coverage and deal with unreliable integration test environments. Test cases were discussed by the team early and often and team members had free license to create, abandon, or find new tools that would help them be more effective.

Key Takeaways from the Client

The release was constrained by the open enrollment date and features were prioritized regularly to accommodate changing requirements and user feedback.  Frequent release tracking and reporting allowed better and more timely decisions to be made.  Integration challenges were overcome through proper dependency management, automated testing frameworks, and removal of highly visible project impediments. Agile enabled the release of a valuable tool to support indirect enrollment inquiries in just 6 weeks and a full online enrollment tool in 8 months.

Measurable business outcomes include:

  • Immovable deadline MET
Blog

Sprint Planning Webinar Recap

By: Agile Velocity | Jul 20, 2017 |  Article,  Scrum,  Video,  Webinar

Thank you so much for spending your lunch hour with us. I hope you got your questions about Sprint Planning answered and benefited from listening to other questions asked by the group. If we didn’t get to your question or maybe you have a follow-up question, ask them in the comments below.

The recording and transcript can be found below. Full disclosure, we forgot to hit record at the very beginning (sad) but got the tape rolling before the Q&A started (yay!). We included a recap of the first 15 minutes below with the slides.

In the next tactical webinar, we cover Retrospectives.

Agile Sprint Planning Webinar Recording

Agile Sprint Planning – The Quick and Dirty 101

Agile Sprint Planning graphic

Every iteration, we get together as a team to talk about what goals our Product Owner has for the team to conquer – what value can we produce, or what hypothesis we can test. We review the stories our Product Owner thinks will help meet the goal, and then we collaborate about how we as a team can deliver. We talk about the tactical tasks we need to do in order to accomplish our goal. This is Agile Sprint Planning.

We typically take two hours for every week in our iteration: if we have a two-week iteration, we plan for a four-hour Sprint Planning ceremony, and a four-week iteration gets eight hours of Planning.

At the end of Sprint Planning, we have a great idea of how to achieve our Sprint Goal and have made a commitment to get it done. However, when we’ve been coaching, a common theme we see is that teams are afraid of actually committing during Sprint Planning.

3 Agile Sprint Planning Antipatterns

  • Fear of Commitment

We can make a few relationship jokes here, but so many teams have a true fear of truly committing to the work of the sprint. The Sprint Commitment is a crucial part of team empowerment and getting to predictable. The business is saying we will be hands-off your Sprint and we are empowering you to do whatever you need to do to get these things done. The team holds themselves accountable to delivering what they said they would. There shouldn’t be a fear of reprisal. This isn’t deliver or else. This is us taking the initiative to dig in and really try to get something substantial done while maintaining a sustainable pace.

Here are a few of the things that we consistently see or have seen that have that keep the team from really feeling like it is their commitment allowing them to really feel accountable to it.

The first one is the sprint being planned out before the team walks into Sprint Planning and all they need to do is give the thumbs up. If that happens, then whose commitment is it really? Right, not the teams. Then when they don’t get it done they are most likely gonna say something along the lines of, “well we thought that was a dumb idea anyway. We never thought we could get it done.”

Not actually “committing” is another thing we see. The team is like, “Yeah eh, maybe we can get it done.”  There’s not a shared commitment around the room. The team truly, All hands on deck, “yes we are going to commit to doing this.”

One of my favorites. Capacity is determined based solely on estimates with no discussion around the actual work. “Our velocity is 22, so pull 22 points in and ship it!” End of discussion.

The over-estimaters: “Let’s pull in 25 points!” The ScrumMaster comes back with, “Guys, your velocity has consistently been 20 points, but you keep trying to pull in 25. Did something change this sprint? Did you do an experiment that made you 25% faster? No? Then let’s pull in less and get to truly done. Then if we get close to the end of the sprint and we are really done, done, we can pull something else in that we think we can finish.

Or the under-estimaters: These are either the chronic sandbaggers or the ones that are afraid of getting in trouble for not finishing. “Hey Reese, you told us the goal was to get done. That last one could put that in jeopardy.” To which I usually try to encourage them to dig a bit deeper and strategize how they could complete everything.

The last one, that will tie us into the next set of anti-patterns is the team fully committing and starting the sprint without tasking as a team.

  • Tasking Antipatterns (three antipatterns in one)

When working with teams that are having problems meeting their commitments – to themselves and to the larger organization – we commonly find problems when teams are trying to task.

As we work together as a team and build a stable velocity, we begin to trust how much work we can accomplish every iteration. Taking the time during Sprint Planning to break our work down into small tasks, though, is like wearing a belt and suspenders, or like trust-but-verify. We take the time to recognize that while we trust ourselves and our past performance, there’s always a chance that we’ll find something new – a new problem or a new solution – that breaks the mold.

Another pattern we’ve seen is that teams start to look for ways to make Sprint Planning more “efficient” – for example, the lead developer in a certain area creating and estimating all the tasks for a certain type of work. While this can help Sprint Planning go faster, that’s never the point; the point of Sprint Planning is to collaborate as a team and work together to figure out how to meet your Sprint Goal. If one developer does all the estimates and tasks for “their” work, you end up with a single point of failure – when she takes a vacation, suddenly you find that your team’s estimates are all wrong, and your Sprint Goal is in jeopardy.

In order to find more efficiencies, we’ve seen teams – especially teams using a tool that makes this easy – start to build out “placeholder” or standard tasks, and filling in the tasks for certain types of work automatically. While this can speed up Sprint Planning, you’ll still miss out on the conversations you need to think through new ideas and new ways to solve problems, and likely miss opportunities to work together to find ways to improve.

When you’re creating your tasks – tasks small enough to see daily progress in your Sprint Burndown, tasks from about a couple of hours to no more than a day or two – you’re verifying that you understand what you need to do as a team and have more confidence in committing to your Sprint Goal.

However, in order to do that, you actually need to have a Sprint Goal.

  • No Sprint Goal

The Sprint Goal is the ONE thing we are truly trying to complete in a Sprint, yet we see a lot of teams that don’t have them. Why? Some teams believe that the goal of the Sprint is to try and get stories completed. False. Just like the goal of a quarter shouldn’t be to get all the projects done, the goal of the Sprint shouldn’t just be to get all the stories done.

A better goal would be, for example, “completing the upgrade process.” If this is the goal, then stories pulled in should support that goal. When you hit the end of the Sprint the product owner can assess if a few tiny things left prevent the team from meeting the goal or if they can move on. Sprint Goals allow PO’s to be ruthless with their prioritization.

Questions Polled From Past Agile Velocity Certified ScrumMaster Workshops

Q: Should you do a daily stand-up the same day that you do a Sprint Planning?

Reese: Sort of. You probably shouldn’t have it as a separate meeting–you don’t want the team to have standup at 9:00am then go back and try to get into something for 45 minutes then Sprint Planning at 10:00am. Usually, teams start Sprint Planning with a quick review of the status of anything that wasn’t completed by review. The last ten or so minutes of planning they strategize a game plan for the day.

 

Q: What does the Scrum team do after Retro and/or Review before Sprint Planning? How far in advance of the Sprint does Sprint Planning happen?

Braz: There a couple schools of thought on this. One, the team can start preparing for the next Sprint. Another option is that they go home….and that’s OK and that needs to be OK.

 

Q: No features added to Sprint once it began? How do you respond to changing requirements that are urgent and important to customers? Two weeks can sometimes be a long time to wait.

Reese: The Sprint should only be as long as the business can keep from changing their minds. If by nature, the work is interrupt-driven or just can’t be planned like support or ops work, maybe Scrum is the wrong framework for your team. Something with a continuous flow from a prioritized queue like Kanban may fit better. If you *should* be able to plan, but you have some cultural issues around trust, then it’s time to reset expectations and do some training.

 

Q: When holidays and training are foreseen and we have an average velocity we plan for, should we plan for less velocity when everyone is out of office?

A: Yes, absolutely. Let stakeholders know that for this time period, Christmas for example, the team is planning for a lower velocity. If the stakeholders know this in advance, they are given the opportunity to plan accordingly.

 

Q: During Sprint Planning, should there be a threshold number of tasks under user stories? If yes, should there be another user story created?

Reese: Break down your stories. If you don’t think you can’t get it done in a Sprint, then you should break that down into a different story. Somewhere between 4-6 stories per Sprint is the general rule of thumb. You don’t want so many that you’re doing a bunch of context switching. You want subtasks to be between half a day to 2 days so if you have more tasks than people days, you probably have too many.

Braz: Maybe the stories are getting to be too big. Follow your gut. Take a moment to ask yourself “Is this getting too complicated? Do we still understand what we’re doing? Do we still understand the value we’re providing?” If not, break down your user stories into smaller stories, not necessarily subtasks.

 

Q: What are best practices to handle carry-over work? Especially related to estimating remaining work and taking credit for completed work?

Braz: So, we get into our Sprint Planning session and with the best intentions, we say “Here are the things we’re getting to get done.” We work and work, but at the end of the Sprint, nothing is done. Now we have carry-over work that will–possibly–be moved over into the next Sprint.

The first thing we do is recognize that we don’t get partial credit. We only count velocity in terms of our ability to deliver value to our customers with predictability, not our ability to predictably keep busy. Even if we’re actually getting stuff done, it doesn’t count if we didn’t complete the work we set out at the beginning of the Sprint.

That being said, we’ve put effort into this and if our PO decides to pull this forward, we might continue working on it in the next Sprint. However, the PO has an opportunity to react to changes in the market before deciding to continue. Now, the team can re-estimate the work without changing the size of the story. You’ll notice over time the velocity levels out. The stories are the same size, it just took a little longer to complete.

 

Q: What’s the role of the “Definition of Ready” in Sprint Planning?

Reese: This isn’t technically a by-the-book Scrum practice. It’s something that’s come up in the last few years as teams have wanted to get closer to predictable.

Some teams want to define ready just like we do with done. Defining ready is all about deciding what things need to be checked off before an item is pulled into a Sprint. These things can include “item is estimated”, “dependencies have been knocked out”, “all questions are answered”, “design and team have initiated some sort of visual mock”, etc. Your Definition of Ready really depends on individual teams because it’s all about defining what you need to be nailed down in order to get to predictable.

 

Q: Do you factor in time for the look ahead/grooming sessions (multiple per Sprint)?  And should the look ahead/grooming be with the entire team or just 3 amigos (to keep the team in flow)?

Braz: When we talk about the ceremonies in Scrum, backlog refining isn’t an official ceremony. However, a team (especially when a team is getting started) should absolutely reserve the time necessary for things like refining the backlog. Almost as much time, if not the same amount of time, that they set aside for Sprint Planning.

When you first start out, you probably do need the entire team involved because of the number of perspectives both in terms of expertise and of skill level. Once your team has started to really gel and flow, you might be able to bring it down to just the three amigos– meaning a PO, a developer, and a tester to ensure that you maintain varying perspectives. However, it would be a good idea to periodically switch those individuals out to keep perspectives fresh.

 

Q: We do big room planning every quarter to break down features, create stories, and estimate. What is the place/scope of Sprint Planning in this case?

Reese: Backlog refinement isn’t necessarily a traditional Scrum ceremony. However, that big room planning is kind of a higher-level backlog refinement. Just like with a normal, every sprint backlog refinement session, you still need a Sprint Planning session to really dig into to tasks and break down what needs to be accomplished within a single Sprint as opposed to within an entire quarter like you would in a big room planning meeting.

 

Q: What if POs are not attending the planning sessions, and the Technical Program Manager is running the show?

Braz: As a coach, the first thing I would ask that Technical Program Manager and PO is if that PO is really a PO. A PO needs to be able to do 3 things:

  1. Be available to the team – If the PO isn’t available, the team will be slowed down because they’re waiting to hear back from the PO and will, therefore, lose predictability.
  2. Be knowledgeable – The PO needs to be able to answer the team’s questions. They need to have a little technical expertise and an awareness of what the customer specifically needs.
  3. Have the authority to make decisions – It doesn’t do any good if a PO tells the team the items that need to get done, if someone is going to come along and override them.

If you don’t have all three of these, then you probably aren’t actually the PO. So the question becomes does the PO want to be PO? Or do they want to let someone else take over that role while they fill a different role?

 

Q: Our release is six weeks and we have a model of six Sprints that last six weeks as well. How do we get out of this antipattern?

Reese: So the simplest answer is that you don’t have to release every Sprint. Your Sprint is attempting to get you to a potentially shippable product increment. That doesn’t mean it necessarily has to be shipped. You just need to be hitting your definition of done and to be in a place where you don’t have a ton of extra work. You don’t want to do 6 weeks of Sprints and then half a Sprint of unfinished work. So you don’t have to tie your Sprint to your release cadence.

 

Q: Should the team look at the product road map (if you have one) at the end of the Sprint to evaluate product launch risks & Sprint goal validation?

Braz: Yes, that’s a great idea. This reinforces the idea of a Sprint goal. We have those for your customer advocate, your business representative, for the PO on your team. It expresses the customer-facing problem that you’d like to solve and what you’d like the team to focus on. Then, it creates the space for your team to come up with some innovative solutions to that problem.

Your roadmap absolutely talks about the features and functionality of things but it also needs to start incorporating how to solve these customer facing problems. The roadmap becomes customer facing problems that we need to solve versus functionality that we’re going to release. That’s when it absolutely becomes incredibly helpful to have that roadmap to refer to in terms of reaching the goals that we’ve set out to accomplish.

 

Q: What is the best way to size tickets? Should it be in terms of hours, business days, story points, etc?

Reese: As humans, we’re pretty darn terrible at estimating hours and days, but we’re really good at estimating things relative to another. We can tell when one thing is smaller than another, or that this thing is 2x as big as this over here. That’s what we try to do with our work and that’s kind of where story points come in. Story points are a relative number that encompasses size, effort, and risk that we give to our work to help us estimate.

A lot of teams do tasks in hours, which is fine. If you’re off in your estimation by a few hours, it’s not that big of a deal. However, when you start to estimate in larger amounts of time like days or weeks being off in your estimates starts to become more damaging and there’s a potential to put the Sprint at risk.

Braz: It’s all about getting your team on the same page.

 

Q: In Sprint Planning, how do you estimate time (number of hours) for allocating maintenance of the product and enhancement of the product?

Braz: This is a coaching moment for the PO. We don’t create a Scrum team to focus solely on new features and functionalities. I’m creating a Scrum team to own a product. And that product backlog includes everything, all the works visible–even if it is maintenance or enhancements of existing products. So you don’t allocate time for maintenance, you treat maintenance just like you would treat new features and functionalities: you put it in the backlog and let the team estimate the work. It also needs to be prioritized in the backlog and evaluated by the value it brings the customer just like new items would be.

 

Q: What if the team realizes that a story was too big and we refactor/split story? Does it count if we refactor the Sprint goal, also?

Reese: A Sprint goal doesn’t have to encompass completing an entire segment of the work. Something like an upgrade process could take 3 Sprints. In that case, you want to break that goal down into pieces that will fit into a Sprint. Really think about what you can realistically get done in that set time period instead of just getting some of it done.

 

Q: What’s the value of estimating both user stories (in points) and tasks (in hours)?

Braz: So we touched on this a little bit earlier but I say go for estimating in some form of relative measure. Whether that be the Fibonacci sequence, estimating in shirt sizes, powers of two, or whatever as long as it’s a non-time based estimation.

The value is two things:

  1. It gives the PO some visibility into the work in the backlog and gives them a relative idea of your velocity as a team. They can then begin to see where they can group things together and begin to prioritize based on those relative estimations.
  2. What happens when your team gets better or you suddenly gain automatic testing? When those things happen and we estimate in time, we’ll have to reestimate everything because the old estimates are no longer valid. On the other hand, if we’re estimating in relative terms, then our estimation is still just as good. Our velocity just went up because now we have more capacity.

For tasks, it really is trust but verify. As the team gets better and better, they may not spend as much time estimating tasks because they just know. But there’s always going to be that one user story that has something you’ve never seen before. In that case, the team needs to know when they might need to go back to estimating in hours again. That would give you the visibility to say “If we have x number of hours available to us over the next week, how likely are we to actually get this done?”

 

Q: We [UX] work so far in advance that usually, we’ve got assets on the shelf for Scrum to pull down. What’s starting to happen is that Dev is getting behind and then the assets need to be revisited for any number of reasons even though the PO thinks he’s got all this design work “done” which isn’t really accurate. We used to be involved in release planning and showed POC/high-level wires, but now those meetings are too late in the timeline for us. So I’m trying to determine a more collaborative approach. Advice?

Reese: I hate to say it, but you’ve got to get closer to the team. It’s not that Dev is getting behind, it’s that you guys are getting way out in front. Dev is working at the pace they can and you guys are there as part of that team too. You should have one foot in the Sprint and one foot in the Sprint before– but not months before. You want to be there really making sure that the next things in the backlog are ready to go.

We were once in a land of product delivery, and we need to shift ourselves into a product discovery mindset. We have to know that things are going to change. As soon as we get in there and start putting fingers to keyboards, we’re going to learn things. We want to get things out there and in front of customers as fast as possible, so that we can tighten that feedback loop and shift as we learn more.

If you’re doing things so far out in advance, not only are you not going to be benefiting from your real-time customer feedback, but you’re also going to get a little white-knuckled. That’s because you’ve already done a lot of work. If you do learn something new from feedback, you’ll be hesitant to shift because of how much work you’ve already done. However, that’s not the world that we live in. We live in a fast-paced, quick-to-change world, and we want to be ready for that. That’s the real goal.

So bring it in. Get a lot closer to your team. You really want to live in that 2-3 Sprints out zone, where you’ll be doing your backlog refinement. Then you want to figure out how to test features as soon as you get them so you can get in front of the customer.

Braz: Not only will you have to respond to customer feedback, but you’ll need the flexibility to respond to changes in the market as well. You never know when changes will come about.

Also, don’t be afraid to get out of your comfort zone. If you’re really comfortable doing UX, but the rest of the team is falling behind, it might be time to step back and see what you can do to help the team out.

 

Q: What’s the difference between a Technical Product Manager and a Product Owner? My company only has TPMs.

Braz: I don’t care what you really call them. From a title standpoint, it doesn’t really matter. The role of the Product Owner, however, is pretty explicit in the Scrum Guide. The person that plays that role, whether that’s the TPM or the PO, needs to be the person who is ultimately responsible and accountable for the decisions that need to be made around the things that should be delivered.

They need to know the customer value that the team is working on and what things are being delayed. The person in that role also needs to be available, so when the team has questions they know who has the authority to tell them what they should do. This way the team can keep delivering on a regular cadence and maintain predictability.

Regardless of their title, if someone can be available, has the knowledge, and has the authority to make decisions, they can wear the PO hat. Anyone from any part of the organization can fill the role of PO if they have those three things.

 

Q: How does Portfolio Management benefit and/or impact our Sprint Planning?

Reese: There are going to be tons of benefits and tons of impacts. But the one thing to make sure you don’t have happening in your organization is that Portfolio Manager just handles the Portfolio Kanban and/or roadmap and tells people when they’re going to do things.

The PO and the Portfolio Manager work together to make sure that everyone is on the same page and that expectations are being set. There be impacts when something shifts or something comes up, and that does happen. If that happened between backlog refinement and Sprint Planning, you may have to do some refinement either at the beginning of Sprint Planning or in a new session. You have to prepared for things to change sometimes. The big thing is making sure that there is a very, very solid line of communication between those two groups (the PO and the Portfolio Manager).

Braz:  When Portfolio management is done well, it provides clarity and a sense of purpose, and it makes that Sprint goal crystal clear on an organizational scale. They help create alignment.

 

Q: If we estimate stories using points, is there value in also estimating tasks for each story?

Braz: Maybe. I don’t mean that to be a wishy-washy answer, but I’ll answer your question with a question: How are you actually delivering on every Sprint? Are you getting everything done? Do you have a level of predictability? Are you at the point where you can say that you have a stable velocity, and you understand what’s going to get done, and we’re correctly sizing things every Sprint without sandbagging?

If yes, it may not be worth it. You may not need to make those tasks because you understand what comes up every single time. I would just keep in mind, when things come up new, keep that task level estimation in your back pocket. Trust but verify, so that your team will still know what’s going on even in light of that new, unexpected thing.

 

Q: We do native mobile development, so we have android and iOS. A lot of times, that feels like two separate teams. Any best practices around planning with two “sub-teams” in a Scrum team?

Reese: I was actually a Product Manager for an Android and iOS team once upon a time, and it was a challenge to keep them on the same page. We actually had them as two separate teams. There was a lot of confusion around one team learning something and not telling the other team or other things along those lines. So you want to make sure that if you are going to have those as two different teams or “sub-teams” that you do meet together. Do things like backlog grooming together and even some Sprint Planning.

From the sound of this question, you guys really do have Android and iOS as one “Mobile” team, and sometimes it can likely feel like you’re dividing meeting time to talk about two separate groups of work.

So a best practice is to really make sure that you are talking about those stories that really do apply to both the Android and iOS application because they are vertically sliced. So, you really want to treat this team like any other scrum team that is working on a vertically sliced product increment: something that is valuable and independent. They’re all playing their part in the team.

But take this question to the team. See what works. Retro on it so that everyone is getting what they need and you guys as a collective team are coming up with solutions.

Blog

From Chaos to Acceleration

By: Agile Velocity | Apr 18, 2017 |  Case Study

Due to continuously missed deadlines, a growing product company specializing in tech and marketing products for credit unions and small regional banks were in danger of pleasing their customers. Leadership identified the threat and realized the organization needed to implement a change to win back their customers’ trust and confidence.

Unique Team Challenges

As with most organizations, a deeper look found that in addition to processes, culture and behavior also contributed to slow and unpredictable release cycles.

Waterfall
Traditional development process (Waterfall) contributed to unnecessarily long release cycles (3 – 6 months).

Changing Product Vision
Lack of communication and collaboration contributed to thrash and changing product vision.

Team Structure
Teams were organized by specialists rather than cross-functional teams.

Costly Rework
Extra-long feedback loops between development and testing resulted in costly re-work.

Manual QA
2 – 4 month QA testing period due to manual processes.

Our Solution

Agile Velocity Scrum coaches worked on location and implemented the Scrum framework with the team. At the completion of the assessment period, coaches worked with all levels of the organization to accomplish the following:

Agile and Scrum Implementation
Agile Coaches and Trainers worked with teams and leadership to teach and implement Agile and Scrum over a period of months.

Creation of Product Owner Roles
Coaches worked with leadership to create the Product Owner role and help those stepping into the role to own new skills and responsibilities including how to increase communication between stakeholders and manage expectations.

Cross-functional Feature Teams
Coaches worked with Leadership to create Agile cross-functional teams focused on small increments of functionality.

Collaboration Between QA and Development
Coaches worked with Leadership to help find ways to foster collaboration between QA and Development.

Test Automation and CI/CD
Coaches worked with Leadership to invest and help implement in Agile technical practices such as automated testing and CI/CD.

Key Takeaways from the Client

By receiving buy-in from all levels of the organization, Agile Coaches were able to guide the Scrum Teams to self-organize and rise to challenges that seemed unsolvable. Customer surveys that once showed frustration now have positive feedback from better products and shorter releases.

Measurable business outcomes include:

  • Decreased Scope Creep
  • Accelerated Release Cycles (From 3 – 6 months to 2 weeks)
  • Foundation for more Agile technical practices
Blog

8 Roles Agile Coaches Play

By: Agile Velocity | Mar 07, 2017 |  Agile Coaching,  Article

Vince Lombardi. Phil Jackson. Kathryn Smith. These are some of the greatest Coaches in the history of sports. But what does being a Coach really mean? While they are experts of the game at hand, chances are, being an SME is only 50% of what a Coach does or is. A great athletic Coach takes on many different roles throughout the relationship, from being tactical like a defensive coordinator to providing guidance as a mentor. The same is true for an Agile Coach. 

By effectively and fluidly moving between different roles, a good Agile Coach can apply their knowledge and talents to help their clients achieve their best results as quickly as possible.

Hands-On Expert

First and foremost, an Agile Coach is an expert on Agile methodologies and on using them to improve the overall performance of teams, teams of teams, and leaders. And by expert, it’s not about memorizing frameworks. It’s about having real-world experiences to take the principles, values and frameworks and apply them to get results. Sometimes, this means that your Coach isn’t going “by the book.” 

Teams and leaders new to Agile often don’t know where to start. In this case, a Coach might choose to run a “team chartering” play to stand-up some new teams. If it is a bigger transformation, that could mean working with leadership to help them create the transformation plan and build an Agile Leadership Team. If an organization needs to re-start a stalled transformation, an Agile Coach can also help to assess current state and then use the findings to create an appropriate transformation strategy to move toward the desired future state.

Reflective Observer and Truth-teller

Agile is not a silver bullet. Rather, Agile is a silver mirror. Agile Coaches taking on the Reflective Observer role will notice the interactions and reactions and, without judgment, provide you with a perspective you may not have noticed. The neutral, third-party perspective also gives credence to what internal team members have also already observed and communicated.

Facilitator

As your Coach works with you, there will be times where they will need to step into the role of Facilitator. Instead of teaching or mentoring, a Coach working from the role of a Facilitator will use their skills in conflict resolution, meeting facilitation, group dynamics, and personality styles, among others, to help your organization. Sometimes, these facilitation skills are used to help a group come to a decision when strong opinions and personalities stand in the way of productive conversations. Other times, a Coach takes on the Facilitator role to help present new ways to make existing meetings and events more effective.

To be effective in the Facilitator role, a Coach uses their experience helping teams in similar situations with the professional facilitation skills they’ve learned and adopted over the years. They help your teams become better communicators, with clearer understandings and more effective meetings.

Modeler of Behaviors

An effective Agile Coach is constantly looking to model appropriately aligned behaviors.

In any move toward Agile-aligned practices and principles, people and the teams they’re on will struggle with adopting new ways of working. They have learned through their careers how to perform and even excel in the previous environment. Therefore, those learned behaviors for success can often work against team performance and Agile-aligned principles and practices in today’s VUCA (volaltile, unpredictable, complex, ambiguous) world.

While working with performers on those teams and with leaders and managers, an Agile Coach strives to model new aligned behaviors, even to the point of over-correcting. This could mean performing their own “failure bows” and explaining how something they did didn’t align with what they strive to model for their clients.

Counselor

When a Coach is working with an organization, she will come across times when introducing and embracing Agile practices create friction, tension, and stress. During those times, your Agile Coach will adopt the Counselor role to help teams and leaders. As a counselor, your Agile Coach will use their active listening skills to create a space where problems can be discussed with honesty and safety.

By creating this safe environment, your Coach uses their counseling skills to help come to a clearer understanding of the problem currently being presented and helps to prepare the client – the person, the team, and the organization – to more effectively explore and evaluate solutions.

Mentor

Mentoring is a hands-on, one-on-one approach to helping someone learn. Similar to the apprenticeship model of career growth, an Agile Coach in the mentor role develops a close and trusting relationship with the individual they’re looking to help. In this role, the Agile Coach leverages their experience and expertise to help explain not just the practices associated with how their apprentice could do their new job, but also the principles behind what makes those practices personally relevant.

One example used at Agile Velocity is the “Lead / Assist / Observe” pattern; this pattern is frequently used when mentoring Scrum Masters in organizations. Your Agile Coach will initially lead the Scrum events, establishing best practices and patterns first by example. After leading these events, the Coach will work with your new Scrum Master to answer questions and explain the decisions made during the events, and potentially role-play scenarios to help expand the new Scrum Master’s knowledge.

Your Agile Coach will then assist your new Scrum Master with the next set of Scrum events. Your Coach and Scrum Master will pair together to lead the events, and your Coach will begin to fade into the background, allowing your Scrum Master to facilitate the events while still having the security of a trusted advisor and expert in the room. After, your Coach will again work with your Scrum Master to help expand their comfort and knowledge, equipped with real examples from their work together.

Last, your Agile Coach will observe your new Scrum Master as he facilitates the Scrum events. Your Coach will remain silent and available, offering support and guidance after the events. This helps your Scrum Master gain the confidence to stand on their own while still feeling like they have the support of your Coach.

This pattern helps establish a trusted relationship between your Coach and Scrum Master and illustrates one of the many ways a Coach takes on the role of an effective Mentor.

[Learn more about utilizing an Agile Coach for a successful transformation in our infographic, Implementing Agile.]

Teacher

Sometimes, your Coach will notice that there’s some basic level of knowledge that’s missing; similarly, there are moments where reinforcing previously learned practices or information would be more impactful than letting a team struggle through a situation. In these times, your Agile Coach takes on the role of a teacher.

Teaching can take many forms – from the image of the professor imparting knowledge through presentations and classroom-like activities–to the interactive learning from collective group activities and many other learning modalities. An effective teacher has command of several different techniques to present and reinforce knowledge, both in a formal classroom-like setting and in ad hoc teaching moments that come up every day.

Coach

Different from a teaching or mentoring role, when your Agile Coach puts on the Coaching role, their focus changes from knowing to unlocking. As a Coach, they operate from the assertion that the person they’re helping has the knowledge and ability to solve their own problems; as a Coach, they help them unlock that knowledge through powerful questions, supportive practices, and helping hold their clients to their commitments to themselves and others.

An Agile Coach frequently pulls from their experiences and knowledge – not just of Agile, but from their careers outside of Agile, their other roles listed here, and their understanding of their client – to validate or challenge their client’s narrative. They help our clients create a new narrative more compatible with this new Agile way of being and provide them the support and guidance needed to fully embody their new narrative.

Partner

The last role listed in the model is that of Partner. Agile Coach must not only be aligned with but must also be invested in your organization’s long term goals. 

And those goals include building organizational self-sufficiency – so that continual improvement can happen in the absence of the Coach themselves. Therefore the Agile Coach plays a key role in creating  Coaching competencies in your organization. By using all the roles listed above, and by working with people within your organization to increase their own skills as Agile Coaches, your Agile Coach will help build the internal Partners you need to keep your Agile journey moving forward and accelerating your business goals.

Long story short, while you may have signed up for an Agile Coach, you should expect the one role to take on seven others throughout the engagement.

Many Roles Embodied in One

Long story short, while you may have signed up for “one” Agile Coach, you should expect the one role to take on many others throughout the engagement.

What has been your experience working with Agile Coaches? If you’re an Agile Coach, is there a role we may have missed? Please leave your comments below.

For more on our approach to building lasting business agility, you can check out our Transformation Services page.

Blog

Agile Team Coaches: What Do They Even Do?

By: Agile Velocity | Feb 20, 2017 |  Agile Coaching,  Article

Agile coaches are subject matter experts in Agile principles and practices and they apply their knowledge towards guiding struggling individuals, teams, and organizations. They are called when teams and organizations begin their Agile transformation, or if they when teams start and see realize that the road to high-performance may be rockier than expected. In both settings, the mission for the Agile coach is clear: help make the people, teams, and organizations they’re working with better by unlocking their potential.  

Hmmmm….a little nebulous?

What “better” means is different for every organization. Organizations embark upon an Agile adoption because of concrete goals they hope to achieve: faster time to market, improved quality, or happier customers. At the beginning of each engagement, the coach will work with stakeholder to define success and how it will be measured.  

(more…)

Blog

Do this, Not that: 8 Bad Habits Sabotaging Your Agile Transformation

By: Agile Velocity | Nov 16, 2016 |  Agile Transformation,  Article

break bad Agile habits, build good habits - motivational reminder on colorful sticky notes - self-development concept

There are a lot of bad work habits: being late, checking Facebook too* many times, not putting your dirty coffee mug in the dishwasher, and interrupting your coworkers during meetings. Bad habits are “bad” because results are negative. They become even more destructive when they directly oppose a goal, e.g., late-night eating when you’re trying to lose weight.

It’s the same with Agile.

During an Agile transformation or adoption, behaviors that were innocent, even positive, can pause momentum or even BLOCK progress. That’s because Agile is not just a process change. Truly becoming Agile involves updating practices and taking a long, hard look at company culture. Below are nine bad behaviors to curb and good replacements if you want to make sure Agile sticks.

(more…)