This article presents the author's view of what you need to reflect on and consider changing when using Scrum based on the November 2020 update to the Scrum Guide. It lists the changes and clarifications that affect each team or role defined in the Scrum Guide.
A good leader keeps everything in order. In this fast-paced era where agile methodologies have become a more often used framework, a good Scrum Master is what is needed. But what makes a good Scrum Master?
Sometimes a challenge can be turned into an opportunity. When our team learned that the business needed to pull their popular Product Owner to focus on another team, a sense of panic set in. There would be a job search that could and did take months. Who would help the team on their path to creating value in the interim? How would we operate? Over time, what seems to be a negative turn of events was turned upside down.
The rapid rate of technological change is forcing enterprises to reinvent themselves and provide more flexible approaches, so agile transformations are key. However, knowing that agile is important is one thing, but the ability to properly implement the main principles, tools, and techniques of agile is another. Let’s explore time-tested agile principles that will help your organization build innovative products that customers love.
So you think you know Scrum? Using the whimsical notion of farm animals and light-hearted visuals, take a refreshing review of the entire Scrum lifecycle as an intuitive set of roles, responsibilities, and handoffs. Particular attention is placed on what the ScrumMaster and product owner are expected to do at each handoff.
Transforming a software development team to agile may not go as planned. The real change requires a phased approach to earn agile acceptance. That mindset must extend beyond the team to the entire organization.
As if working at Lego isn’t fun enough, Sherri Sobanski delights in finding new ways to test. Faced with a situation requiring a complete product redesign, she shares the route her team took to overhaul testing.
Most software development teams these days adopt an agile approach to guide projects through their lifecycle. But, according to Gil Broza, embracing popular practices is not enough. To work effectively in an agile environment, developers must change their mindset.
Ryan Ripley, professional Scrum trainer at Scrum.org, chats with TechWell community manager Owen Gotimer about what Scrum is, some of the most common Scrum antipatterns, and the importance of connecting your Scrum team with your customer. Continue the conversation with Ryan and Owen (@owen) on the TechWell Hub (http://hub.techwell.com/)!
In this interview, Hans Buwalda, the CTO at LogiGear, details the common misconceptions people have when it comes to DevOps. He also discusses continuous integration and continuous deployment, having the right amount of confidence when it comes to testing, and how to know if DevOps is right for you.
In this interview, Michael Nauman, a testing lead for AutoCAD Web, explains how we can go beyond basic agile principles. He digs into the current state of shift-left testing, the importance of aligning your DevOps with your automation, and using agile as a starting point on your quality journey.
In this interview, Sanjiv Augustine, the president of LitheSpeed, sheds light on a handful of scaling frameworks, including the Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), and the simple scrum of scrums meeting.
Most teams that do agile development start with Scrum. And why not? Scrum is a proven method for focusing your team, ensuring that work adds value, and minimizing the risk with release. Then, after awhile, Scrum becomes stagnant.
The product owner role was introduced in Scrum in 1993, so the role has been around for more than twenty-five years. Yet we still struggle with the nature of it. Is it simple or complex? Is it inward- or outward-facing? It is about backlogs and stories, or something more?
While the Scrum product owner is arguably the most crucial role within agile teams, we often hear horror stories about POs who aren’t available to their teams, change their minds incessantly on business priorities, or ignore quality requirements and technical debt.