What looked like a good idea back in the 1990ies—outsourcing software development as a non-essential business area—has meanwhile massively backfired for a lot of legacy organizations. While they try to become more appealing to product and software developers, they still have difficulties understanding what it takes to build an attractive product/engineering culture. Learn more about typical anti-patterns and signs that an organization is causing a toxic team culture, impeding its efforts to become agile.
If technical debt is the plague of our industry, why isn’t the Scrum Guide addressing the question of who is responsibly dealing with it? To make things worse, if the Product Owner’s responsibility is to maximize the value customers derive from the Development Team’s work, and the Development Team’s responsibility is to deliver a product Increment (at least) at the end of the sprint adhering to the definition of “Done,” aren’t those two responsibilities possibly causing a conflict of interest?
This post analyzes the situation by going back to first principles, as laid out in the Scrum Guide to answer a simple question: Who is responsible for keeping technical debt at bay in a Scrum Team?
Team building has always been a challenge, not just since the advent of agile frameworks and the resulting emphasis on self-organization, engagement, and achieving a valuable objective. This post covers four team building mental models — or concepts — that have proven useful in understanding the context of creating agile teams: from Taylorism to Tuckman to Lencioni to Dan Pink.
The seventh Hands-on Agile webinar Scrum Sprint Anti-Patterns analyzed 12 ways a Scrum team can improve its effectiveness by avoiding typical sprint anti-patterns. Learn more about gold-plating, delivering Y instead of X, absenteeism, side-gigs, and organizing people instead of the flow of work.
The main message of the retrospective was clear: there are too many interruptions by stakeholders and senior management. The interruptions impeded the flow of work through the team. Consequently, achieving the sprint goal had been at risk several times in the past. Moreover, the team missed the sprint goal twice recently. Solving impediments as a team has become a necessity.
Learn more on how to tackle impediments as a team by running experiments and iterating on the solution.
A meta-retrospective is an excellent exercise to foster collaboration within the extended team, create a shared understanding of the big picture, and immediately create valuable action-items. It comprises of the team members of one or several product teams—or a representative from those—and stakeholders. Participants from the stakeholder side are people from the business as well as customers.
Meta-retrospectives are useful both as a regular event, say once a quarter, or after achieving a particular milestone, for example, a specific release of the product. Read more on how to organize such a meta-retrospective.
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
