Want to talk about something controversial? Politics? Religion? Healthcare? Mere child’s play compared to the deeply entrenched beliefs about the effectiveness of the Scrum or Agile practices in software development shops.
OK, maybe that’s a bit of a hyperbole, but the senior leadership that I’ve consulted with over the years tend to have impenetrable convictions about the value, or utter lack of value, that Agile practices brings to a project. Most acknowledge that the traditional waterfall techniques are doomed from the outset. A lot of time and energy are devoted to understanding user needs, creating project plans and dependencies, and updating colorful Gantt charts. Yet by the end of the project, most of that has proven to be wasteful. Even if the timeline and budget have been managed effectively, the landscape has changed and the requirements and assumptions documented at the outset of the project are no longer valid.
However their experiences with Agile haven’t produced the panacea that the development managers have promised. They’ve been poorly executed and communicated.
In his book The Lean Startup, Eric Ries describes the many parallels between starting a business and developing software. The traditional way of starting a business involves creating a thorough and well-documented business plan, spending an inordinate amount of time and capital creating a product or service, and finally building an elaborate infrastructure to deliver the product/service to the customer. By the time all of that is done, the business owner may learn that what he’s built is not needed by the customer. Sounds a lot like the waterfall approach, huh?
Ries suggests adopting a “lean” approach to starting a business, or a new division within an existing business. “Lean” is manufacturing’s term for Agile. Create a Minimum Viable Product (MVP), one that you know is incomplete, and get it front of customers as soon and as often as possible. Watch how they use it, what they like and what they don’t like. Learn from them by conducting A/B experiments, trials where some of the customers have one experience while others get a different experience, and make adjustments based on the results.
Ries contends that productivity in a startup should be measured not by features created, hours worked, or any other traditional method, but in the amount learned. He describes and promotes a process to effectively do this in a measured and intentional way for most any type of business.
He essentially combines the Scientific Method, Agile/Lean practices, and small business ownership mentality so that you know what is important to your customer and what isn’t. Spending time on something that isn’t wanted is wasteful. Ries outlines a systematic approach for determining that.
It makes sense to me.