Lean Startup: Reduce time to market time & cost.

What is a Lean Startup?

Definition from Eric Ries, Founder of Lean Startup Movement is simple and concise.

“A Human institution designed to create new products and services under conditions of extreme uncertainty. Nothing to do with size of the company, sector of the economy or industry”
                                                                                         - Eric Ries, Founder of Lean Startup Movement.

"Lean Startup" is a system for developing a business or product in the most efficient way possible to reduce the risk of failure.

It is an approach for launching businesses and products that treats all product and business ideas as assumptions (or hypotheses) that must be validated by rapid experimentation in the marketplace.  The approach relies on scientific experimentation, iterative product releases, and customer’s feedback to generate validated learning.

If you need some more info hop to http://theleanstartup.com/

So now that we have some context into Lean Startup and if you are planning to launch a new technology product or are worried about time to market on your existing products, I would like to share an interesting case study how Lean Startup helped a product launch:

- Reduce time to market by 40%
- Reduce cost by 32%.
- Improved Quality by 55%
- Improved Business value by 40%

This Webinar is a walk-through of a "Live Product" built using Lean Startup & MVP approach that proves quantitative gain in time, cost quality & business value.

Webinar - Lean Startup: Reduce 40% go-to-market time & cost on your next product launch

This Webinar is a walk-through of a "Live Product" built using Lean Startup & MVP approach that proves quantitative gain in time, cost quality & business value.

The webinar would focus on the following topics:
- Concerns while new product development & How Lean Startup addresses these questions / challenges
- What is Lean Startup
- Lean Startup vs Traditional Approach
- Innovation and speed through MVP and Continuous deployment
- Aligning Product Launch, Marketing and Sales in Lean Startup approach
- Introducing Customer Engagement in the product life cycle
- Reduce time & cost by almost 40%
- Increase product quality and business value by 50%
- Case study - showcasing Lean startup benefits
- How Lean Startup can be applied in Enterprises

Project Managers FAQ's on Agile

Project managers adapting Agile have a series of questions about Agile ways of working. This is my attempt to list and answer a few.

Can we measure earned value in Scrum ?

Earned Value (EV) is a metric which answers the question: "What did we get for the money we spent?". We could relate this in scrum as a measure of stories done vs. the original sprint commitment expressed as a percentage.

Using the EV leads to an outcome of success or failure(i.e if >75% team succeeds the sprint, less than that the team fails). This is often misused because if pushed, the team will tend to either under commit or over estimate tasks.

EV can be put to use in a scrum environment if required but we should be careful to not push the team to meet a certain percentage and ensure term "failure"  is never used.

How do I measure project progress?

Project progress is measured using a release burn down chart. A release burn down chart is a graph which visualizes total points remaining for the release at the end of each sprint.

Is there a Work Breakdown Structure(WBS) in Agile
PMBOK definition of WBS is "a deliverable-oriented hierarchical decomposition of work to be executed by the project team to accomplish the project objectives and create the required deliverables". WBS is based on all the activities required to be accomplished in the project (e.g., requirements definition document, design specification document).

In Agile all work is organized as end user functionality refereed  to as user stories. Each user story represents work to deliver the increment of functionality and add business value.

During planning, agile development is inclined to a feature breakdown structure (FBS) approach instead of the work breakdown structure (WBS). Feature breakdown structures are advantageous for a few reasons:

- Help with communication between the customer and the development team in terms both can understand.
- Allow customer to prioritize the work to be done based on business value.
- Enable work tracking against the actual business value produced.


There are a lot more question than what I have listed. I will leave this blog here and would would like to hear from readers on the questions your encountered and learn from your experiences.

Please share your experiences and comments.

Retrospective for a distributed team.

I have been conducting retrospectives for quite some time now have been always looking at exploring ways to get better at them. In this blog I would like share my experience of conducting a retrospective with a scrum team which was geographically distributed. This is my way of conducting retrospectives which has brought me some success and not necessarily the right way. Please feel free to comment and suggest areas of improvements.

My retrospectives are heavily influenced by Esther Derby & Dian Larsen's book Agile Retrospectives: Making Good Teams Great and have always followed the suggested five stage process of conducting retrospectives.

- Setting the stage.
- Date gathering.
- Decide what to do.
- Close retrospective.
- Retrospect the retrospective.

I am a strong believer in the above steps of retrospective and have experienced the importance of the steps crucial for reaping all the benefits of a retrospective.

With a team distributed geographical it is best to hold the retrospective over a video conference. If that is not a option then the alternative which can be easily put to use is have a set of high quality web cams setup at both the locations over skype or other social video chat facilities easily available. I use the video chat software's for visuals only and rely on phones for voice to keep away bandwidth related problems.

Setting the stage
One of the very obvious fears people have about retrospectives is that the ritual will become a negative blame game session. If it does then then it will not contribute to any learning. The key to a constructive retrospective is assuring that all the participants adhere to the retrospective prime directive:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

A slide shared across sites using the prime directive seemed sufficient.

Data Gathering

- What went well ?
- What did not go well ?
- What can we improve ?

The above three questions form the crux of a retrospective. Each questions is put forth and the team then discusses, agrees and lists the events in relation to the above questions. I have used a shared excel workbook to capture the events across locations.

Apart from this I also like to capture the sprint mood:

If this sprint was human what would it feel ?
- Happy :-)
- Disappointed :-|
- Sad :-(

I use outlook voting button to capture the sprint mood just before the retrospective starts.

Decide what to do

Having captured events and ensured everyone in the team has had a chance to speak is an achievement in it self. With limited time available the next challenge is to choose items for improvement in the next sprint. I always suggest the team to 1-2 or a maximum of three items for improvement in the next sprint to avoid an overload.

How do we decide in a distributed team ?
Well voting with dots is the best way to do it in a collocated team. I case of a distributed team I would capture the votes on a excel sheet. You can allocate 5 votes for each team member, they could then use the votes as they like on the events listed. Team members have the options to place one or more votes for an event. Once every one has had the chance to vote you can then easily identify the items which need immediate attention and seek volunteer pairs to take actions on the improvement areas. I am suggesting a pair takes ownership to enable better collaboration within the team.

Close Retrospective.
I like to close retrospective with a thank you note to the team and also give an opportunity to any one in the team including PO if present to speak.

Retrospect on the retrospective.
Continuous improvement is the essence of being Agile and retrospectives also need improvement, spending a few minutes to discuss how your retrospectives can further improve will enable you to gather feedback and discuss ways to make your retrospectives better.