0 Comments

One of the key foundations of Startups is to be Agile.

Being able to experiment without time and location restrictions is awesome. With the Lean Startup gaining mainstream adoption, it becomes important for the engineering team to have the skills and processes that allow experiments on software MVP.

Here is where Git Hub Flow helps a lot. Having the ability to branch off from Master and work on feature branches is a very powerful way to experiment, demo, discard or improve the feature.

In my recent project, for Indian Cinema UK, an idea would strike while commuting by train. I would pull out my PC and code off by branching off. A one point I had 3 feature branches and switching between them at will using Visual Studio is super cool.

The biggest advantage though is the change in mind shift towards “Self-Permission to fail”. This is normally hard to come to terms for a developer working in an enterprise setup where the mentality is to not disrupt the status quo. Writing throw-away code is an important skill needed if one has to consider themselves as a “Full Stack Product Person”.

So, in summary, why adopt Git Hub Flow?

  1. Freedom (from time and location) to experiment
  2. Self-Permission to fail
  3. Change to throw-away mind shift (a mini build-measure-learn attitude)

0 Comments

The Lean Startup Circle of London organise a book club every month where everyone reads a book and shares their thought or asks questions about the content of the book.

This time it was at the http://www.launchLabs.co.uk, an incubator with a twist. They are a registered charity and support entrepreneurial activity for the needy like single mums, on income support etc.

We discussed the book “Lean UX” which is part of the Lean Series of book

We all agreed that the title of the book might be misleading but I emphasised that the book is not a prescriptive guide unlike “Running Lean”. Instead, only one of the foundations of Lean UX is the “Lean Startup”. The other two being “Design Thinking” and “Agile Methodologies”.

The most useful bits for me was the list of all the principles:

  • Cross-Functional Teams
  • Small, Dedicated, Colocated
  • Progress = Outcomes, Not Output
  • Problem-Focused Teams
  • Removing Waste
  • Small Batch Size
  • Continuous Discovery
  • Get Out Of Building: The New User-Centricity
  • Shared Understanding
  • Anti-Pattern: Rockstars, Gurus, and Ninjas
  • Externalising Your Work
  • Making over Analysis
  • Learning over Growth
  • Permission to Fail
  • Getting out of the Deliverables Business

Essentially, the rest of the book is mostly about applying these principles.

Ultimately, the book says “Our goal is not to create a deliverable, it’s to change something in the world – to create an outcome”

The next Lean Book Club is going to discuss the book “The Lean Enterprise” which is not to be confused with the yet to be published “Lean Enterprise