Steve Neiderhauser

Three Types of Scrum Teams

Brian “Ponch” Rivera writes a nice article that exposes the three types of Scrum teams.

For the team type that provides a significant advantage, here are a couple characteristics:

* Two or more people who work interdependently, adaptively, and dynamically toward a shared and value goal (This is actually the definition of a team)

* Improve team interactions daily

* Each team member can lead any event

Running a Business is a Design Job

Ayse Birsel describes how Alan Mulally used Design to run Ford.

She shares five principles for how to act like Mulally, a designer of business.

The second principle, have empathy, actually includes a bias for action. Get out, meet people, talk to them...

By working as a Ford car salesman, Mulally developed empathy. In about an hour he sold three cars, and this is how he saw firsthand how customers approached their trucks and cars.

How to Run More Experiments

“Our success at Amazon is a function of how many experiments we do per year, per month, per week, per day."

— Jeff Bezos

This Fast Company article talks about companies running thousands of experiments.

If you want to run more experiments, here are some steps to take:

1. Build a platform that enables you to run 10 to 100 times more experiments.

2. Set aside a percentage of your development budget just for experiments. Shoot for around 10% of budget for experiments.

3. Create an environment where the most junior employees can run their own experiments.

How to Accelerate Innovation

In a podcast, Barry O’Reilly explains how to accelerate innovation.

One of his tips? Think big; start small.

Introduction to Experiment Pairing

David Bland writes a great article about experiment pairing. 

What is Experiment Pairing?

"Experiment Pairing is simply knowing what other techniques fit with an experiment to further advance your learning."

David goes on to provide examples and shows how a Landing Page can be paired with Online Ads. Great stuff!

David shares additional articles here.

We must realize that the ability to experiment is a core skill that every product team needs to develop.

MVP: Skateboards vs. Cars

Because the concept of minimum viable product is key to developing successful products, here’s a post by Marty Cagan on MVP.

Marty covers one of Henrik Kniberg’s posts on MVP. Instead of using software engineers to build software in a two-week sprint and then get customer feedback, you can move faster by building rapid prototypes in a couple hours and then requesting customer feedback.

If all of those iterations are done using engineers and each requires releases to production, we’re probably at several months if not years of elapsed time, assuming management or the team hasn’t lost patience.  However, if we can do those same 10-15 iterations in a week of discovery, we’ve reduced our time to deliver the right solution (defined as both building the right product and building the product right) to our customers from months to days

My suggestion is that developers become more T-shaped and learn design thinking skills; the ability to build rapid prototypes using drawings or storyboards is one of those skills.

Design thinking lets a team validate a product idea in weeks instead of months or years.

Minimum Viable Product Resources

The book “hello, startup” looks like an excellent read. 

I was impressed by the number of resources it provides for creating a minimum viable product (MVP). Why spend days creating an experiment when it should only take hours.

I’ve known some product managers who are confused about MVPs. A minimum viable product is not a product, it’s a process.

There’s also a link to how Spotify creates MVPs.

 

Save the Cat Beatsheet Tips

In this Save the Cat! Podcast, Naomi Beaty and Don Roff share tips on how they write stories using the Save the Cat! beat sheet.

Don always starts with the final image and works backward to the opening image. Then he works with the five key beats; Catalyst, break into two...

You don’t have to start at the top of the story, the opening image. It’s smart to start with the final image and work backwards. 

You're setting a target where you want the entire story to aim. This gives you direction, then reverse engineer to get to your goal. It also lets you experiment to see if you have the right character for your story.

If the character doesn’t change that much then maybe you have the wrong hero for this story. 

Agile is a Form of Rapid Development

Some random thoughts about the Lean Software principle, Deliver as fast as possible:

Deliver fast does not mean work harder. It means work smarter. Leverage the power of software (automation, Object-Oriented techniques...) and Extreme Programming to deliver faster.

When Jeff Sutherland invented Scrum he intended that Scrum be used with object-oriented (OO) languages like Java and C#. That's because object-oriented languages have features that enable rapid development, allowing developers to respond to change and deliver working software by the end of the sprint. So you can view Scrum as a form of rapid development.

Scrum requires Extreme Programming's technical practices (TDD, Continuous Integration) to meet the goal of delivering software by the end of the sprint. A team is not considered Agile unless they can delivery working software that is potentially shippable by sprint's end.

Cross-functional feature teams are also needed for rapid development. Feature teams have all the skills needed to create and deliver the application. The work of the feature team will often result in an object-oriented framework that will help the feature team build software even faster.

Ideally, teams need to figure out how to deliver software so fast that stakeholders don't worry about the team's ability to deliver. Deliver fast is important because Amazon releases software to production every 11.6 seconds; this means Amazon has the ability to learn about customers at a fast pace. This is a key metric: How fast are your learning cycles?

In fast-moving organizations, the work is structured so that the people doing the work know what to do without being told and are expected to solve problems and adapt to changes without permission. This is the power of self-organizing feature teams.

Agile Coach Basics

Damon Poole shares Agile Coaching basics in this post.

There’s some excellent material here that will make you a better Agile Coach.

I liked his notes on the ADKAR change management tool.