Steve Neiderhauser

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.

Five Levels of Leadership

Bob Anderson wrote a wonderful article on the stages of leadership.

Leaders will only have the necessary skills to lead today’s organizations when they reach the Creative level. Bob defines leadership as the deployment of self into circumstances.

"As a leader, you are your primary asset. How you show up moment to moment is your leadership impact."

In their book Mastering Leadership the authors make the key point that Reactive leaders will eventually sabotage agile transformations. 

Qualities of the Best Continuous Discovery Teams

Teresa Torres says the best discovery teams have three mindsets.

1. Collaborative Mindset 

2. Continuous Mindset

3. Experimental Mindset

Also, avoid hand-offs and co-create with teammates.

How to Build a Better Business through Design

IDEO posts a wonderful article on how to design your business.

They discuss how to prototype various elements of the business and determine if the business is economically viable.

Software developers should take note of the prototyping concepts. Don’t try to estimate the time to create the prototype, simple put a timebox on it.

“Creativity loves constraints. Put a budget and time limit on your prototyping, and see where it gets you."

History of Agile

A nice article from Jeff Sutherland and Hirotaka Takeuchi that delves into the history of Agile Innovation.

It may have all started when Walter Shewhart of Bell Labs applied Plan-Do-Study-Act cycles to the improvement of products and processes.

Roadmap to TDD Adoption

My experience getting teams to practice Extreme Programming techniques like Test-Driven Development (TDD) says that the typical approach of sending developers to a class and having them practice what they learned back at work doesn’t play real well.

Instead, I like the approach described by Ben Scott.

Summary of TDD Approach:

• Focus on design and clean code
• Learn how to write unit tests
• Enforce tests in the same commit as production code
• TDD exercises
• Complete well suited stories in TDD fashion
• Switch to TDD