Articles and videos on creating and managing cross-functional Scrum teams: scrum master, product owner and development team.
Who says you need “stable” Scrum teams in order to build a successful software company? While the addition or removal of one person from a team means you have a “new team”, there is a myth out there about “stable” teams. When your Agile team compositions change it doesn’t mean you’re doing it wrong – it could be the secret to your success. Different companies have thrived through reteaming – the act of moving people around teams in different ways. This talk goes over the what, why and how of reteaming and shares stories from different companies who are living this reality.
Some software development teams are orders of magnitude more effective than others, turning around business solutions in days or even hours. Their secret is a combination of smart technology choices, great development habits and a powerful team dynamic. This talk describes a number of patterns of behavior that have been identified working with some great teams, beyond the basics of colocation, stand-ups and pair rotation. You’ll gain a new appreciation for old techniques like code reviews, and even working in silos won’t seem so bad!
If one of the first aim of Scrum was to break the silos between business analysis, development and testing, you can consider that improving the cooperation with the operation side of IT as the next frontier in this journey. What is the point to produce potentially shippable software increment in two weeks if your database administrator doesn’t want more than three new releases windows for the production database?
There might exist some lonely standalone software developers that create software without any other person involved, but my guess is that there are not many of them. Communication is an essential skill in software development, testing and project management… and life. As feedback is a key communication tool, I was therefore very interested when I stumble on this book about feedback written by an Agile coach.
If Scrum and Agile approaches are supposed to increase the chances of success for software development projects, not all the projects that want to use Scrum are successful. In some organizations, Scrum is a failure. This article discusses why Agile projects might fail because of the confusion between the Scrum roles (Scrum Master, Product Owner, Developer) of a Scrum Team and the required Agile mindsets.
How do we actually know if our Agile teams are doing well? Is gut instinct enough? Furthermore, in a rapidly growing organization such as Spotify, how can we ensure some sort of consistency in our baseline level of Agile knowledge across the technology, product, and design organization?
This is not a talk about Scrum teams. This is a talk about you and your role in developing a great team. No matter whether you are a Scrum Master, Project Manager or CTO, at least part of your job is to help your team or teams grow. In order to make this happen you need to work on two levels: The Zen Level and The Operational Level.
