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…..

Ken Schwaber, co-developer of Scrum, just gave an interesting talk at the Agile Project Leaders Network. Scrum, he explained, is not a methodology, but a framework for developing complex products.

The thing about complexity is that the more of it we have, the less likely it is that an external entity can dictate our way to success. There are just way too many variables and too many unknowns. Instead, what we need is a safe, supportive environment in which the team can generate ideas to dynamically deal with this complexity.

Scrum serves as a container for this environment. It’s not a methodology, it doesn’t tell us what to do (we still have to figure that part out). Instead, it exposes the weaknesses and, dare I say, failures in how we’re doing it.

Read More…..