Steve Neiderhauser

What Should ScrumMasters Not Do

Sam Laing describes what a ScrumMaster should and should not be doing during a sprint.

Let's consider this one: Don't update the burn down chart.

Why is it important that the ScrumMaster not update the burn down chart for the team?

The chart helps the team understand how well the user stories are flowing during the sprint... Will the team complete the sprint on time.

If the ScrumMaster updates the chart the team won't take ownership of the sprint's progress. When the team updates the chart, they'll be more focused on story progress and avoid trying to complete large batches of user stories at the end of sprint.

Are Your Teams Really Doing Continuous Integration?

From the book Lean Enterprise, Jez Humble provides three questions to determine if your development teams are really doing continuous integration.

That's right. Just because your team uses a build server doesn't mean they are practicing continuous integration.

Questions:

1. Are all the developers on the team checking into trunk at least once a day? In other words, are they doing trunk-based development and working in small batches.

2. Does every change to trunk kick off a build process, including running a set of automated tests to detect regressions?

3. When the build and test process fails, does the team fix the build within a few minutes by fixing the breakage?

If the answer to any question is "no," you aren't practicing continuous integration.

Connection Between SMED and Continuous Delivery

Consider the following comparison between single minute exchange of die (SMED) and continuous delivery.

First, the definition for SMED.

Single minute exchange of die(SMED) - A series of techniques for rapid changeovers of production machinery. Ten minutes is a common initial objective. SMED does not literally require only one minute. It implies that die changes should be completed in a single digit of time (0- 9 minutes). Long-term objective is zero setup time to optimize continuous flow.

The goal of SMED is to reduce setup time… To be flexible and switch production between different kinds of products.

Now, it’s fascinating that in Continuous Integration (CI) there’s a concept called the ten-minute build. After you check code in to the CI build server, the automated unit tests created using test-driven development are kicked off and run against the latest code. The tests should run in ten minutes or less (similar time as SMED) so the feedback is given to the team quickly.

So when a developer runs his code changes through the unit tests and deployment pipeline and the code is deployed to production through 1-click deploy, he is making a rapid changeover of production code. After the software deployment changeover, the Scrum team is working on a new version of the software product.

Likewise, Extreme Programming practiced with a pairing station, test-driven development, and one-click deployment optimizes continuous flow.

Who Else Wants a Deployment Pipeline

Jez Humble describes the benefits of a deployment pipeline in this article.

Why is the deployment pipeline in software development important? Because the deployment pipeline is the key pattern that enables continuous delivery.

Like an oil pipeline, the software deployment pipeline helps golden software flow from version control, through a series of tests, to production where users eager fingers wait for new features.

The deployment pipeline helps agile teams practice the first Agile principle.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

How to Manage Technical Debt

Scott Ambler provides 11 strategies for managing technical debt.

Here's an important tip: Have an explicit architecture owner. The architect guides the team through technical decisions and mentors the team in design skills.