Lately the conversations I am seeing happen around agile are more about what agile is really about, as opposed to specifically how to “do it right”. Getting a break from drum beating around which practices are “real agile” or “real scrum” is really refreshing. I’ve been particularly re-energized by the conversations around MVP, minimal viable product, and how it’s NOT just a v1.0 of your app. Instead, a better way to think about your MVP is that it’s the earliest possible opportunity for learning*. Learning what you’re doing right, what you’re doing wrong, and figuring out how to improve are key things you can take away from your MVPs. I feel like it was always an undercurrent of WHY people released MVPs in the first place, but at the end of the day it was often marketed as getting code into customers hands sooner. I’ve never met a C-level executive with numbers to make that was jazzed about tossing a barely functional V1 of their app out to customers purely as a rapid time to market strategy. It’s simply not compelling enough given all the risks that strategy could bring. But tell them that it’s about better focusing of the (very expensive) team’s efforts, more quickly getting to the heart of what customers REALLY want, and not wasting time on the things customers don’t care about? That equates to real dollars, and the C-level folks can put their arms around that. It’s not even that revolutionary of a concept, I think a number of people in the race to adopt agile get hung up on the execution, and lose sight of the goal.
*I’d give credit to someone specific for that little nugget, but everyone I follow on agile lately is saying this and I have no idea any more who said it first.
I won’t wax philosophic on it further, because that’s the whole purpose of the meet-up I want to encourage you to attend in Chicago next month. In fact, it is a SUPER meet-up. For real, how do you NOT attend a free *super* meet-up. More details can be found at the Chicago Agile Open Space Meetup site but here’s a brief synopsis to tempt you into joining the group and signing up to attend:
David Hussman - How to Build the Wrong Thing Faster and Learn From It
- For years we’ve worked hard at software development. Agile methods have allowed teams to establish better flow in software development; refactoring language, not just code, presents itself as the next meaningful evolution. Can ‘software development’ be refactored to ‘product development’? Some brave pioneers that are already doing this, and are re-learning that building the product is much less clear than simply getting work done. The land of product development is filled with holes or ambiguity and laced with land mines of wrongness. Ideas that you are certain about often fizzle or change when you watch someone interact with your product. Being overly certain or overly focusing on ‘just getting work done’ are weak weapons in a place where being wrong, and learning from it, is a vital part of finding your way to success.
Instead of talking about ‘why you should do agile,’ let’s explore ‘why you should think in product,’ assuming you are using some agile practices. Our journey will explore the messy, sloppy and non-linear aspects of product development. Along the way, we’ll investigate how software construction is important, but courageously failing and learning in product is even more essential. We’ll look at how some teams are producing more real product value with less code. We will also peer into the world of program level development, where collections of teams produce product without injecting incidental complexity by employing what you might call ‘test driven product.’
Who knows, toward the end of the journey, we might even rally to refactor the agile manifesto to read ‘Learning in Product over Simply Getting Things Done.’”
Hope to see you there on July 20th! If you can’t make it for this one, be sure to join the meetup to learn about other upcoming topics.