An Overview of ScrumMaster - Part 2

The Agile method called Scrum empowers the “Team” (the group of developers and the business working together to produce product) to decide together how to do their work without lots of external influence. People who are used to working in a hierarchical, specification and deliverable-oriented environment may have a lot of trouble at first with this combination of freedom and responsibility. It can feel very disorienting. So, within Scrum, there is a role called the “ScrumMaster” whose job it is to help the team with this transition, to stay healthy, and to stay focused on producing product (that’s the “hand” in the diagram on the right).

It is a hard job!

I am running a little Scrum project for a relief and development organization I support. The team is composed of college interns editing and producing video training. They are quite uncomfortable with the freedom I am giving them, and appreciate why I am doing it. It has made for some involved conversations to help them see what they are supposed to do, how I am there to help but not to do and not to dictate. So, I really appreciate the difficulty that ScrumMasters face.

This podcast is Part 2 of a “ScrumMaster Overview” conversation Read the rest of this entry »

 An Overview of ScrumMaster - Part 1

I was in a meeting last week with a number of Chief Information Officers. One of the speakers, talking about Agile and Scrum, used the term “ScrumMaster” and got a lot of blank stares. They had no idea what she was talking about.

This is a fundamental role in Scrum, one of the better approaches for Agile software development. There have been some good articles and books written about ScrumMasters and there is formal Certified ScrumMaster Training available. Yet, the term seems to get in the way of understanding the role.

This is because the terms “Scrum” and “ScrumMaster” were chosen because they were essentially value-free. Thus, the developers of Scrum were free to “pour” their own meanings into the terms. This has proved to be both a blessing and a curse.

“ScrumMaster” is probably a good term, within the context of Scrum. Read the rest of this entry »

Agility Works. You can look at projects and see that more often than not, it delivers the goods. So, why do so many software projects remain artifact-driven and waterfallish? The most common excuses are that agility is too developer-centric, that it is too lightweight, and that feedback to business is hard to understand. In particular, many managers in larger companies miss the metrics that waterfall-type projects deliver.

In a new white paper, we consider a new metric - Earned Business Value (EBV) - to report progress and to manage Agile projects. Read the rest of this entry »

One of the most powerful phenomena that we have observed on effective Agile Development teams is something we have come to call “TeamSwarm”.

In my upcoming blog posts, I will be describing what TeamSwarm is, how you can see it, some simple rules that guide its operation. I will discuss how the TeamSwarm can be coaxed into existence by building upon these simple rules. In Lean, we call putting simple rules into practice, building blocks. I will define and discuss the rules as building block practices and how they synergize to form emergent behavior that shows a team is swarming. Briefly, these building blocks are: Read the rest of this entry »