Stephanie Ockerman

I was honored to participate in the Women in Agile panel discussion last week. If you missed it, you can watch the recording. I learned three things from this experience: 1) an hour goes by very fast, 2) I have a lot more to say on the topic, and 3) I want more opportunities to help women. We ran out of time on the last question about what advice we have for our women colleagues. And I wanted to share my thoughts in the hopes that some women out there will find it helpful. My advice is the same for men too, so feel free to keep reading. Get really clear on your values and what fulfills you. Many of us share similar values, but what values are strongest for you? We all are driven by a purpose. What is your purpose? What lights you up? Visualize that purpose. Bring it to life. That is what will motivate you to do the hard work to achieve it. Set meaningful goals that align with your values and what fulfills you. If our goals are in alignment with our values and what fulfills us, we are much more likely to achieve them. Be cautious of "should" goals. Be cautious of goals that other people set for you. Break down those goals. What can you do today to get you closer to that goal? What can you learn today that will be helpful? What can you do this week? What can you do this quarter? Get creative. Run some experiments. How are you going to measure progress? How will you know you're on the right path? How will you ensure there is an opportunity to adapt your plan (or even your goal) as you learn more? Say no to the things that do not align with what's important. I used to say yes to everything. And because I was successful and seen as a go-to person, I was asked to do even more. It was only once I got really clear on what was important to me that I was able to say no to the opportunities that did not align. Even the good opportunities. Saying no creates the space for the important work. Saying no creates the space for reflection, thought, and creativity. Saying creates the space for growth. Work with a coach. It can be really hard to execute and stay focused on the above items. It can be difficult to get past our own limiting beliefs. It can be challenging to see different perspectives. A coach can help you get clear on what's important to you. A coach can empower, support, champion, and challenge you. A coach can help you tap into your creativity, deepen your learning, and take concrete action. I offer complimentary coaching sessions, and you can sign up for one here. Pradeepa, another panelist from the Women in Agile webinar, offers complimentary coaching sessions as well, and you can find her here. Take care of yourself - mind, body, and soul. Not taking care of yourself is like creating technical debt. As the debt builds, it will be more difficult to learn and grow and to accomplish things effectively and efficiently. It will zap your energy, focus, and creativity. When you take care of yourself, you will do your highest work and can be a better leader. This advice is based on what I call an Integrated Life. This is a life of more joy, fulfillment, and balance. Essentially, this is aboutthinking like a Product Owner and treating your life as the product. Make it clear what you want. Ask for help and support. When I joined a consulting company, I made it clear that my goal was to become a Professional Scrum Trainer (PST). I asked my company and other PSTs for help and support. And I got it. I realize that you will not always find help and support, but it doesn't hurt to ask. If someone says no, ask someone else. Keep going. Join local meetup groups. Go to conferences and make connections. Take a class. Follow up with the people you meet. If there is someone doing what you want to do, invite them to coffee or ask them for an informational interview. Volunteer your time and/ or skills. Please reach out if you have any questions. I'm happy to share my experiences and provide support.

A recurring Scrum myth I see in my training and coaching is that there is no planning in Scrum.  Unfortunately, this myth can lead to two negative consequences. The people in organizations responsible for budgets, product management, sales, and marketing may be unwilling to try Scrum. Scrum Teams may not be effective in their use of Scrum. The reality is we plan A LOT in Scrum. We just plan differently to optimize effectiveness. In Scrum, we emphasize the activity of planning over the plan itself. We know the plan is going to change. And this mindset honors the agile value of adapting to change over following a plan. In Scrum, the activity of planning is collaborative. The Sprint starts with Sprint Planning, and the entire Scrum Team participates. This is a collaborative negotiation to determine a valuable outcome the team wants to achieve. The Development Team creates the Sprint Backlog, identifying what will be delivered and a loose plan for meeting that valuable outcome. The Daily Scrum is a collaborative planning session for the Development Team to inspect progress and adapt the plan to meet the Sprint Goal. The Sprint Review is a collaborative session to gather input needed to help plan the next Sprint. The Sprint Retrospective is a collaborative session to enable and plan for continuous improvement. In Scrum, the people doing the work own the plan. The Development Team owns the Sprint Backlog. They create it, and they can adapt it. This ownership means the plan will reflect the current reality, incorporating input from the most knowledgeable people. For release-level planning or forecasting, the entire Scrum Team owns this. It requires a collaboration because of the distinct accountabilities of the Scrum Roles. Planning in Scrum is part of every Event. In every Event, we are both inspecting and adapting.  That is the essence of planning.  If we don’t see the adaptation happen during a Scrum Event, it is time to revisit the Scrum Team’s understanding of the purpose of the Events. Furthermore, the Scrum Framework is just a framework. It encourages Scrum Teams to apply complementary practices where relevant to further assist with planning, including release planning and product backlog refinement techniques.  Development Team members choose how to do their work, and they may have planning discussions throughout the Sprint. In Scrum, the way planning is done reduces waste. A plan is out of date a minute after you discuss it. Therefore, we keep the plan lightweight and make it easy to update the plan. Some ways that we reduce waste related to planning include: We minimize time spent analyzing things that may never happen. The further something is in the future or down the ordered list of priorities, the less time we spend trying to gather details. We minimize time spent analyzing to an impossible level of accuracy. There is a point where our gains in accuracy no longer outweigh the time spent to get there. We accept that the complexity and unpredictable nature of software development make it impossible to have a perfect plan. We incorporate meaningful feedback every time we plan. By doing the work, by building software, we learn the most valuable information for helping us adapt our plans. In Scrum, we still recognize the inherent unpredictability in complex software development. By being honest about this, we can be transparent about the current progress and likely completion dates. This helps us build trust.  This enables us use an empirical process to enable business agility, to make difficult decisions, and to do professional work. In summary, planning effectively is an essential part of Scrum.  I have experience working as both a Project Management Professional (PMP) in the traditional delivery environment as well as working as a Professional Scrum Master (PSM) and Coach in an agile delivery environment. I argue that when we do Scrum well, planning in Scrum is more effective.

This post is part of a series on debunking Scrum Myths.  While my business cards say Professional Scrum Trainer, I may change that to Scrum Myth Buster.  This post debunks the myth that the Daily Scrum is a status meeting.  This myth undermines the effectiveness of Scrum in major ways.  I will share four key differences between the Daily Scrum and a status meeting. What is the Daily Scrum? According to the Scrum Guide, the purpose of the Daily Scrum is to inspect progress towards the Sprint Goal, synchronize activities, and create a plan for the next 24 hours. The Development Team runs the Daily Scrum. The event is time-boxed to 15 minutes, and it happens every day. Essentially, the Daily Scrum is a collaborative planning session conducted by the Development Team. What is a status meeting? There is not one definitive source for the purpose of a status meeting.  However, we can look at how this term is generally used in the workplace.  In a status meeting, individuals provide an update on the progress of their assigned tasks to another person. This other person is usually someone in the role of team lead, project manager, or manager. The focus is on the progress of a set of tasks or milestones, not on valuable business outcomes. Status meetings tend to focus on individual contributions. On the surface, the two may not seem that different.  However, in practice, there are important differences that drastically impact the effectiveness of Scrum. 4 Key Differences between Daily Scrum and Status Meeting #1 – Daily Scrum promotes self-organization. The accountabilities in Scrum are important for effective self-organization.  The Development Team has a shared accountability to create the Done Increment.  This means they determine how they do it.  They own the Sprint Backlog.  By inspecting their progress and adapting the Sprint Backlog together, the Daily Scrum helps the Development Team self-organize. When a Daily Scrum is treated as a status meeting, the Development Team provides a status update to someone else.  They may not feel empowered to make decisions.  This may be exacerbated if the person questions the Development Team’s decisions or tells them what to do. #2 – Daily Scrum amplifies transparency and enables frequent inspection and adaptation. Scrum uses empiricism to deal with the complexity and unpredictability of software development.  One of the three pillars of empiricism is transparency.  The Daily Scrum enables transparency by ensuring that the Development Team members who are responsible for creating the working software all know what is going on.  The good, the bad, and the ugly. Transparency enables teams to adapt based on the current situation and new learnings.  The people building the Increment have a short Daily Scrum every day.  This cadence and time-box optimizes the inspect and adapt feedback loop without creating waste. If Development Team members are reporting a status to someone, they may not be as open about their progress and issues they face.  Furthermore, a status meeting does not emphasize adaptation of the plan. #3 – Daily Scrum enables focus on achieving an outcome. The entire point of Scrum is Done.  And the Sprint Goal guides the Development Team.  By focusing on achieving a goal and having working software, the purpose of the Sprint is emphasized.  The Development Team can assess progress in the context of the entire Sprint.  If new work has been identified that endangers the Sprint Goal, they can discuss and adapt the plan.  If issues are slowing progress, they have the right discussion and adapt the plan. In a status meeting, individuals give updates on the tasks or items they have each worked on, and there is likely not focus on achieving a valuable business outcome.  A task or a feature that is 80% complete is not very meaningful in software development.  We don’t know what progress has been made.  We don’t know if we will likely have something that delivers business value by the end of the Sprint. #4 – Daily Scrum promotes collaboration. The Daily Scrum is a great opportunity to promote collaboration.  All Development Team members have awareness to progress, what people are working on, and what impediments are slowing progress.  Since everyone is on the same page and focused on their shared accountability, there is ample opportunity for collaboration. The Daily Scrum is a collaborative planning session.  No one person on the Development Team owns the plan. They create it and adapt it together.  Furthermore, the Daily Scrum presents opportunities to help each other with impediments, share knowledge, or work together to get an item done faster. In my experience with status meetings, there is not a lot of collaboration.  They tend to focus on individual contributions and coordinating work. In summary, an effective Daily Scrum is essential to achieving the benefits of Scrum.  The Daily Scrum is a quick collaborative planning session.  It is by the Development Team, for the Development Team. What techniques have you used to get out of “status mode” and amplify the effectiveness of the Daily Scrum?

In a previous post describing challenges to creating a Done Increment, I identified impediments as one of those challenges.  More specifically, NOT removing the impediments makes it difficult to create a Done Increment.  Scrum Teams will always face impediments because the work is complex and dynamic.  The question is whether we tackle those impediments or live with them. An impediment is anything that is slowing down or blocking a team from delivering working software.  Impediments could be related to technology, process, or people.  It is easy to get overwhelmed by the expectations of delivering more product features faster and feel like there is no time for implementing improvements.  However, removing impediments helps improve workflow and can result in higher quality and easier delivery of enhancements in the long-term. 5 Challenges Tackling Impediments 1 - The team is not empowered. I talked about team empowerment related to the challenge of team ownership.  Empowerment comes into play again here.  When a team cannot make decisions about how they do their work, their ability to improve is limited.  Their ability to adapt to change is limited.  Their ability to take advantage of opportunities is limited. Make the Development Team's accountability explicit. They turn the Product Backlog into working software.  And as professionals, they are expected to do this to the best of their ability.  This means they must manage and improve upon their processes, tools, and interactions to be more effective in delivery. Coach management on how to create an environment of empowerment. Question how we do things.  This could be processes or practices that the team owns or something that exists in the organization.  Asking bold and outrageous questions can help your team start to take their power. Ask for forgiveness, not permission.  A Scrum Master can be the one to show courage first in "taking power" if the team does not yet feel their own empowerment.  A Scrum Master should be prepared to protect the team when they do exercise empowerment. 2 - We confuse constraints and assumptions. I have seen people assume they have to follow certain processes or use specific tools because it is a constraint in the organization.  When I teach Scrum Training Courses, I explain that constraints help maximize self-organization.  However, the majority of "constraints" I have come across are usually not constraints but rather recommendations or best practices. Some constraints have exception processes if you have good reasons for doing something differently or not at all.  I recently heard an example of a team who worked with regulators to influence policies that they saw as impediments to software delivery.  How awesome is that! Question everything. Help your teams come up with bold and wild ideas.  What if we could do anything we want to solve this problem?  What would that look like?  You might actually be able to try out those crazy ideas. 3 - Impacts of impediments are not understood. Does your team have recurring impediments?  Do the impacts of those impediments seem small or large? Is your team putting off process or tooling improvements because they are a large effort?  Or maybe there is a price tag that we are worried won't get approved? Is your team putting off knowledge sharing or training because there isn't enough time?  Or maybe they don't want to be perceived as less productive. I have two suggestions to help clarify the impacts of impediments: Look beyond the "blocking" impediments.   Many impediments are not stopping us from working but rather slowing us down and preventing us from delivering the most value.  I call these "anchors."  We may be able to push on, moving forward while continuing to drag them behind us.  Eventually we get tired, and they slow us down further. Quantify impacts in terms of cost and business impact.  Make it visible.  Put it on a chart.  Show the trend. How much time are we spending dealing with an impediment? How frequently is this impediment occurring? A technique I have used in the past is the Waste Snake. What is the quality impact? For example, are the number of defects discovered in production increasing or decreasing? What is the cost of fixing a defect in production versus fixing a defect found during development? What is the impact to the team's flexibility? How is the impediment affecting morale? Are people leaving because they are unhappy with the impediments? What is the cost of hiring someone new? (I'm taking this to the extreme, but it is a valid situation. People leave dysfunctional organizations. Tolerating impediments is a dysfunction.) Waiting until an impediment becomes urgent (i.e. all forward progress is  blocked) will typically be a huge impact.  Try not to do this. 4 - Planning too much in the Sprint. If we schedule every working hour of every Development Team member during a Sprint, we are almost guaranteed to fall short.  Furthermore, the team will likely feel there is no time to resolve impediments.  We must recognize that improvement is part of the work.  Here are a few ideas to acknowledge this and encourage this. Stop creating arbitrary deadlines and fixing scope.  The pressure to deliver specific functionality by a certain date can cause teams to fill a Sprint with Product Backlog Items and push off the improvements they needed to improve their effectiveness.  Scrum Masters and Product Owners can help protect the Development Team from this pressure and work with those outside the team who may be creating this pressure. Make impediments visible and an input to Sprint Planning.  Sometimes the Development Team and Product Owner need to actually see impediments to keep them in mind during Sprint Planning.  If the impacts of the impediments are understood, the next step is to make them visible and consider them inputs to Sprint Planning. Get your Product Owner on board.  The Product Owner's accountability is to maximize the value of the product.  If the product is not scalable, enhance-able, or maintainable, the Product Owner is not going to get much more value out of the product (or it will come at great expense).  I have worked with Product Owners who are fierce advocates for removing impediments to the Development Team's continuous improvement. Don't be afraid to talk about some impediments in the Sprint Review.  Some things are best to handle with the Scrum Team only in the Sprint Retrospective.  However, organizational impediments or impediments that require investing in the Scrum Team may make sense to bring up in the Sprint Review.  You have a wide range of stakeholders in attendance, and they may have influence to assist with these impediments. 5 - Management is not engaged in removing organizational impediments. A Scrum Master's responsibility is to help the Development Team remove impediments they cannot resolve themselves.  However, a Scrum Master should not feel they have to do this on their own.  Sometimes the Scrum Master just needs the Manager to provide cover or support for their efforts.   It is also important to recognize that a Manager can often provide knowledge, insights, and influence the Scrum Master does not have. The Scrum Master and Agile Manager should be working closely together on the impediments that will require organizational involvement and support. In summary, a Scrum Team tackles impediments in order to improve effectiveness in delivering valuable software.  Teams must be empowered to resolve impediments.  The impacts of impediments should be made transparent.   Teams must take the time to resolve impediments.  A self-organizing Development Team will know which impediments they need to address, when to address them, and when they need support from outside the team. If you think one of these problems is affecting your team, pick a technique and try it.  Let us know how it goes. Check out the whole series on Getting to Done:   Encouraging Team Ownership Improving Team Collaboration Creating Good Sprint Goals Balancing Emergence and Delivery

In a previous post describing challenges to creating a done Increment, I identified too much change during the Sprint as one of those challenges.  The Manifesto for Agile Software Development talks about responding to change over following a plan.  It also says that the best architectures, requirements, and designs emerge from self-organizing teams. So how do we respond to change and allow emergence while still delivering something of value that works? First lets define delivery and emergence.  In Scrum, delivery is releasable software by the end of a Sprint.  Because we are dealing with complex work, we do not know everything about what is needed and how to deliver it before we start working.  This is where the concept of emergence comes in. Emergence implies that all solutions to all problems will become clear as we work, not simply by talking about them.  Essentially, we need the ability to learn for experience and respond to what we are learning.  This could mean fine-tuning our direction, changing course altogether, or continuing forward as our assumptions are validated. Balancing emergence and delivery are challenging.  There is no formula.  Teams have to figure out what will work in their situation. So let me provide some guidance on where to start looking if it feels like there is too much change happening, and this is affecting the ability to deliver of a Done Increment. 3 Challenges Balancing Emergence and Delivery  1 - New work is being assigned to the Development Team. The Development Team should be focused on the Sprint Goal and using the Sprint Backlog to visualize progress towards achieving it.  Nobody should be adding work to the Sprint Backlog except the Development Team.  Remember that the Sprint Goal helps the team stay focused and provides flexibility as work emerges.  If someone is giving the Development Team other work to do, then we have broken focus, and we have undermined team ownership. Here are a few ideas for handling emerging priorities not in line with the Sprint Goal. A Scrum Master can help protect the Scrum Team from outside distractions by teaching them the rules of Scrum, by helping them understand their accountability, by helping them understand what decisions they own.  This includes teaching the Product Owner to prioritize new requests in the Product Backlog rather than try to push them into the current Sprint.  This includes educating stakeholders about Scrum.  This could also mean leveraging management. It can be hard to say no to the "shoulder taps," but team members can help by holding each other accountable.  If someone brings up something they are working on that isn't on the Sprint Backlog (or they try to add it to the Sprint Backlog), it is the team's responsibility to question it.  This is a hugely supportive thing to do for team members.  Everyone struggles to say "no."  Having support from your team when you need to say "not now" is helpful. If new work emerges during the Sprint, the Development Team and the Product Owner should negotiate.  If something is going to come in, it is very likely that something else must come out.  Remember that our Sprint Goal should not be changed during the Sprint. 2 - Poor Product Backlog refinement causes the "what" to grow during the Sprint. Product Backlogs are not meant to be detailed requirements contracts.  We expect details to emerge during the Sprint, and there may be a few surprises periodically.  However, we may see an overwhelming amount of details emerge during a Sprint.  The Sprint Goal becomes unachievable, or the Scrum Team spends so much time analyzing and negotiating that little time is available for actually delivering the Increment.  This could be a sign that we are not doing effective Product Backlog refinement. Consider having the full Scrum Team participate in Product Backlog refinement.  When all Development Team members participate, you get two major benefits.  1) Everyone is part of the discussion of what we are building and why, which reduces misunderstandings later.  2)  Everyone can contribute to the slicing and ordering of the Product Backlog Items so that they are right-sized and dependencies are reduced. The goal of refinement is to get Product Backlog Items to an actionable level of detail.  You may choose to make this more formal with a Definition of Ready.  I like Roman Pichler's description of "ready" as clear, feasible, and testable.  Some teams will create a visual board that shows the refinement of Product Backlog Items to the state of "Ready." A Scrum Master coaches the Product Owner on how to best fulfill their role and responsibilities to the team.  The Product Owner is accountable for maximizing the value of the product and the work of the Development Team.  Refinement is important so that value is understood and achievable.  A Product Owner does not have to do all of the refinement activity alone (nor should she).  However, if we are seeing symptoms of this problem, a Product Owner may need to get more engaged in refinement activities.  Here are some great questions to help coach a Product Owner. 3 - Not discussing the "how" during Sprint Planning. The Sprint Backlog consists of the selected Product Backlog Items and a plan to deliver them.  It is true that this is a loose plan, and the details are expected to emerge during the Sprint.  But that is not an excuse to do a poor job with planning.  Discussing the "how" helps a Development Team better understand how much work they can forecast for the Sprint.  Discussing the "how" helps identify dependencies, gaps in skill or knowledge, and other impediments.  All of these can kill a Sprint if not dealt with early. A Scrum Master should reinforce the purpose of Sprint Planning.  It is easy for a team to lose sight of the purpose of an event, and sometimes we just need a reminder.  I ask a team member to kick off the Event by stating the purpose and output of the Event.  Periodically, I ask if the team feels we are making progress towards that purpose.  And at the end of the Event, I ask if everyone feels that we have achieved the purpose.  For Sprint Planning, I ask what impediments they foresee and need help resolving. A Scrum Master can help the team more effectively use the time-box.  If the team usually reaches the end of the time-box before talking about the "how," break this into two time-boxes to help the team focus on both aspects of the Sprint Backlog.  A back and forth between "what" and "how" is normal, but help the team balance this.  If the team ends Sprint Planning well before the time-box without a solid discussion of the "how," use open questions to draw out this part of the discussion.  "This is a large item.  How can we break this down into smaller pieces the team can tackle together?"  "Do we have everything we need as a team to meet our Definition of Done and achieve the Sprint Goal?"  "What dependencies will drive how we deliver on the Sprint Goal?" Break the Product Backlog Items into tasks or to-dos.  Sometimes teams talk about the "how," but they don't actually capture what they talk about during Sprint Planning.  If you are facilitating the event, you may start capturing some of the conversation visually on a white board.  You may ask if someone can draw what they are explaining.  Offer the team the option to take what they have visually captured and break down the Product Backlog Items into tasks on the Scrum Board. In summary, a Scrum Team must learn to balance emergence and delivery.  While there is no cookie-cutter recipe, we can help our teams use the Product Backlog to prioritize new work, have more effective Sprint Planning, and improve Product Backlog refinement. If you think one of these problems is affecting your team, pick a technique and try it.  Let us know how it goes. Check out the whole series on Getting to Done:   Encouraging Team Ownership Improving Team Collaboration Creating Good Sprint Goals Tackle Impediments

In a previous post describing challenges to creating a done Increment, I identified a lack of clear Sprint Goals as one of those challenges. According to the Scrum Guide, the Sprint Goal is an objective to be met by the Sprint through the implementation of part of the Product Backlog. The Sprint Goal provides guidance to why we are building the Increment. If we have a Sprint Backlog, essentially the plan for the Sprint, why do we need a Sprint Goal? Remember that software development is complex, and we cannot plan perfectly for the unknown.  When we create the Sprint Backlog, there is an expectation that work will emerge during the Sprint.  Scope may need to be re-negotiated.  The Sprint Goal helps provide focus on an objective we want to achieve and allows the flexibility to negotiate the work to achieve that objective. Creating a clear Sprint Goal can be challenging for Scrum Teams, and this often comes up when I teach Professional Scrum courses. 4 Challenges With Sprint Goals (and some tips for resolving them) 1 - The Sprint Goal is too big. When we have compound Sprint Goals (e.g. achieve X and Y and Z), we are splitting focus and not allowing much flexibility.  Here are a few reasons we end up in this situation and suggestions for how to think differently. We are working on multiple unrelated projects or initiatives.  When we are ordering the Product Backlog and doing Sprint Planning, consider both cohesion of the work and the top priority initiative.  When we cram too much into a Sprint, we are setting ourselves up for failure.  We end up with waste due to context switching and little room for the work to emerge as we learn.  If it feels impossible to choose one, perhaps our Sprints are too long and do not provide the business the opportunity to change focus and direction frequently enough. We try to encompass every Product Backlog Item (PBI).  When I teach Scrum courses, I often hear that teams consider their Sprint Goal to be "complete every PBI."  This is the equivalent of not having a Sprint Goal at all.  This feels a bit lazy.  Yes, coming up with good Sprint Goals is hard.  Take the time to do it. We think the team may not work as hard if the challenge isn't big enough.  This sentiment reminds me a command-and-control mindset.  If self-organizing, empowered teams are to be effective, we must believe that people are committed to doing their best.  If the Sprint Goal is met before the end of the Sprint, professionals will figure out what else they can do to contribute in meaningful ways.  This could mean delivering more functionality.  This could mean working on continuous improvement items.  Trust them to figure it out. 2 - The Sprint Goal is vague. When we get to the end of a Sprint, is the entire team in agreement on whether or not the Sprint Goal has been achieved?  If not, the Sprint Goal may be too vague.  Here are a few tips for creating more clear Sprint Goals. During Sprint Planning, ask "how will we know if we have achieved the Sprint Goal?"  If we have different answers or puzzled looks from the Product Owner or any Development Team members, then we need further discussion and refinement of the Sprint Goal. Make the Sprint Goal measurable.  This helps reduce subjectivity, or opinion. During Sprint Planning, use a consensus technique to confirm everyone's understanding and commitment to the Sprint Goal.  This is also a way to help encourage team ownership. Here are some examples of unclear Sprint Goals and modifications to make them clearer. Unclear Sprint Goal Clearer Sprint Goal Enhance shopping cart functionality. Streamline purchasing process to enable an increase in conversion rates. Improve performance. Increase page load time by X%. On-board new market segment. Enable new market segment to purchase Service Y. 3 - The team doesn't pay attention to the Sprint Goal during the Sprint. Remember we have to actually pay attention to it to help provide focus. Make it visible.  Write the Sprint Goal on or near the Scrum Board.  Make it large.  Use a color or border that stands out. Teach the team to talk about progress towards the Sprint Goal in the Daily Scrum.  Development Team members often give updates about the Product Backlog Items they are working on, and the Sprint Goal is never discussed.  Make it part of the Daily Scrum. Make the Sprint Goal a team measure and keep it visible in the team space.  Similar to how a team may track their velocity or automated test coverage over time, a team can also track Sprint Goal achievement over time.  Keeping this information visible helps the team think about it.  Historical data and trends can be used for discussion in the Sprint Retrospective.  A word of caution:  achieving a Sprint Goal is pass/ fail.  There is no such thing as 85% achieved. 4 - The Sprint Goal doesn't feel meaningful. A Sprint Goal is supposed to provide purpose.  It helps the team know why they are building the Increment.  People want to do meaningful work.  People want to do work that has an impact.  This is a driver for intrinsic motivation.  Lets think about ways to make Sprint Goals more meaningful to the people who are building the product. Make it business or user focused when possible.  What will a user be able to do when we implement this feature?  What will a business area be able to achieve when we implement an enhancement? Make it focused on testing business assumptions and getting feedback.  Many times we do not know what users actually need or are willing to do (because even users don't know).  A Product Owner needs early feedback to test assumptions regarding value to users. Make it focused on reducing risk.  Proving out a technology or design is an important part of reducing risk.  If we learn that a technology is not going to meet our needs for performance, security, or scalability, we can change direction.  The earlier we change direction, the cheaper the cost of the change. In summary, a good Sprint Goal can help a team focus and have the flexibility to create a Done Increment by the end of a Sprint.  A good Sprint Goal helps a team understand the purpose and impact of the work they are doing, which is a driver for intrinsic motivation.  Roman Pichler provides a helpful template for creating effective Sprint Goals. If you think one of these problems is affecting your team, pick a technique and try it.  Let us know how it goes. Check out the whole series on Getting to Done:   Encouraging Team Ownership Improving Team Collaboration Balancing Emergence and Delivery Tackle Impediments

In a previous post describing challenges to creating a Done Increment, I identified a lack of team collaboration as one of those challenges. Collaboration is what enables the whole team to be greater than the sum of its parts.  Collaboration allows a team to work together to complete a product backlog item and then move on to deliver the next one.  Collaboration allows a team to come up with effective solutions to complex problems. If individuals are working separately, there is often a lot of partially done work at the end of a Sprint.  This means the increment is not releasable.  In order to enable effective solutions and deliver working software by the end of a Sprint, we must improve team collaboration. 4 Problems Preventing Effective Team Collaboration (and some tips for resolving them) 1 - We do not have trust within the team. I talked about ways to build trust related to the other challenge of lack of team ownership.  Team collaboration and team ownership are related and are often both present or both absent.  Here are some additional tips for building trust related to collaboration. Leverage the power of gamification.  Gamification uses game thinking and mechanics to engage people in solving problems together.  Use games to make learning visible and enable people to collaborate in a safe and fun way. Plan team building activities to get to know each other and have fun outside of work.  Happy hour is an easy one.  The impact can be maximized if the activity involves creating something together or playing a team-based game.  I have brewed beer, participated in a pot luck, taken an art class, gone bowling, and played sand volleyball with teams. 2 - Team members don't know how to collaborate. This is common if people have worked in siloed organizations where their job title dictated the activities performed  (e.g. Tester, Requirements Analyst, Solution Architect) .  This is also common if people are used to working on several projects concurrently because the nature and timing of the work does not allow opportunity for collaboration.  Here are some techniques to help break down the silos. Have the team take an activity-based training course together.  Professional Scrum Foundations and Professional Scrum Developer are both excellent training for entire Scrum Teams to attend together because teams collaborate to build working software during the course.  Team members will have a shared learning experience.  They will likely be more comfortable taking risks and doing new things because training is a safe environment for experimentation. Teach team members a growth mindset.  A growth mindset is based on the belief that your basic qualities are things you can cultivate through your efforts.  This is the mindset that allows people to thrive when faced with challenges.  One of the biggest challenges someone may face in their career is moving from a narrowly defined role involving a skill set honed over many years to a self-organizing, cross-functional Scrum Team. Introduce the pairing technique.  Pair programming is a well-known technique in which one programmer is a driver and the other an observer, switching roles frequently, as they work together at one workstation.  However, pairing does not need to be limited to programming.  Check out this 7-minute video where Pradeepa Narayanaswamy talks about pair testing as a collaboration and learning tactic. 3 - The environment and tools do not foster team collaboration.  Scrum does not require team members be co-located.  However, co-location is quite helpful for fostering collaboration.  If team members are located in the same building but still sitting in separate individual spaces, create a team space for them. A team space should be a comfortable area where it is easy for team members to work together.  Throwing a team in a cramped conference room without any windows does not create an environment for collaboration.  A team space should respect that individuals needs space for their belongings and to do their work.  The space should have lots of wall space - even if not permanent - for the team to keep visible information.  Also have plenty of white board space.  Magnetic white board walls are amazing! A Scrum Board helps a team plan their work together and stay focused on the Sprint goal.  If progress is visualized, it fosters collaborative planning.  It helps enable discussions about how to get something to done and what is the most important thing to focus on next. Sometimes team members need to have a private conversation or a place to quietly think.  Ideally, also have a private space that the team can use without having to "reserve" it. If the team cannot be co-located, take advantage of the many collaboration tools available.  Face-to-face communication is best.  Consider Google Hangout (or a similar tool) for team events, refinement sessions, and pairing.  You can even keep a Google Hangout open all day for remote team members to connect via video and work all day. If you have remote team members, try to bring the team together in one location periodically.  This is especially helpful when starting up a new team, implementing significant process improvements, or moving the product in a new direction. 4 - Team members are afraid of conflict. Team collaboration inherently comes with conflict.  We want productive, healthy conflict in our teams in order to get the most effective solutions and to keep improving as a team. Look for signs that team members are avoiding conflict.  There may be a lot of silence in team working sessions or in the team working space.  When someone proposes an idea, there is rarely an alternative offered by other team members.  Team members may go to the Scrum Master or someone outside of the Scrum Team to vent their complaints. Create team working agreements that include how to handle conflict. Create conflict.  Yep, that's right.  Propose wild and crazy ideas to get some discussion going.  When facilitating Scrum Events or working sessions, seek out the quieter voices.  One way to do this is to ask everyone to write something on an index card relevant to the discussion you're facilitating.  Collect the cards and randomly pass them back out to team members.  Have each person read what is on their card and interpret the meaning or respond.  This is a great technique for getting different ideas out in the open and enabling team discussion of the alternatives. Teach team members how to navigate conflict.  Focus on the ideas, not the person.  Gather data and focus on facts.  Maybe re-ground the team with the agile values and principles and the Scrum Values. In summary, collaboration is critical for self-organizing, cross-functional teams to solve complex problems and deliver working software every Sprint.  Traditional ways of working have not taught this important skill, so we have to take steps to teach people how to collaborate effectively and create an environment that fosters collaboration.  If you think one of these problems is affecting your team, pick a technique and try it.  Let us know how it goes. Check out the whole Getting to Done series:   Encouraging Team Ownership Creating Good Sprint Goals Balancing Emergence and Delivery Tackle Impediments

In a previous post describing challenges to creating a Done Increment, I identified a lack of team ownership as one of those challenges. The Development Team is accountable as a whole to create a Done Increment by the end of the Sprint. When team members do not feel team ownership, individuals focus on getting their product backlog item done. There is not a focus on the outcome of the Sprint. In order to use Scrum effectively and have transparency over our progress and quality, we must create an environment that encourages and enables team ownership. This is easier said than done. It often involves people changing both their mindsets and behaviors. There is not a recipe to follow that will guarantee team ownership. So how can we influence team ownership? 5 Problems Preventing a Sense of Team Ownership 1 - We do not have trust within the team. When we do not have trust, team members are not comfortable being vulnerable with each other about their weaknesses, mistakes, or fears. Team members are afraid to admit when they are stuck on a problem and to ask for help. The solution is to build trust. In the agile community, we talk a lot about building trust. But how do we do that? This is a big topic. Here are a few ways to get started on the path to building trust. Help team members get to know each other's histories, behaviors, and interests. Using a tool like MBTI or DiSC can help team members become more aware of how they perceive and behave in the world, and this opens the door to discussing strengths and weaknesses as a team. Create a team activity for people to share their personal histories. Facilitate a team discussion where each individual shares strengths they bring to the team, strengths they appreciate in others, and what area they want to personally grow. Set the example by relying on your team members. Demonstrate curiosity.  Ask open-ended questions of the team to encourage them to share their own ideas. Be vulnerable.  Ask for help.  Admit mistakes.  Ask for feedback.  You may say, "Can you take a look at this?  I might have missed something and would appreciate your perspective."  By demonstrating vulnerability, you are showing others that it is okay. Make explicit that there are a lot of unknowns with complex software development.  We need to have everyone's unique perspectives, knowledge, and skills in order to succeed. The more we learn about each other, the more comfortable we get being vulnerable.  We feel safe.  As we get more comfortable being vulnerable with our team members, trust will grow.  This often takes time, so we need to be patient and continue to demonstrate. 2 - Team members are not aware of the team's overall progress. We need to make information transparent so that the team can easily discuss progress, identify problems, and determine solutions together. Help the team use a visual Scrum Board to see their progress.  Reference the visual Scrum Board whenever discussing work with other team members. Track impediments brought up by the team over time.  The team can inspect the impediments in a Sprint Retrospective and look for recurring themes. Understanding WIP (work-in-progress) or how much time is spent waiting on others can help a team identify where they see waste and bottlenecks. Regularly bring up the shared accountability of creating a Done Increment. Change the language to "we."  We succeed as a team, and we fail as a team. If somebody brings a challenging issue to your attention, encourage taking it to the team for discussion. Ask questions such as, "How do we feel about our progress towards the Sprint Goal?" or "What do we think is the most important thing for us to focus on and achieve today?" 3 - Teams are not empowered. It is difficult to feel ownership if you do not have the power to make decisions about how to best achieve desired outcomes or goals.  Management needs to empower teams.  Yet simply declaring "teams are empowered" does not usually make them feel empowered.  This empowerment must be demonstrated by management.  This is another big topic.  I will focus on helping managers identify behaviors that help or undermine their desire to empower teams. If a manager provides solutions when individuals bring him or her problems that are best solved by the team, this will continue to reinforce the manager's role as "expert" or "decision maker."  Coach the manager on how to use open questions to help the person identify possible solutions or approaches. Demonstrate trust and confidence in the team.  This can be directly stated as, "This sounds like a difficult decision.  You are the ones closest to the work, and I trust your judgment." Be okay when outcomes are not as expected or desired.  This can often require standing up for and protecting a team when they fail.  Failure (done right) is another word for learning. Do not commit to dates or deliverables on behalf of the team.  This completely undermines team ownership.  Do not succumb to this pressure.  Let the team own their forecasts, and appreciate the unpredictability of their work. 4 - Individuals are rewarded instead of teams. Many organizations have performance review processes and ingrained management behaviors that reward and recognize individuals.  There is not always a comparable effort to reward and recognize team success.  Here are some ways to encourage the team to focus on team outcomes without changing the entire organization. Recognize individual behaviors that cultivate team ownership.  When you see a team member helping someone with an issue or peer reviewing his or her work, recognize that positive team behavior.  Maybe write your appreciation on a sticky note and silently hand it to the team member.  Consider creating a "kudos" tradition after the Daily Scrum or at the beginning of the Sprint Retrospective. Celebrate team successes.  When a team achieves the sprint goal and creates potentially releasable software, celebrate it.  When a team implements a major retrospective improvement action, make it a big deal.  Do the wave.  Go to happy hour.  Create a chart in your team space to visualize these successes.  Make it fun and meaningful. Coach managers to recognize team successes.  It can be as simple as stopping by the team space occasionally to pass along positive feedback or to ask what the team needs. If you are interested, read more about how annual performance reviews are dead. 5 - Team members are split across multiple teams. This situation often arises when we have created bottlenecks of knowledge or skills. Stop doing this.  Create action plans to share knowledge and skills with the teams that need it in order to create a Done Increment.  Yes, this will take time and effort.  This will also reduce the costs and effects of context switching over time. If we must do it, limit it.  Reduce the number of teams an individuals is assigned to (no more than two).  Plan work to prevent context switching.  Create blocks of time that allow focus.  Yes, this will limit each team's ability to plan their own work and may create some waiting times.  That is the reality of accepting this impediment. Make the waste transparent.  Track the number of times a team is blocked and for how long when they are waiting for the shared team member to be available.  Track the number of times a shared team member has to switch focus during a day.  This factual information can help make the case to management to invest in fixing this impediment. In summary, team ownership is an important factor for enabling the shared accountability necessary in order to create a Done Increment every Sprint.  We can help our teams get past this challenge by taking steps to address the common problems presented in this article. If you think one of these problems is affecting your team, pick a technique and try it.  Let us know how it goes. Coming up in the Getting to Done series:   Improving Team Collaboration Creating Good Sprint Goals Balancing Emergence and Delivery Tackle Impediments

The purpose of Scrum is to create a potentially shippable Increment by the end of a Sprint.  This is so important that people now use many terms to describe this Scrum artifact.  Working.  Releasable.  Done.  Done done.  However, many teams struggle to produce a done Increment.  Without working software, we don't have transparency over progress and quality.  We don't have the ability to validate assumptions and learning.  In my experience, there are five common challenges to creating a done increment. 1. Lack of Team Ownership The Development Team is accountable as a whole to create a done increment by the end of the Sprint.  When team members do not feel team ownership, individuals only feel responsible for getting their product backlog item done.  There is not a focus on the outcome of the Sprint. A common sign of a lack of team ownership is a lot of WIP (work in progress).  Product backlog items in the Sprint Backlog are often "carried over" to the next sprint.  Each individual is focused on getting their piece done and not looking at the whole plan, the whole team, the whole increment.  Quality issues are likely prevalent, but the team isn't discussing them. 2. Lack of Collaboration As a team moves through the stages of group development, they shift from coordination to collaboration.  When people are collaborating, we are enabling the most creative and most effective solutions to rise to the surface.  Without collaboration, solutions are constrained by the experience and knowledge of individuals. This is closely related to team ownership, so you will often see a lot of WIP caused by team members each working on a different product backlog item.  They may be talking to each other to coordinate the changes to the code or to ask questions and confirm the approach.  However, they are not collaborating to get a piece of functionality done and then together tackling the next piece of functionality.  Lack of collaboration can also create issues when teams try to integrate the individual work they have done.  Perhaps they discover the design is not very cohesive or that it is even conflicting.  Perhaps they discover a lot of refactoring, regression testing, or bug fixes remaining. 3. There is Not a Clear Sprint Goal A sprint goal is a measurable objective set for the sprint that provides the team focus and flexibility.  It is created through negotiation between the Product Owner and the Development Team.  Without a sprint goal, it is difficult to find focus as work emerges and the team experiences external pressures.  The Development Team may lose sight of what is most valuable and the purpose of building the Increment.  There may even be arguments about what to work on next. Here are a few questions to help determine if this is a challenge for your team: There is no sprint goal.  The expectation is to complete all of the product backlog items in the Sprint Backlog.  There is little focus and little flexibility here. The sprint goal is vague.  At the end of a sprint, do all team members know with 100% certainty whether or not the sprint goal was met? The sprint goal is too big.  Compound sprint goals (X and Y and Z) may not provide enough focus and flexibility. 4. Too Much Change During the Sprint  The Sprint Backlog is expected to emerge during the Sprint as the Development Team does the work to build the Increment.  We don't know everything about the features and functionality or the work to deliver them at the beginning of the Sprint.  So how do we balance allowing emergence with actually getting the Increment done? A sprint goal is one way to ensure focus and flexibility.  If you already have a clear sprint goal and are still struggling with too much change during the sprint, ask these questions: Is someone outside the Development Team assigning other work?  Are Development Team members doing other work? Is the Product Owner changing the sprint goal during the Sprint? Are we discovering diverging perspectives on what a product backlog item actually means during the Sprint? 5. Impediments Are Not Being Removed Teams may have technical or process impediments slowing them down or blocking them from creating a done Increment.  It is easy to get overwhelmed by the expectations of delivering more product features faster and feel like there is no time for implementing improvements.  However, removing impediments helps improve workflow and can result in higher quality and easier delivery of enhancements in the long-term. Here are a few questions to ask regarding common impediments: Does the environment go down frequently? Does the team have the knowledge and tools they need to implement automation? Is there someone outside the team who has to perform certain tasks or provide approvals in order to create a done Increment? If you are experiencing any, or perhaps all, of these challenges, stay tuned.  I will be writing more posts with tips for overcoming each of these challenges.