Webinar Archives - Page 3 of 3

Blog

Webinar Recap: The Evolution of a User Story

By: Agile Velocity | Nov 02, 2017 | Agile Tools, Video, Webinar

User stories are a staple in Agile but it can still be a tough practice to master, particularly for newer teams. A user story is defined as a short description of a feature or product told from the perspective of the end user or customer. They typically follow the same simple format:

As a < WHO >, I want < WHAT > so that < WHY >.

Many Product Owners we work with find themselves struggling with when and how to break their epics down into actionable user stories. Another challenge? Team members get frustrated because the user story doesn’t capture all of the details needed to begin work and complete it successfully.

How do we fix this?

Our Agile Coaches, David Hawks and Braz Brandt discuss the “when” portion of breaking down epics into user stories and how you can get into a regular cadence of evolving your backlog through collaboration between Product Owners and the Dev Team in this recording of our December webinar, The Evolution of a User Story.

Q&A Transcription

1. Looking at the lifecycle of a User Story, as a Product Owner, how do I how do I balance PO responsibilities (stakeholder management, decomposing epics, etc.) with being available to the team so that they can continue to be a high performing team?

David: There’s actually some language that’s been lightening up in the Scrum Guide around who actually does all the work. Traditionally, it’s been the PO who does all the data entry and whatnot after Backlog Refinement. Now, it’s something that the entire team might help finish. When the PO is overloaded, the team needs to recognize that and find ways to relieve that pressure.

2. Where do things like Behavioral Driven Development (BDD) or writing in a Gurken format (given…when…then…) tie into the traditional User Story format?

David: So some people use these formats for writing acceptance criteria, and that can be helpful. For me, that can sometimes be extra overhead. I think teams might take things too far at times.

If you’re writing acceptance criteria in more readable language, and then those acceptance criteria then become automated tests, that can be pretty valuable because we’re not having an extra translation step. However, if you’re not doing BDD, and not actually automating those tests, then it might be too much extra ceremony or overhead for the team.

My advice is to make sure that you’re keeping a balance when trying either of these methods.

3. I find it near impossible to write plumbing type stories from the user’s perspective. I run a small team, so our velocity doesn’t always allow for user value in a single sprint when plumbing or re-plumbing is required. What is your advice? [Plumbing meaning the database code, the API layer, service, microservice, etc. The stuff underneath the product.]

David: Let’s take a look at this diagram:

What we see a lot of times is that teams are structured in terms of database, middle tier, or UI, etc. What we don’t want is to write a story from a component or architectural dimension. That’s not actually a valid story. So that’s probably the challenge that you’re running into: You’re trying to write a story for something that is actually a task. We need to think about writing the story from the user’s perspective. This could be a challenge for your team for multiple reasons:

Your team is made up of just people from that plumbing level (like one of the black ovals in the diagram). This could be problematic because then you have a component team. These teams are challenging because they don’t have all the capabilities to deliver a user story. So in Agile, when we talk about creating cross-functional teams, we mean a people from different levels creating a feature team, so that we get multiple capabilities and perspectives to form a functional user story.
You don’t need a user story for the issue! The re-plumbing question is a good example of this. This issue likely comes from a case of already having the functionality, but now there’s technical debt problems or refactoring that needs to be done. In that case, a user story might not be necessary. Remember, we don’t have to force everything into this user story format.

4. How do you handle stories that are highly technology driven? For example, an internal department delivering to a larger organization’s IT developers?

David: The first test I’m always going to apply is “Can we build a cross-functional team to simplify dependencies?” The Agile answer is to put as many of the dependencies on the same team as we can so that they are all working together. Conway’s Law tells us that we have a tendency for any structure built within an organization to mimic the organization’s structure. That creates issues in technical structures because it causes us to overcomplicate our technical architecture which can make it difficult to put all of those skills onto one team. Sometimes, it’s more than just putting people together and more about taking a look at that technical architecture and perhaps refactoring.

Now let’s say we have done all of that. At the other end of the spectrum, there’s a scenario where you need a system persona. Say the “customer” that you’re writing code for is a pharmacy system. In that case, it’s okay to write a user story from the perspective of that system persona. The team that writes that user story might not have a UI because they only deliver to that pharmacy system, and that’s just fine!

What we don’t want to do it abuse that technique.

Braz: Yeah, I’ve used that method quite a bit. It’s important to be thorough when it comes to external vs internal users so that you don’t get mixed up. It’s all about understanding the user perspective.

5. Your example involved 16 weeks of backlog refinement before the first sprint starts for the new features, but I often have a hard time getting the backlog refined 4 weeks prior to the start of the sprint. What is your advice?

David: First, when I think about the backlog, I think about it like this:

There are things at the top, maybe some larger ones in the middle, and maybe even some extra large items at the bottom. Typically, we want this backlog to have at least 2-3 sprints worth of ready stories. Some teams even like to include a Definition of Ready (DOR). So by the time we get to Sprint Planning, we have the top 2-3 sprints worth of stories refined.

Also, we want everything that’s in our current plan or forecast is sized—they all have an estimate on it. We want all of these things sized so that if something new needs to get added to our backlog, we know what/how much needs to be taken away to still keep our forecast on track.

If the stakeholders or teams are slow to provide necessary feedback, maybe you just need to set some time on the calendar, get them all in a room for an hour or two, and get stuff done. Incorporating a consistent cadence of backlog refinement with the team into each sprint could help you stay on top of your backlog as well.

6. The previous question mentioned 16 weeks worth of work. How does that translate into actual time spent for the team? Also, what are your tips on accelerating conversations with the team when it comes to trying to get everyone into the room and providing feedback?

David: As far as tips go, I would start by breaking it down. Let’s first take a look at how much time is truly spent with the team over those 16 weeks. If we spend 5 minutes in our first meeting with the team where we do rough order magnitude, then maybe 15 minutes in a Backlog Refinement session, then another session where we spend 10 minutes breaking down some stories into tasks, then time totals to somewhere around 30-45 minutes total as a team actually working on backlog refinement.

Braz: If refining the backlog becomes a team effort in Backlog Refinement, then the work of inputting things into Jira or on a board becomes something anyone can do.

David: If it’s the highest priority, then the team should swarm to get it done.

7. UX activities – how do you recommend accounting for these in context of User Stories? Do you recommend creating User Stories for UX work or define these as self-standing tasks or subtasks, tasks, or simply as acceptance criteria for User Stories?

David: It sounds like the first question we should ask is if the UX person is working as a member of the team or outside of it. That’s going to dictate your solution. Having that UX person as a member of the team is obviously going to be more ideal.

If the UX person is a member of the team, then we want to make sure all of our work is visible. How do we do that within a tool, like Jira? It’s not always simple, and there’s not a perfect answer. I have seen teams create a Jira ticket—not really a user story—as something to create visibility. These tickets are simply there to show what the team is working on. It could be called something like “Prepare for Stories 1, 2, and 3”. Tasks associated with this could be things like meetings. While this isn’t necessarily work that takes place under a story, it is reflective of what the team is really working on.

So don’t get too hung up on making everything a user story. The focus here would be to make your work visible to the rest of the team.

8. Do you create separate “user stories” (or some other card type) for technical work that needs to be done to realize a User Story? Like “Create Database Scheme”, or “Do Development Work”, etc.? If so, what do you call these card types, and what content do you put in them?

David: From a Scrum definition, we would call those tasks. Jira would call those sub-tasks—not to be confused with Tasks, Jira’s straight-out-of-the-box version of a User Story. Most of the time, these sub-tasks underneath user stories don’t have much detail at all. The reason for this is that the whole team is present as they’re being created and we’re only creating these sub-tasks for the next two weeks. If we were creating them 6 months in advance, we’d probably need more detail to recall what the heck we were talking about. When we’re only planning for a two week sprint, they’re fresh in our collective mind and we don’t need all of that extra work to be done.

As far as documentation of design and other things, Jira isn’t the place for that. Instead, you can put that on your favorite Wiki software, like Confluence. Sub-tasks or tasks are very transient things—they should go away after two weeks. If you have a co-located team, we even recommend tasking on a physical board where tasks are sticky notes on a wall so that you can just toss out the sticky notes at the end of your two-week sprint. Your stories should, of course, be documented in Jira, but the tasks aren’t meant to be extensively documented. You just don’t need it.

Braz: This takes me back to User Stories 101—it’s the 3 C’s. We can have a ticket and the ticket can describe some user value, but the ephemeral conversations that we have on a day-to-day basis about how we’re going to turn those tickets into real-life user value. Also, how we’re going to capture the outputs of those conversations in things like delivered software, just-enough documentation, and long-term artifacts.

Looking for more information on user stories? Check out these articles:

4 Characteristics of a Personable and Useful Customer/User Persona

Why You Need to Jazz Up Your Boring User Stories

Blog

Overview of Agile Scaling Frameworks – Webinar Q&A

By: Agile Velocity | Oct 20, 2017 | Leadership, Video, Webinar

We recently hosted a webinar exploring 6 major Agile scaling frameworks: SAFe®, DAD, LeSS, Nexus™, Scrum at Scale, and Enterprise Scrum. We had a blast, but we were unable to address all the questions asked during the Q&A portion.

You can find the recording below. We also took some time after the webinar to answer the remaining questions (below embedded video). We hope you were able to shed some light on the different scaling practices. If you have further questions, don’t hesitate to reach out. We will also be creating a white paper about scaling, with extensive coverage on SAFe®.

Overview of Agile Scaling Frameworks – Webinar Recording

1.What framework best fits (or is most adopted) by highly-regulated enterprises (such as financial services, healthcare, etc)?

Both SAFe® and DAD have constructs that make working in a regulated environment easier, such as solution intent, a repository for requirements, and traceability maps.

2. How do these frameworks handle the “exceptions”—last minute, high-priority items that do not fit into the regular timeline? How do you short-circuit the process?

All of the frameworks include the concept of a prioritized backlog, and several have backlogs for different levels. When a high-priority item comes in, the Product Owner (or content manager at the appropriate level) orders the request at or near the top of the Product Backlog. At the next Iteration Planning meeting, the new request is likely chosen.

3. Is there a checklist/comparison chart to pick the right and possibly best framework for an organization?

There are several comparison charts available from various sources. One good one is from Box. We certainly advise the use of an Enterprise Agile Coach to help you make the right decision, as it is often not just a single framework—most enterprises need a custom solution.

4. Do you have a list of companies or products that have successfully adopted each of these frameworks?

These lists and case studies are available on the websites for each framework.

5. Do these methodologies apply to other departments in an organization (with many departments e.g finance, marketing, etc.) OR are they meant for the IT Departments of organizations and software companies (whose only product is software)?

Each of these frameworks is generic and work quite nicely in non-IT environments. Over the last 10 years, more and more organizations such as HR, Marketing, Sales, Operation, etc. are using Agile and scaled solutions.

6. I’ve got about 5-7 Agile teams about to be realigned to newly defined product lines, most currently use Scrumban for execution. I’m leaning towards recommending LeSS to leverage the familiarity with ceremonies and cadence. We don’t have a critical need to incorporate business side at this time, which is why SAFe® was lower. Any pitfalls you see with this approach?

No pitfalls at all. LeSS is a great choice for you, especially if you would like to introduce some Lean economics type thinking into your organization. You may also want to take another look at Essential SAFe®. It is a 2-level approach for Agile teams and Agile programs (no business level).

7. Any quick advice on how to tell if an organization is “doing Scrum well”?

The classic evidence of “doing Scrum well” at the team level is each team is delivering business value each iteration, they are using WIP Limits to optimize flow, and they have tangible evidence of improvements over time.

8. Is the assumption for all these scaling models that “all teams will follow Scrum”? Are there any models for scaling that accommodate organizations with Scrum and Kanban teams?

Absolutely. Both SAFe® and DAD accommodate Scrum and Kanban teams quite nicely. Nexus™, LeSS, Enterprise Scrum, and Scrum at Scale are focused only on Scrum.

If you’re specifically looking to start a SAFe^® implementation, we recommend starting with Leading SAFe^® training. You can explore our public and private training options on our Leading SAFe^® training page by clicking here.

Blog

Scrum Roles Q&A Recap and Recording

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

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

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

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

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:

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.
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.
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:

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

WEBINAR – Stop Sabotaging Your Agile Transformation

By: David Hawks | Mar 29, 2017 | Agile Transformation, Leadership, Video, Webinar

An Agile adoption and Agile transformation require a lot of change at all levels of a company. Most importantly, it’s more than a process change, a concept that can cause leaders to stumble as they move their teams forward. For leaders, it’s important to leave some traditional management ideas behind in favor of a more Agile leadership approach. In this webinar, David Hawks breaks down four major obstacles leadership faces during an Agile adoption and transformation:

Driving vs. Supporting
Lack of Support to Improve
Drowning in a Sea of Opportunity
Focus on Output vs. Outcome

Webinar Recording

Webinar Q&A

Besides time and having management show support, what tips do you have to encourage former waterfall employees to access self-empowerment?

Empowerment takes a mindset shift from the entire team. The best advice would be for managers and ScrumMasters to continuously encourage the team to share their ideas and try new things, and hold them accountable for continually practicing these methods.

Another way to do this would be one-on-one conversations where managers can ask questions to find out what the team needs to continue improving.

When you are changing the way leadership prioritizes items and transforms the urgent projects into a backlog for the team to pull from, what practices do you recommend?

When it comes to prioritizing, you never want to approach it with a divide and conquer method. Instead, use techniques that will bring stakeholders together and get them talking to one another about the projects they want to prioritize. This should be a collaborative process.

You can look for tools online to practice this mindset, such as Buy a Feature by Innovation Games. Story mapping is another great tool that can help a team prioritize within context. You can learn more about this technique from Jeff Patton’s book, Story Mapping.

What’s the biggest factor in moving from downward chaos to upward growth?

So this question refers to the pivot point between Chaos & Resistance and Integration & Practice on our Path to Agility®. You can really see that a team is transitioning into the Integration & Practice stage when they become more comfortable with the language of Agile. This typically takes around 3-6 sprints, which are essentially cycles of learning. It’s important for the team to have this period where they can practice the techniques they’ve recently learned and begin to get comfortable with the new system. A key factor of this cycle of learning is the retrospective, where the team can really focus on how to improve their processes.

Have you seen this practice work well in IT infrastructure teams?

Yes, we’ve seen that Agile’s core principles still apply. However, Kanban typically works better than Scrum when it comes to IT infrastructure. Kanban provides a more continuous flow of tasks as opposed to weekly plans. Because IT infrastructure usually deals with more interim driven work rather than work that can be planned out in advance, this framework tends to be a better fit.

What tips do you have for encouraging cross-functional teams in a matrix organization?

This question addresses the biggest factor that keeps organizations from truly getting all the benefits of Agile they are seeking. However, finding a way to address this is difficult because it’s not a one-size-fits-all solution. It really depends on the culture of the organization.

Some companies have fixed this by having feature teams initially report straight to the VP. This empowers the teams and stops them from continuing bad habits that arise from reporting straight to output focused managers. Then, once the managers also get a handle on their new outcome focus, they are placed into the feature teams. This process can help encourage a smoother transition of the company mindset from output to outcome.

Is this directed primarily at software development or an overall business operational culture?

Most Agile adoptions come out of the software world but Agile methodology applies across the board. Often, organizations think the problems are confined to the software department when in reality the entire organization needs to change. From the executives to HR to marketing teams, Agile is effective for all levels and parts of a business.

For organizations where there is a clear strive to meet business commitments and deadlines, how do you help get senior leadership more open-minded to allow a learning environment, particularly if there are offshore teams involved, which has a cost associated with it?

The first question we ask senior leaders is this: “Are you happy with how IT is working?” Not surprisingly, their answer is always no. There is nearly always a disconnect between IT and the rest of the company. Deadlines are handed out like free candy but rarely met. This creates a level of distrust.

Agile provides senior leaders with a solution to this problem but they need to be as involved with the change as IT. Senior leaders can help by allowing time (3-6 sprints) for teams to make mistakes and test out new ideas. The organization can eventually get to a point where they are rebuilding trust by demonstrating a higher level of predictability.