Articles, Blog Posts, Books and Quotes on Agile Project Management
We all know that there are three roles in Scrum teams : product owner, scrum master, and the development team. Modern software development can sometimes require some specializations that could be beyond the capabilities of the Scrum team members. UX and Web design, database administration, performance testing are some examples of activities that requires specific expertise only for a limited amount of time. How do you deal with it?
The Kenneth Rubin’s “Essential Scrum” book starts with a foreword by Mike Cohn who writes “there must be billions of possible ways to implement Scrum. And while there is no single right way, there are better and worse ways to implement Scrum.” Mike Cohn writes also “what works in one company or project will fail in another”. The presence of Mike Cohn in this book is not a surprise as Kenneth Rubin hired him in 2000 to work on the implementation of Scrum at Genomica.
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.
Following the famous mantra of “you can’t manage what you can’t measure”, Scrum teams have often a set of metrics to monitor their activity. Velocity, the amount of work performed by a team during a single sprint, might be one of the most famous Agile metric. Doc Norton has written an interesting book about the negative sides of velocity and what might be a good metric for an Agile team.
Gojko Adzic is known in the Agile software development world for his work on requirements presented in his book “Specification by Example – How successful teams deliver the right software”. In this small and easy to read book, he focuses on a single tool that could be very useful for Scrum teams: impact mapping.