Steve Neiderhauser

Speed as a Habit

In my last post, I wrote, "Modular design equals speed."

And speed kills your competition. Speed allows you to get inside the competition's product cycle.

In this article by Dave Girouard, he talks about making decisions with speed.

Truth is, modular design empowers this quote by General George Patton.

A good plan violently executed now is better than a perfect plan next week.

Unlocking the Power of Teams

In this article, Chris Fry tells us how to unlock the power of teams.

Why are teams important? A couple reasons.

• Teams are the atomic unit of growth in Agile. In fact, you resource at the team level. If you have five teams, you should have only five projects.
• It's crazy difficult to increase a person's performance by a factor of three or four. Yet, with a team, in a couple months it's possible to increase performance by a factor of four.

Chris, a system's thinker, believes there are four things you can do to move the needle:

1. Build strong teams first.
2. Go modular. Remove dependencies.
3. Establish a short, regular ship cycle.
4. Keep teams together.

I agree with modular design. Because modular design equals speed. And speed kills. Kills your competition.

Keeping teams together helps make teams stable. Same group of people working on projects for some time. These teams are cross-functional and have all the skills to deliver working software.

Bring the work to a stable team, do not break up teams and bring people to projects.

For more on Stable Teams, see the Scrum Pattern -- Stable Teams.

Agile Leadership

Here's Q&A with Jeff Sutherland on Agile Leadership.

Your teams may practice Agile, and if your managers aren't working as leaders it's unlikely your company will achieve market success.

Consider this Sutherland response:

Their problems are huge but boil down to one problem. The leadership needs to become Agile. They need to support the teams, remove impediments, and coach the organizations to be agile. There are so few managers trained and good at this today that many companies will be driven out of business by their agile competitors.

Steve Denning makes the case that managers hate Agile. So it may be a while before hierarchical companies are able to benefit from Agile.

Guy Kawasaki Entrepreneurship Class

Through Udemy's website, I completed Guy Kawasaki's Entrepreneurship class.

Guy provides practical tips along with deep insights. If you're interested in starting a business, simply take Guy's class.

Six Rules for Reducing Cycle Time

As an Enterprise Agile coach, I teach companies the six rules for reducing cycle time.

• Limit work to capacity
• Even out arrival of work
• Minimize the number of Things-In-Process
• Minimize the size of Things-In-Process (small user stories)
• Use pull scheduling
• Establish a regular cadence

What’s regular cadence? Well... if you have ten Scrum teams working on software, each team should be working on Sprints of the same length. Let's say your sprints are two weeks long.

The sprints should start and end on the same day each sprint. This way executives, developers and support know when the sprint review will be and when sprint planning happens. Teams know how to sync user stories and eliminate dependencies.

Product owners know how to schedule and release software that delights customers.

Continuous Improvement Program

The archetype for a continuous improvement program in Agile starts with Scrum teams resolving impediments they identify.

If those impediments are in the soup, things outside team's control, the issue is raised to an executive Scrum team. The executive team should be cross-functional and have all the skills needed to transform the enterprise impediment backlog into working solutions.

I also recommend that the impediments be displayed on a big visible chart.

Hypothesis-Driven Development

Barry O'Reilly's brilliant blog -- How to Implement Hypothesis-Driven Development.

What is Hypothesis-Driven Development? It's thinking about the development of new products as a series of experiments to learn if the product fits a market or if the product is not viable.

"We do not do projects anymore, only experiments."

So we've become a learning organization. To help us learn we replace the standard user story format (As a user, I want..., so that...) with the following format.

After you write software to test the hypothesis, use continuous deployment to load the software to production servers.

When you practice continuous deployment of experiments you create a system that provides immediate customer feedback and enhances opportunities for innovation.

What a ScrumMaster Should Know

The ScrumMaster role can be a challenging position.

If only because there's so much to learn. Coaching. Extreme Programming. Teaching. Leadership.

Growing Agile has put together a learning framework and a list of topics for ScrumMasters to learn. An excellent place to start your learning journey.

Chief ScrumMaster

If your company has more than two ScrumMasters have you ever wondered how to develop the skills of those ScrumMasters.

You may want to consider the Chief ScrumMaster role. A role that will help develop a consistent practice across teams and provide the framework for ScrumMaster development.

A couple highlights from the article.

Help establish communities of practice -- I meet with my ScrumMaster once a week. We discuss what's working and what improvements we should focus on.

Coordinate Teams -- I don't feel this is so much of a project management function as it is teaching teams about lean software concepts, or object-oriented practices like interfaces.

Agile training -- The Chief ScrumMasters should know how to present effective training. He should understand Innovation Games and Training from Back of the Room techniques.

Ticket to Ride Technical Debt

Ticketmaster describes the trip they have been on to pay down technical debt.

It's a nice model because they track application, architecture, and infrastructure debt.