Product Owner

Remember the old days when software engineering teams used to tune software until it passed quality gates, gave golden bits to marketing, and finally threw a big release party? The world was simple, and writing code that worked according to a specification was enough to be a star developer. Viktor Veis says that world has changed. Software now often dials back home to record information about its usage and health. This telemetry flows back to engineering teams who are accountable for making sense out of this data. This is a fundamental shift in the software engineer role. Teams who can leverage data-driven engineering will delight customers by learning more about customers than they know about themselves. Teams who ignore data-driven engineering will continue based on assumptions and eventually lose competitive nerve. Join Viktor to learn how to start data-driven engineering today. Discover a practical approach that sometimes deviates from classical data science but is easy to learn and apply.

The Scrum Guide describes Product Backlog Refinement as “the act of adding detail, estimates, and order to items in the Product Backlog.” New and even experienced agile teams often underestimate the importance of well-groomed stories and find the process of reviewing numerous stories, breaking them down, and estimating the work chaotic and cumbersome. As this happens, teams push problems downstream into sprint planning meetings—or worse, into the sprint. Becky Moshenek shares how, working with the Product Owner, they create stories for backlog items to be reviewed. The stories include a link to the actual item, tasks outlining how and what to review, and a deadline for a future refinement meeting. These become refinement stories that are assigned to team members and brought into a sprint for an allotted ten percent of their time. Coordinating the team’s effort around backlog refinement in this way has cut meeting times, increased team involvement, produced more polished items, and made for a happier team.

Businesses are hit by thieves from all angles. Thieves often go unnoticed until something is missing. If you are adopting agile, you may have thieves stealing from your transformation right now. Every organization is different, but some thieves of agile adoption are well-known. Francie Van Wirkus shares her “most wanted” list of thieves, common organizational impediments and patterns, and her ideas on how to mitigate them. At the foundation of all solutions is strong leadership muscle, so expect stories and action items on how to raise your leadership game. Francie introduces high-level concepts including the mistakes of managing change instead of leading change, pushing culture ahead of environment, and skipping agile coaching. Awareness of what’s stealing from your agile adoption is only part of the conversation. Francie provides real-life actions to keep your strategy and goals on track. Don’t wait for something to go missing from your organization before you take action.

Has the adoption of agile techniques magically erased risk from software projects? When we change the project and product environment by adopting agile, have we tricked ourselves into thinking that risk has been abolished—when it hasn’t? Agile risk management is a continuous process that makes risk management part of how the team works so they get value from the activity. Thomas Cagley suggests that we develop user stories that specifically address risk so it is prioritized, planned, and executed as part of the normal agile cadence. Agile techniques—daily standups, demonstrations, retrospectives, and sprint-planning activities—provide a platform for monitoring and controlling risks. The built-in feedback loops act as a safety net to ensure eyes are continuously looking at what is happening and what could be happening. By constantly evaluating risk, agile processes avoid spending significant time analyzing risks that are not on the horizon, while making it very difficult for an unseen risk to sneak up on your project.

Actionable customer feedback, although difficult to capture well, is critical to adapting to customer needs. How can you ensure you identify the right customers, get customers to feedback sessions, and capture the most useful feedback? Mario Moreira shares ways you can establish a customer vision focused on gaining that elusive customer feedback. He helps you identify customer types via personas for your product, service, or value stream. Mario discusses how you can incorporate customer personas into the way you capture requirements. He helps you identify various types of customer feedback loops you can used and determine strategies to get customers to your feedback sessions. Leave armed with a framework for establishing a customer feedback vision with ways to get more effective customer feedback leading to products and solutions that more closely align with customer needs. Instead of barely hitting the broad side of the “customer” barn, wouldn't you rather hit the “customer” bull’s-eye?

After implementing Scrum, some organizations slowly stray away from the basics that made their implementation successful. They loosen up Scrum practices, lose sight of core roles and responsibilities, and succumb to their muscle memory of how things were done before. Teams have little accountability and fail the transparency test. Denise Dantzler reminds us of the roles and responsibilities of the ScrumMaster, Product Owner, team member, leadership team, organization, Scrum coach, and stakeholders. She then identifies and discusses pitfalls, and recommended actions in each role to rejuvenate a Scrum implementation. Denise explores overall process improvement opportunities for Scrum implementations, including mid-sprint poker, release planning, and the importance of a Sprint Zero. Learn the critical adjustments you and your organization can make to remain successful over the long haul with Scrum.