Iterative Product Creation: lean, agile and continuous delivery

At Sikka, I introduced iterative product creation in 2015. It did take us two years however to find our footing and after a lot of trial and error, we finally settled for a design and implementation methodology that works for us (and enables us to deliver those Minimal Lovable Product weekly drops that delight our customers).

Iterative software development = How to create technology that we can build, test and release in small parts rather than building the whole thing and releasing it all at once.

See, after trying Agile and see it fail miserably (for all the good reasons), I did innovate at Sikka and opted for our simple “sikka lean” against continuous delivery and faux-fake-agile. 

My personal nirvana would have been a healthy combination of design thinking, agile and lean; however one must always find the right spot based on the DNA of the teams we're working with. 
​
For this reason, I'd like to take this opportunity to summarize my take (and an extended summary of a few others) on what are the most efficient iterative design methods in 2017. 

Lean iterative product creation

This is more or less the de-facto way of developing for innovation and new products: lean - iterative, intuitive, creative (vs. the traditional incremental, staged, uncreative tech methodologies favored in the distant past). 
Lean basically focuses on evolving a product based on continuous market feedback by testing every new idea and every assumption with users on a daily (more reasonably weekly) basis. The product team starts by creating a small initial set of features (I call this the “Minimal Lovable Product”) and drops it to the marketplace in order to get immediate end-user validation early on.  We then continue to iterate the product in fast build-measure-learn cycles, while the product team prioritizes the features and direction as user feedback data keeps coming in. 
The lean product development was pioneered and perfected by Toyota  for manufacturing (then adopted by Apple) - and very well summarized by Eric Ries in his book “the lean startup”. 

The beauty of Lean is that it connects metrics directly to product development. In other words, there is immediate understanding of the effect of a new feature on the business’s revenue. It places the end user in the driving seat of the product and its roadmap. 

• Companies using lean:  Unilever, Intuit, GE, Toyota (manufacturing), Apple (manufacturing)
• Benefits of lean:  Products more aligned with market needs, faster validation of products/features, reduced risk, better prioritization of work, features closely tie up with the business model 

Design Thinking

I love Design Thinking. Personally when I ideate I always start by applying Design Thinking to my thought process. Design Thinking, which applies the creative approach of designers to any problem was invented at Stanford’s D-School. It’s a very solid and beautiful process for design and ideation amongst creative types. However it really takes forever if done well to actually hatch anything that makes sense because it heavily relies on guided exploration and brainstorming.  And difficult to implement when you don’t have superbly creative types in your product team. But IDEO has been extremely successful and the first to apply Design Thinking to business-driven products.

Benefits of design thinking

• Team cohesion (my teams at Nvidia are still raving about it, 10 years later)
• Highly creative outcomes

Common issues with  design thinking

• Long discovery timeline
• Unexpected results
• Requires a lot of (intense) interactions with current users

agile

First and foremost, Agile is dead. Agile was created in 2001 as a simple way to implement lightweight development processes to make software better and was built around 4 basic principles: trust, collaboration, improvement, and accuracy.

Then the old-guard (stuck in a closet waterfall mindset and non-technical with no hands-on code writing experience) stepped in and made it “a process”.  the result: well, another process. 
So let’s go back to Dave Thomas’ (and his friends) original manifesto:
​
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

•  Individuals and interactions over processes and tools
•  Working software over comprehensive documentation
•  Customer [user] collaboration over contract negotiation
•  Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

I am not going to spend time on scrum and other methodologies that have been invented to implement agile but I’d say this, the key reasons why dev teams love agile are:

• Test driven development (TDD) — this  means that no QA is necessary in agile
• Estimation (this is when most dev teams fail: incorrect estimate and lots of padding!)
• Pair programming
• Backlog prioritization
• Retrospectives
• User stories

However, for as long as agile software development is not part of an agile organization incorporating agile governance and agile budgeting, there is no point in trying to fit a square peg into a round hole … it will fail, here are the common issues that “faux-agile” mindsets have a real hard time to understand: 

• Less certain timelines
• Impacts whole organization, not just tech/product
• No product roadmaps (that’s hard on the fake-agile crowd)
• Embracing uncertainty (that’s also super hard for most)

Companies using adapted versions of Agile (DevOps): Apple, Facebook, Google, GM and Spotify

When the Agile mindset is strong, here are the 3 main benefits to the organization:

• Faster, iterative development
• (Almost) bug free code with no QA (thank god)
• Higher productivity from fewer people 

conclusion

Rapid development methodologies have three major caveats: first, they require a uniform mindset across the board at every level from all teams, most importantly dev and product. The most common pitfall is for dev to demand waterfall-style specifications, supremely detailed flows, prototypes and mocks, though not in the form of PRDs and MRDs but already broken down in long and cumbersome encyclopedia-britannica-style epics and user stories, thus completely negating the purpose and philosophy of rapid development frameworks. 

Second, issues will arise when old-school organizational practices, such as re-introducing QA as separate of dev (QA does not typically exist in modern devops orgs) compounds the previous issue by adding another layer of administrative thus slowing down the process. often to a crawl. 
Remember, in 2017, the data represents the user, and nobody else. The sooner you get your product in the hands of your users, the more and the faster you learn from them. 

Lastly, devops organizations must understand that with rapid iteration comes with a lot of cost in terms of code written and re-written - teams must provide for some "adjustment" periods typically dedicated to refactoring and re-alignment.

---

My name's phil mora and I blog about the things I love: fitness, hacking work, tech and anything holistic. Since July 2015, I've been the Head of Product at Sikka. We're using big data, analytics, machine learning and AI to redefine medicine - our angle is the business of being a doctor. What we do is very, very cool. If you want to talk to me about that, you are more than welcome to contact me here or follow me on medium or twitter and chime in.

---

​Join my newsletter: 
I send my personal notes, usually for the week, with the links I found interesting and why they mattered. It's fun, I promise!