Articles on Scrum and Agile Project Management
Metrics are an important part of the Agile software development approaches like Scrum. They are however, like velocity, more often focus on the performance of the delivery team. What about the customers? In this article, Fabio Gasparri discusses Key Performance Indicators (KPIs) that will matter for the clients.
A Scrum team cannot deliver value without a good Product Owner. This is for me the most important role and it is not easy to keep an Agile balance between a long term business vision that could lead the team to success and the ability to adapt to change after receiving customer feedback. In this article, Zuzi Šochová shares a list of the most common mistakes made by Product Owners.
T-shaped skills is a metaphor used to describe people with deep vertical skills in a specialized area as well as broader but not necessarily deep skills in other areas. This is a base for cross-functional Scrum teams, but people can resist this. Learn why and what you can do to change this.
The ScrumMaster role is certainly the most original addition of Scrum to the concept of software development teams. How and how much the ScrumMaster should be involved with the teams is a topic for debates in the Agile community. Isn’t the Scrum team supposed to be self-organized in the first place? In this article, Zuzi Šochová, author of The Great ScrumMaster, shares her opinion on some of the common mistakes made by ScrumMasters.
Sometimes, organizations adopting an Agile approach are mostly following Scrum practices like rituals. They might do daily stand-up meetings but do not perceive that the real goal is to deliver quickly value to the customer. In an article, Vinod Santhanam explains how the Value-Oriented Incremental Delivery (Void) approach can help Agile teams to achieve this goal.
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.
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.