02 Feb 2012 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

31 Jan 2012 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

26 Jan 2012 James Shore/Calendar

Diana Larsen and I are partnering with Cyrus Innovation to deliver our acclaimed "Art of Agile" training course in New York City from April 23rd to 27th. There's also an option to attend just the planning or delivery section of the course if your schedule doesn't permit you to attend a full week. For details and registration, visit the Art of Agile NYC web site.

Comments

26 Jan 2012 James Shore/Calendar

I'll be speaking at the Philly Emerging Technologies conference taking place on April 11th and 12th. The title of the talk is "Kanban, Lean, and Large-Scale Agile." Here's the blurb:

Agile methods work beautifully for a single team. But what do you do when you have multiple, interdependent teams, all working on a single product or product suite? How can Agile scale without losing sight of its core principles? In this session, we'll examine how to apply Lean and Agile principles to the problems of large-scale Agile. We'll combine a pinch of theory, a dash of experience, and a heaping helping of crazy ideas to give you something to try on your large-scale projects.

Comments

17 Jan 2012 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

12 Jan 2012 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

10 Jan 2012 James Shore/Calendar

The AgilePDX user group is having its yearly Agile Tune-Up this month and I'm facilitating. The event is free to all. Location and times are on Calagator. Here's the blurb:

It's time for your yearly Agile tune-up! Has your Agile team made its new year's resolutions yet? If not, this month's AgilePDX meeting will help. It's all about helping you understand what you can do to improve the state of your Agile practice.

James Shore will kick things off with a description of Agile Fluency. He'll describe multiple levels of proficiency and help you figure out where your team is today. Then, he'll provide specific techniques and practices to focus on as you work to reach the next level.

Next, we'll turn it over to you! You'll break into groups focused on the issues that matter most to your teams. You'll have the opportunity to learn from each other's experiences and to discuss how you can improve your team. Experienced Agile practitioners will be on hand to answer questions and help you figure out which improvements will make the most difference for you.

This event is free and is at Puppet Labs. It begins at 6:30 pm with pizza, sponsored by PNSQC (Many thanks to both Puppet Labs and PNSQC for supporting agile in Portland).

The program starts at 7:00 pm.

After the program you're invited to join us for a no-host gathering at a nearby brewpub for further discussion of agile fluency.

Comments

10 Jan 2012 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

03 Jan 2012 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

29 Dec 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

27 Dec 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

22 Dec 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

20 Dec 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

15 Dec 2011 James Shore/Blog

In today's Portland Entrepreneurs' Salon, we were talking about Lean Startups. As we talked, I had a realization.

In Lean Startup, there's a lot of focus on creating a Minimum Viable Product (MVP). Like Sprints in Scrum, it's an easy concept that people latch onto right away. But perhaps that's the wrong focus. Maybe it's not MVP we should focus on, but MVH: Minimum Viable Hypothesis.

The Minimum Viable Hypothesis

In working on Rabu, Diana and I ran into a common problem. We were in love with our product. We loved designing it, thinking about it, creating it. We focused on creating an MVP, and when our target market didn't respond, we said, "Well, that must have been too minimal. Let's make it more robust." And we dived back into product development. We ended up with a nice product that hardly anyone uses. Then we ran out of money.

We were following the build-measure-learn cycle, but falling into an easy trap: persevering when we should have pivoted. I think it's because we were focusing on MVP at the expense of MVH.

With MVH, the first step after figuring out the problem to solve isn't to create a minimum viable product. Instead, the first step is to brainstorm market hypotheses. Which groups have the desire and funds for a solution? One way to brainstorm would be to put a big graph on a flipchart with "Desire" on the X-axis and "Funds" on the Y-axis. Potential markets would be brainstormed onto sticky notes and placed onto the chart. The guess in the upper right--the one with the most desire for a solution and the most collective funds to pay for it--is the first market to test. It's your best guess market.

It's still a guess, though. So rather than going out and creating an MVP, test the market. That's what an MVP is for, too, but I'm shifting the emphasis. For me, and I think for most people, it's way more tempting and fun to work on product than it is to work on marketing. But in the early stages of a startup, when you're discovering product-market fit, "market" is just as important as "product," and much less tempting to work on.

At the end of the build-measure-learn cycle, you have a decision to make: Pivot? Or persevere? Our mistake with Rabu was that we persevered when we should have pivoted. Our measurements showed us, over and over again, that people weren't using what we had built. We assumed that the problem was in our product, but I think it was much bigger than that: the market we had chosen didn't actually care that much about the problem we were solving. But because we were focused on our product, we kept investing in improving the product rather than pivoting to a new market.

Instead, I wish we had tested our market assumptions. We had made two implicit assumptions: that programmers on Agile teams wanted a tool to help them collaborate with their sponsors (desire), and that enough of them would pay us to customize such a tool to their situation (funds). We did test those assumptions once, with a successful landing page, but then we shifted gears to creating an MVP. We should have stayed focused on our assumptions.

The minimum viable hypothesis provides that focus. Product is built as a last resort. Each MVH is focused on providing an un-ignorable answer to the pivot or persevere question. To define an MVH, look at your market assumptions. Consider which are the riskiest, and ask yourself, "What unambiguous test would I trust so much that I would abandon this market and pivot if the test failed? What's the smallest test that I could perform that would give me that confidence?" The important part is to create this MVH in advance, with a clear and unambiguous pass/fail criteria, so you can overcome the temptation to simply press on when you're in the throes of development.

The MVH doesn't validate your market; instead, it helps you fail fast. Once you have your MVH, you go through the build-measure-learn loop: build the test, measure the results, and learn from them. Using your pre-established criteria, if the test failed, you abandon the market and choose a different one. If the test passed, you've validated one assumption, but more will remain. Choose the next riskiest, define another MVH, and build-measure-learn again.

Conclusion

I'm not changing any of the fundamental Lean Startup ideas. Testing hypotheses is what MVPs are for, after all. But by focusing on product rather than creating an explicit hypothesis, I found it was human nature to spend way more time on the fun product stuff than I should have. I'm hoping the MVH approach will help prevent that mistake next time.

In summary:

1. Don't start with a product.
2. Instead, start by brainstorming potential markets. Choose the one that looks most promising.
3. Consider your riskiest assumptions about the market. Pick one to test.
4. Define a test that you'll trust if it comes back negative. Figure out the cheapest/fastest way to perform the test. This is your MVH: minimum viable hypothesis.
5. Build-measure-learn. Build the MVH, measure the results, and take action:
6. If the test failed, discard that market and pivot. Start over with step 2.
7. If the test passed, persevere. Continue with step 3.

Thanks to Willem Larsen of Language Hunters fame for providing the case study we used to catalyze our discussion on this issue.

Comments

15 Dec 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

13 Dec 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

08 Dec 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

07 Dec 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

01 Dec 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

30 Nov 2011 James Shore/In-the-News

At this year's Norwegian Development Conference, I gave a new presentation on evolutionary design, and NDC was good enough to record it and put the video online. It's a highly visual look at how evolutionary design has worked in practice on three projects I've been involved in. It's good to watch if you've ever wondered how evolutionary design plays out in practice. Here's the blurb:

In an agile environment, programmers must deliver working software in the first iteration. Requirements may change at any time, so there's no way to design the software in advance. Instead, you must design your software based on its current needs, and evolve the software design as the requirements change. This process is called evolutionary design. (It's also called continuous design, or iterative and incremental design.)

But how does it work? How can evolutionary design result in high-quality code? In this visual and example-filled session, James Shore will demonstrate how evolutionary design works in practice, using real-world examples culled from his decade of Agile development experience. You'll see how designs evolved in response to external forces, and how responding to those forces yielded in designs that were clean, flexible, and maintainable.

(Note that the video is in MP4 format, which may not work in your browser. If it doesn't, you can download the video using the link below.)

Download the video here (MP4 format).

NDC has graciously made all of the conference videos available as a Torrent as well as individual downloads. Find them here.

(Thanks to Camen Design for the Video for Everybody code. Thanks also to Longtail Video for the JW Player Flash video player.)

Comments