You’ve got your vision of what you want to build.

You’ve also got a ton of unknowns and uncertainty. You know you can’t just go build it and hope they will come. You have to do it iteratively. Put a little bit out there, see how people react, figure out what to do next.

But where do you start? How much is enough to start getting feedback?

Josh Seiden gave this awesome talk at Boston’s Lean Startup Circle on replacing requirements with hypotheses. And it occurred to me that what he’s really talking about is hypothesis-driven development, which I love.

In Agile, we drive our development with tests. We say, “okay, I know what the product needs to do, so let me write the test first.” It’s an automatic check. If I accidentally develop the feature incorrectly, the test will fail and I’ll get immediate feedback that the feature isn’t ready yet.

But what about in a startup where we’ve only got guesses for what the product should do? Then the tests should not be whether features are implemented correctly. Who cares if nobody wants them?

What we do care about is creating a successful business. So those tests aren’t for if the product works, they’re for whether it’s the right product. Now we’ve got an automated check. We don’t waste our time & money building something until we’ve validated it’s the right thing to build.

Read More…..

MIT’s Entrepreneurship Center asked me to give an Agile Product Management workshop for their Hacking IAP course. The course is a special seminar in management they’re doing for MIT student entrepreneurs. It takes place over the IAP (January) term and is open to all MIT students that have startups already underway.

The first week of the course is a series of guest lectures from industry experts on how to get shit done (that’s where I come in). After that, the course serves as a mini-accelerator with students applying what they’ve learned to their startups and receiving mentoring from myself and the other lecturers. The course concludes with a demo day at the end of the term – which I can’t wait to see!

Here are my slides – I actually beefed this up a little for SlideShare, adding some bullet points for the key talking points (I know, bullet points suck – but otherwise all you have are pictures). Hope you enjoy!

Maybe it’s all the time I spend with startups, but while I strongly value Scrum’s ideas behind self-organizing teams & continual feedback – I can’t help but feel Kanban represents the next level of agility, giving us more flexibility and capitalizing on the lessons we’ve learned from Lean.

Scrum

A lot of people tend to think Agile means Scrum – you know how it goes:

Is Agile the same as Lean? When people say “agile” do they really mean Scrum? Or do people still use different types of agile – and if so, why? 

Been getting a lot of questions lately, so thought I’d take a stab at this…

Lean

Lean comes from Lean Manufacturing and is a set of principles for achieving quality, speed & customer alignment (same as what we’re trying to do with agile development, right?).

Mary & Tom Poppendieck adapted the principles from Lean Manufacturing to fit software development and I believe these ideas actually provide the premises behind why agile works:

Read More…..