Scrum Agile Project Management

Servant Leadership for the ScrumMaster

September 26, 2012 0

This article by Badri Srinivasan discusses the important notion of team leadership in Scrum and how the ScrumMaster should be a Servant Leader for the Scrum team. The article presents the principles of Servant Leadership. This is a philosophy and practice of leadership that is defined as “a management philosophy which implies a holistic view of the quality of people, work and community spirit. A servant leader is someone who is servant first and who contributes to the well-being of people and community.”

Book Review: Essential Skills for the Agile Developer by Alan Shalloway

September 25, 2012 0

If Scrum provides the project management framework used in a majority of Agile projects, eXtreme Programming (XP) is the main source of technical practices for Agile software development. This book written by Alan Shalloway, Scott Bain, Ken Pugh and Amir Kolsky is focused on these technical aspects. The first part deal with the coding and testing activities, and the second part discusses how to handle the software design activity with an Agile perspective.

Release Planning Value

September 20, 2012 0

In this article, Vaidhyanathan Radhakrishnan discusses about the value of release planning in Scrum. This is the tool to schedule timelines for a project or a product in a complex environment where the outcome of one team is required for the other teams. The article proposes an approach to produce a release plan. This approach is based on the finding primary and secondary features in the product backlog. You can then determine whether the resources are adequate and what interdependencies exist to adjust the feature layout. The article presents the advantages of a release plan and the common disadvantages of this situation, like including ongoing or generic activities spread across the timelines which dilutes the focus of the plan.

Doing “Scrum, And”

September 19, 2012 0

In this blog post, Gunther Verheyen discusses how he quit the “ScrumBut” expressions to move to a “ScrumAnd” status. He shares with us a nine questions test to determine if you are doing Scrum, but beyond the mere crossing the line of ‘yes/no’ doing Scrum there is a myriad of possibilities to play Scrum, but he explains that the core practices presented in the test are at the core of the Scrum framework and that doing less is not doing Scrum. He suggests to use Scrum as a framework for Continuous Improvement and look for ways to measure it.

The ScrumMaster Is Not a Project Manager

September 11, 2012 0

In this article, Steve Hunton explains that, even if people expect that the shift to Agile practices includes a wholesale shift of roles,, the ScrumMaster does not play the part of the traditional project manager. He thinks that the project manager role is more filled by the product owner. The project manager is a decision maker accountable to the business for accomplishing the project objectives. The ScrumMaster is a coach and facilitator that sits between the project and the customer. He isn’t responsible for the project or managing the development team. If you have questions about the product, then you should ask it to the product owner. He concludes that if the ScrumMaster is making decisions about a product, then Scrum has not been properly implemented and there’s going to be confusion and conflict about who does and owns what.

Why You Should Not Estimate in Hours or Days

September 4, 2012 13

Developers don’t like to provide time estimates for implementing a software feature. Management, on the other hand, has a legitimate need for project management estimates. This article explains how the Scrum Agile Project Management framework provides a solution to this conflict.

Pair Programming Report

August 30, 2012 0

Pair Programming is an Extreme Programming (XP) practice where two developers collaborate on the same code on one workstation. In this blog post, Yan Pritzker provides an experience report after his first nine months of pair programming. On the positive side of pair programming, he lists quick knowledge transfer, improved productivity and higher quality code. The disadvantage of this practice are a tired voices, difficulty to research and learn, need for space for creative activities, longer time spent on trivial tasks, possible issues with sharing the same configuration for the development environment. His conclusion is that “pairing coupled with an extremely pragmatic approach to knowing when not to pair is the key to success.”

1 106 107 108 109 110 145