The concept of team is at the heart of Agile software development and frameworks like Scrum. Forming high performance Agile teams is however not obvious. In this article, Debbie Madden suggests five steps that could bring your software development teams beyond the basic principles of Agile.
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 this article, John Yorke shares his opinion on why Agile projects might fail because of the confusion between the roles (ScrumMaster, 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?