Design Thinking / Lean Startup / Agile

As the demands for building Cloud Native Apps for Enterprises are rising, there is a huge vacuum in relevant skillsets. Elastic Engineering is another concept in building or transforming existing teams into highly efficient and effective teams.

Where or How do we start this journey?

The objective of this article is to give a high-level overview of all these concepts/methodologies and how it maps back to building Cloud-Native Apps.

The following image shows how Design Thinking, Lean Startup, and Agile come together to create a highly efficient team to deliver results for modern business requirements. Companies like Amazon, NetFlix, Uber, etc do 1000s of (software) production releases every day.

Let us understand each of these areas briefly and how all these are connected to Cloud Native Apps development.

Design Thinking

Design Thinking is a 5 step process to under the problems and comes up with a solution. To explain this one of my all-time famous quotes is from Henry Ford

“If I ask the people what they wanted they would have said faster horses”.

Ok. Now here is the fun fact — there is no evidence Henry Ford made this statement even though you will find tons of references to Henry Ford in a Google search. Let us understand this statement more carefully. What it says is never take any input from the Customer or User instead Empathize with the customer, understand the pain points, understand the challenges the customer is facing. That's Step 1 in Design Thinking!

1. Empathize (Who the user is? What their needs are? What do they do?)
2. Define (From Step 1: Turn Observations, Discoveries, and challenges into Insights)
3. Ideate (Ideas, Solutions, Potential matches to the problem)
4. Prototype (Build a Prototype a Minimum Viable Product — MVP)
5. Test (Test with Real users, Gather Feedback, Observations, and new Insights)

Some key elements in this definition are Empathize, Human-Centered Design, and Minimum Viable Product. You will see HCD (Technology doesn't matter — means it doesn't matter whether your Backend Code is written in Java, C#, Python, TypeScript, or Go Language — its the Architect / Developer’s choice) in other areas too like in Domain-Driven Design, Microservices Architecture, etc.

Now let us look at the Prototype Stage in Design Thinking which results in building an MVP. This is where the Lean Startup Concepts comes in,

Lean Startup (By Eric Ries)

The origin of Lean Startup came from the movement by Taiichi Ohno and Shigeo Shingo by developing Lean Manufacturing in Toyota.

Over here we are going to look at 1 of the 5 Principles of Lean Startup. Build, Measure, Learn Loop the core to the Lean Startup Model. This enables the “Validated Learning” Principle resulting in the MVP.

In the Learning stage of Lean Startup (by Applying Design Thinking) the key over here is to Observe and Don't Ask what the customer want. The Critical part of the “Build” is building the Prototype and there are 3 types or categories of Prototypes.

1. Video MVP

An example over here is DropBox CEO Drew Houston created a video demonstrating how a typical Cloudbased Drive works without actually building the software. This gave the user the idea about how to use a Cloud-Based Drive and they were able to give feedback. When the DropBox released the video to a selected community the Beta Waitlist subscribers went from 5K to 75 overnight (Page 98 Lean Startup by Eric Ries)

2. The Concierge MVP

Identify a single Customer, start building the Product for that Single Customer and keep improving the product based on the feedback. Once the product gets into a reasonable state start acquiring new customers. Over here product doesn't mean an actual software product from a Technology perspective. From the customer's perspective, their process is simplified by the solution you provided. Manuel Russo CEO of “Food on the Table” creates weekly meal plans and grocery lists based on a single customer and then connected to the preferred grocery store to figure out the best deal.

3. The Wizard of OZ Test

Amazon created a manual book review system and suggestion system(by employing). After they collected a lot of feedback they automated the entire process. Max and Damon thought about Computer Personal Assistant to answer any queries from Customers. The early Aardvark is an example of this process and tried many variations. It took the 6th iteration of the prototype to gain traction with the customers. For close to 9 months they had humans handling the backend system, categorizing and answering the queries. In the Wizard of OZ test the customers felt they are interacting with the Product while in reality, they were interacting with humans behind the scenes. They even raised the seed and Series A funding before the system was automated. This was not a scalable model and like The Concierge MVP, it was inefficient too. Max and Damon kept pivoting until they got it right and eventually acquired by Google for 50 million dollars.

So far we established How to understand the pain points an end-user is going thru and how to capture (or define) the problem statement and then ideate over them to come up with an MVP. Now it’s time we look at the Agile methodologies and see how these will fit into creating the Product mindset.

Agile Values

Agile Manifesto focuses on similar lines.

1. Individuals and Interactions over Processes and Tools
2. Working Software over Comprehensive Docs
3. Customer Collaboration over Contract Negotiation
4. Responding to Change over Following a Plan

To summarize: Watch Jeff Gothelf: Lean vs Agile vs Design Thinking

The first Foundation is the User (Human) Centered Approach — End-user behavior, The User Journey is what we are going to focus on. How to capture those journeys.

Business Capability Centric Design

The focus over here is the Business Capability and the outcome of those business capabilities from the end-user perspective. The teams work in Product mode instead of a project-based approach. What it means is, For Ex. in an e-commerce Application If a team is working on Shopping Cart and Order Processing they will handle that as long as those capabilities are there in the product. The following image explains the concept. Read more: from the article written by Sriram Narayan.

User Stories, Acceptance Criteria, User Journey, and Story Map

The best tool to write user stories is post-it notes.

Now let us understand the Role-Featur-Reason Matrix.

So, the 3 elements “Who, What, and Why” are the building blocks of User Stories. In a very clear and precise language, it defines the end-user behavior. Now let us understand the next aspect of the User Sory — the Acceptance Criteria — They are modeled based on Behaviour Driven Development.

BDD is based on Gherkin language — Given, When, and Then.

Now let us look at the 3 C’s of User Stories. Card, Conversation & Confirmation.

Why do we need stories?

• User stories emphasize verbal communication.
• User stories are comprehensible by everyone.
• User stories are the right size for planning.
• User stories work for iterative development.
• User stories encourage deferring detail.
• User stories support opportunistic design.
• User stories encourage a participatory design
• User stories build up tacit knowledge.

Source: User Stories Applied by Mike Cohn. Page 178

Keeping the spirit of Design Thinking, Lean Startup, and Agile, we are not writing big documents on specifications.

Now let us look at some more examples from an e-Commerce Application.

The above examples complete the User Journey by walking through the following Epics

1. Customer — Registration
2. Product Catalogue — Search
3. Shopping Cart — Add to Cart
4. Order — Order Processing
5. Payment — Payment Processing

Each of these Epics is considered as a Bounded Context in Domain-Driven Design (it can be further broken down into smaller stories in the future). Each Bounded Context will have its source code repository and release plans. For Ex, when you want to add a new Payment method or enhance the functionality of the Product Catalogue it won't affect other Epics. Those releases can be independent. In the Microservices world, these Bounded contexts can be individual Microservices

Epic = Bounded Context (DDD)= Microservice = Pods (Kubernetes)

Now let us understand the best practices to write good user stories.

INVEST in Good Stories

• User Story should take a maximum of 3–5 person-days to complete the story. (From Analysis + Design + Deploy + Test + Fix + Re-Deploy)
• User Stories can be smaller from a few hours to 1–2 Person days.
• Each story can have 3–7 Acceptance criteria.
• Sprint backlog will be having 6–10 stories.
• If a story survives more than 1 sprint, then the story needs to break down into smaller stories.

What is a Minimum Viable Product?

An MVP must complete a user journey. Don't worry about how it's implemented. We saw that with Lean Startup. It connects multiple user stories and connects in a way the user is expected to travel.

Now let us look at the overall user Journey with Epics (Microservices), User Stories, Story Map and Minimum Viable Product, Sprint Cycle, multiple release plans, and Kanban-based release.

The following diagram shows

• 6 Epics (Microservices)
• Each Epic contains a collection of User Stories
• Story Map shows a typical User Journey
• Minimum Viable Product focused on getting the basic User Journey implemented.
• Two types of Release cycles are Scrum and Kanban.
• Scrum (R1 and R2) where all the user stories will be released as part of the Sprint.
• 2nd Release Type is Kanban where it’s possible to release an Individual User Story based on the Business Requirement.

Microservices are the building blocks of Cloud-Native Apps. So, what we looked at so far is how Design Thinking, Lean Startup, and Agile combined lay the foundation for building the Cloud Native Apps.
Have fun. 😊