Meetings like the daily stand-up or retrospectives are moments that rhythm the journey of Scrum and Agile teams. Sometimes these meetings are almost religiously considered as rituals or ceremonies that bound participants together and that nobody could miss. Is this true? In his book Forming Agile Teams Workbook, Jesus Mendez discusses if the participation to Scrum meetings is mandatory.
Agile and Scrum were supposed to free us from management: self-organized, cross-functional teams who get stuff done without that old-guard hierarchy. In this fauxtopia, some software developers were more equal than others. Can we get the healthy parts back without the Lumberghs? To bring back healthy engineering management, we must first de-mystify and de-stigmatize the concept of management.
Even if Agile approaches favor collocated teams, distributed Scrum teams are more common that what you might think. Many Agile software development teams are based on a virtual organization. This article presents some free online tools that can be used to facilitate retrospectives for distributed Scrum teams.
Imagine you are asked to sit in on a team’s sprint review and retrospective. The team has been having difficulty forming and the Scrum Master has asked you to observe the team dynamics during these two sessions. Are you simply going to watch what’s going on or is there more you can do? Perhaps you are seeing interactions and team dynamics at play without truly realizing what you are observing.
In a Scrum team, there are three roles: Product Owner, Development Team and Scrum Master. There is no explicit mention of software testers and some could question if testing specialists are really necessary in Scrum teams. After working on several projects, Eric Delahaye has found that they are and shares with us four reasons why they should be included as soon as the first Sprint Planning.
Agile approaches like Scrum recommend a “just enough” attitude in software development and this is also the case when you discuss tools. Ideally, you would work with a small team that is collocated, but this is not always possible and you might be running your project virtually with a distributed Scrum team scattered around the world.
If metrics like lines of code or code coverage are widely known by the software development community, measuring the joy of a software development team is certainly something more rarely discussed. In this article, Doc Norton proposes a simple way to asses the happiness of your software developers using the quality of your existing code. With this, you can lower your Scrum team turnover and get hints for refactoring needs.
Copyright © 2009-2019 Martinig & Associates