June 22, 2018 12:38 am

Book Review: The Lean startup

Filed under: Agile,Business,Process Improvement,Project Management — ramsblog @ 12:38 am


The Lean Startup by Eric Ries is one of the significant books I have read in the recent past. Great tips and examples to learn processes for a start up. You have the Ideas, start rolling them the product. This book can be your tag along guide as you go through the process.

My understanding before reading this book was , it was geared for those geeks who want to start a new company and explore into various options to making their ideas transforming into cool products. However, As I went through reading each chapter, I was able to recall my day to day projects at work and apply some of those concepts. A start up company OR an established company but coming up with new products and features , this book would help in visualizing and developing those cool features faster and obtain feedback along the way.

This book is structured into 3 sections – Vision, Steer and Accelerate. A key take away about adopting the projects into a Lean fashion, is the amount of learning you have while developing that cool product or feature. Validated the learning and identify the moment of flying out with colors, or Pivot and improve the course.

LOFA – Leap of Faith Assumption – is a key in taking risks and getting into the venture – either in-house or through external VC funding, Execution, and last not but not the list Innovative Accounting for the investment of all the resources (Time, Money, Ideas, and any other raw materials  like expertise, technology, etc.,)

This book will walk you through Learning opportunities via Experimentation, LOFA leading to execution, defining MVP (Minimum viable product) , marketing, being flexible on Pivoting / Perseverance. These should go with some sort of Feedback in the so-called Build-Measure-Learn pattern.

Later part of the book takes you  through batching process, the efficiency / Effective way of batching work size, with simple examples and case studies. This chapter however, I think, is somewhat debatable. I sense there are some overlapping thoughts, contradictory statements between the types of batches appropriate. But however, I agree, it is contextual and depends on the project is appropriate to go batch process, and if so, the size, feature set, and the product.

There are numerous examples all through the book that would help to learn from others’ experience. If not anything, I would recommend you read all those examples provided across the book. Examples from Groupon, Facebook, Toyota, and several other companies included in the book. Fascinating examples to learn from.

One key take-away for troubleshooting the process or incidents. I also learned this from my little one a few years ago, of asking Why on every response. “5-Whys” is a technique described here, coined by Toyota Production process to identify the core root cause. “5” may not be a silver bullet or a golden rule, but use the depth as appropriate to the context.


June 17, 2008 12:05 am

Agile Project summit in Seattle…

Filed under: Agile,Events,Project Management — ramsblog @ 12:05 am

I just received an email about Agile summit. APLN summit is scheduled in Seattle for July 17 – 18th, 2008. Flyer can be downloaded from here and more details about APLN on this website

Technorati Tags:

March 6, 2008 5:59 pm

Agile Open Conference – NorthWest

Filed under: Agile,Events,Project Management — ramsblog @ 5:59 pm

One of a kind conference (Open-Space) where experienced Agile practitioners get together and discuss about various topics sharing their insights and experiences. A great way to learn from experiences others go through. It is going to be held in Seattle on March 18th and 19th. 

For more details, see here  [http://www.agileopennorthwest.org/]


Technorati Tags:

December 20, 2007 2:27 pm

Product management webinars online …

Filed under: Agile,Process Improvement,Productivity,Project Management — ramsblog @ 2:27 pm

There are several webinars both upcoming and an archive of past webinars available on Product management blog site here

 I was just going over a past presentation about productivity – getting more things done [flash presentation] — provides top 10 items that the presenter does in his daily experience. There are are many valuable presentations up available online.

May 24, 2007 11:05 pm

Team achievement and Team Credit

Filed under: Agile,Project Management,Quotes — ramsblog @ 11:05 pm

I recently noticed a quote below…

“There is no limit to what can be accomplished if it doesn’t matter who gets the credit.” -Ralph Waldo Emerson

soon after I read this, i started analyzing to understand further myself. I started to think – it is a great attitude. This is what I almost always believed in and I believed in Team effort and Unity. Specially, thinking about the project management and following different ways of project management, working with people around, and a mission – having a common goal makes more sense. I have been in teams where even though the common goal was set as xyz, but still, the team members had their own goals and literally it was self centric.

Alright, not that i am questioning this quote, but if I understand it right in team effort point of view, I still think TEAM must get the credit. It depends on teams, but I believe the Team credit is the biggest motivating factor. As I see, credit doesn’t matter only If there was no common goal / mission set by the TEAM – But once the team has the common goals to achieve, then there must be a credit to the team. It doesn’t have to be monetary benefit, and mostly it goes by the way the team members are rewarded.

April 30, 2007 12:52 am

Exploratory Testing and documentation…

Talking about Exploratory testing and the project management  [link] a few weeks ago, Pradeep from Bangalore, had shared a fable about TestTrimming or shortcuts. It is a good story of what it takes to bake a cake and how shortcuts would not provide a quality outcome.

From the fable’s example, it is agreed that the 3hrs of effort is what it takes to bake a cake and no shortcuts. However, 3hrs is an estimate that was given by the baker and he/she knows it takes taht time to complete. So, back to my ad-hoc testing – considering we have provided a similar estimate and what I referred in previous paragraph as Mar 15 – what is the level of confidence to say, I can be done by then. OR, does it mean, I won’t know about it until I am done. This is something I heard from someone working on SCRUM project model.

I have also come across few articles [link1][link2] while learning about the technique / approach for ET, and i have noted that the documentation or heuristics can be used along with FTT (Features to be Tested) docs to learn about the product. I also remember reading on Satisfice or somewhere else that the last few minutes of the ET session should be kept for reporting the bugs / issues etc. I was having a similar conversation with someone recently. So our conversation was, though having the reference materials like mentioned before, how about keeping a log for what was exactly tested or at least the scenarios touched upon during the session. We had mixed thoughts, given the time constraints for the project, on

  1. whether to be documented on those or not
  2. if documented, then to what extent? I understand it is relative comparison. so my answer was, we need to document at a higher level to an extent of the scenarios touched upon, for others to understand the areas touched, helpful pointers as appropriate etc. And it doesn’t have to be detailed to include the sample data, outcome of that data (in case the software resulted as expected) [again “as expected” could be like from a spec]
  3. why document that – because it ad-hoc and the bugs/issues will be reported anyway. –> it probably makes sense, but I probably have to disagree with this and I think it is always better to have some sort of documentation, even if it is a one liner as mentioned in #2 above – i understand there are chances of ambiguities if we start documenting things. Well again, we need to draw a line somewhere. I have also noticed a blog post by Pradeep on mixing Scripted and ET. This is another resource with good examples listed.

It looks like I am wandering around these thoughts on ET, agile, TDD, etc etc as I think about Agile project management.

So, your thoughts on ET and documentation? please share here in comments….


{tags: project management, agile , exploratory testing}

Blog at WordPress.com.