Book Review: The Lean startup

http://a.co/2IE9BCO

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.

http://a.co/2IE9BCO

You do know one song daddy!

It is often great to learn that we learn from toddlers. We had been to a local community celebration – Kannada sangha’s sanranti gathering – this afternoon. One of our neighbors sang a couple of songs. I had one of those songs several times before in my childhood and also later years. We were driving and starting humming that song. Being sheepish for yet not knowing the lyrics, I said – to my wife on passenger seat, “although I seem to know several songs – one or two liners – I wish I had known complete lyrics of at least one song. I need to learn the lyrics so i can hum a complete song.”

Now, from the back – on a child seat – our daughter chimed in – i thought she had fallen asleep, but looks like she was still alert thought about to fall asleep. we couldn’t here at the front and asked her to repeat – says: you know one song completely daddy – mudaakaraatha modakam [youtube video]. Well, we had both learned this song together a few months ago.

My wife chimed in – “look: she wants to encourage and uplift you to the best of her knowledge”

Certainly, it is interesting. When I thought about how and what most adults would have responded when I said, i didn’t know a single song completely, it would probably have been (a ) accept what i said (b) console in a different way (c ) some words that might make me feel much sorry about myself 🙂

On the other hand she didn’t want me to feel sorry for not knowing other songs, and rather uplift or encourage for knowing one so keep up learning others – not a big deal.

It is the matter of Attitude and how others centric that we get to in helping others grow.

To an extent it also follows (in terms of awareness and learn) what I just learned on Alan Page’s blog – about 5 orders of Ignorance – in the context of software development  – Links here – article about 5OI ; 5 orders of Ignorance

Is it true – helping others is better than self analysis….

I hve noticed in several instances that some individuals are great in their Creativity while working with other individuals compared to brainstorming for themselves. Some are great coaching compared to doing things for themselves. I remember i had shared a similar thought once before.

so is this true creativity goes exponentially with pair programming or XP, and the quality and productivity increases as opposed to having the individuals left for themselves, specially while troubleshooting issues. Be it a software application or planning for a project.

what do you think?

if so, what are the ways one can learn to leverage his/her own brain for troubleshooting in a better way? I don’t think it is the experience, if that was the case, they would not be able to contribute high while helping / coaching others.

Reporting Reporting Reporting…

How much time do you spend on your status report at what-ever-job-or-business-you-work-with?

Per day, per week, per fortnight, per month, per year?

What is the value add? Who is the audience? How often is it reviewed? How many of those reports are looked back?

When started few years ago, I was a report junkie where I wanted provide the information nitty-gritty activities that goes on. Try to gather some numbers from the tools, formulate the charts, make them colorful, provide the risks and potential mitigation plan, etc etc…

I know the reporting makes it more meaningful provided it has the relevant information, at the same time, we also need to think about the cost involved.

When you look at the Project Management Hierarchy there are several cross functional teams, several levels of management, several applications, and several people of course, and few leads. There are reporting requirement involved at each every level in some way or the other. If you each one is preparing a report towards the same project, where the common goal of every individual, every element involved in the project is towards the project deliverable (you may add any number of factors to it viz., quality, complete functionality, etc etc etc), then think about the amount of time each individual puts in to create that report. Well, most times the specification of what the report should convey might be lacking in many situations, when you do have the expected format or certain expectations, every individual need to adhere to it.

Let’s assume there are about 20 people involved in a project and his/her own skilled areas. each one spending about 30minutes for “so-called-report” –> that makes it to 600minutes of your project time went into reporting and this repeats every week – even if it is 20minutes per individual – translates it to 400 minutes – and that’s about 8 to 10 hours of work.

In my mind, we need to come up with Tools to do such mundane repetitive tasks like gathering the numbers, consolidating the issues etc. Let our human brains do creative work.

Agreed, specially talking about road blocks and attempting towards removing them from the project individuals is what the project management should be looking at. and that would help keep the project healthy, but it is interesting to see the amount of time most projects put into merely status reporting.

borrowing this book from the library to understand what the author has to say about project risk management.

What is your opinion about reporting and how much time do you think would a project spend on such activity?

Knowledge Management

I was at the SEASPIN presentation few days ago. The presenter Jeff Smith talked about  Knowledge Management and how it influences/impacts the organization. It was a great forum that we mostly discussed a lot on pros and cons. Listening to the audience there, Knowledge (information) management is not only an issue at the team level or an organization level or a company level, it appears to be at the industry wide. talking about this, there are gazillion number of tools and processes in place. There are practices and processes that get implemented and gradually disappears within a year or two.

certain teams try to consolidate all the documents in a single so-called “repository” and despite, documents are scattered everywhere. Have you been in a situation where you look for documents and find and search for them and still not able to locate those documents after hours and hours of search and finally create another copy. Well, at some point you would find duplicate documents around and not being able to make out the latest one. What would you do, would you merge them? would you review both the documents or would you judge on the latest modified date and keep the recent one? How do you even know that’s the legitimate valid document?

This kind of situation, in a way, turns into searching for the required information. Jeff puts this as “Search is a backup plan for a lack of Plan” –> I so agree with him, based on what we understand from the scenarios I described above. We end of searching for information when we fail finding at the known repositories and that boils down to lack of better planning in Information Architecture or Information Management.

It was a great insight overall. Thank you, Jeff.

SEI Webinar: Process Improvement on Dec 18

SEIs webinar titled “Process Improvement at the Edges” scheduled on Dec 18, 2008.

For free registration see here: https://www1.gotomeeting.com/register/941082132

Title: SEI Webinar Series: Process Improvement at the Edges

Date: Thursday, December 18, 2008

Time: 1:00 PM – 2:00 PM EST

 

Technorati Tags: Process Improvement,webinar

Agile Project summit in Seattle…

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: Agile Project Management

Software Quality…

280Group writes an article about “why Software still stinks here“. In this article the author says the product management is the key reason for why software fails. I like the way this article starts and pointing one of the key impediments as “being open for critical feedback and ideas“. I liked the way it was put across in one phrase as “this industry still so amused by its own opportunities” as an improvement factor.

I believe there are other factors to be accounted as well.

a. Strategy: Good strategy to drive the project management

b. being able to coach the teams and being transparent of what product management thinks of the end product and the teams knowing the exact same thing.

c. being open for feedback from the team – this has already been addressed in this article. additionally, most times the managements are firm on what they want and not really listen to the team though the management change the course (shift) when market changes. Why not the management listen to the internal team for what they have to say.

d. when it comes to “about buggy, inflexible and incomplete applications” –> irrespective of how the product management is, only the team can certify the quality gates and the entire team has to come up with the measures to comply with that. It is the team work and not just one product manager, I think.

I have been in the application development projects where the customers did not really know what they really really wanted, and I agree, it is our responsibility to help customers to define the features they really really want and omit the obsolete requirements. Agreed, product management plays a key role here, at the same time, I think, the entire engineering team should put themselves in customer shoes while designing the solution early on and not really blame the customers for not providing the requirements.

note: I am probably sounding a bit biased or defending here, but I am trying to see from a cursory look and from my own experience being in the industry.

 

Technorati Tags: Software Quality,Product Management

Agile Open Conference – NorthWest

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: Agile Project Management

Functional Specification – a Bible?

In Software development arena, I often hear people saying, “Functional Specification document is like a Bible for us.” Well, I tend to question this statement. It is too much ambiguous to me. What does a Bible mean? Does it mean the key source of information? (note: I am not pointing to the holy Bible). I asked if that is what they meant – whether as a key source of information for application development and testing. I heard “Yes – the information in this document is fairly technical in nature and derived from the Requirements Document. ”

Great – so that means, somebody wrote the Requirements as the understanding from the Business owners. The requirements were reviewed by the business owner and the representatives, and perhaps few end users have reviewed the requirements and passed along the feedback. Let’s assume requirements on paper are according to what end users have visualized. Note – requirements might not have all the prototypes and the exact screenshots to help their imagination.

So, now, Functional document is a subset of Requirements depending on the functional ownership of the piece of application. Requirements on the other hand, supposedly, the end to end solution, as what business is looking for. Now, comes the functional dev and test teams, looking at Functional document ” so called the key source” that provides the subset of the requirements. My question is, if the key developers and testers are not even reviewing the requirements, as to what Business wants, how would they be able to translate the piece of software into what business wants. At the end of the day, what we develop is for the end users to be efficient in what they do and not become frustrated of not having the feature they were looking for.

I was often countered, “why would you even want to look at the requirements document when we are deriving the information into Functional?” my answer was “a big picture“. As a developer, at times be blindfolded on 4 key points and forget the rest

1. Object in question or to be coded
2. What are the input parameters
3. What are the output parameters
4. what are the business rules (logic) go into this object

Well, that does not work for a testing individual to know just that, to perform his job. He needs to know more and beyond the vertical object to ensure many many factors impacting or influencing due to one vertical piece. This kind of information can be obtained :

• partly from the functional,
• partly from the requirements and
• mostly from the end users or the product owner or from the user surveys depending on who the end users are.
• Additionally, having the prototypes to the end users would definitely be a big bet.

Additionally, being involved in FS development and reviewing the Requirements at the same time and having the prototypes up-front, would potentially save a lot of cycle time at the later time and potentially reduce or eliminate any re-work due to mis-representation during the requirements process. We are all humans, at times what we draw on a piece of paper might be different when translated to the prototypes and users would see in a different angle when presented with at least the prototypes than doing a visio diagram or describing 5 pages for a little dialog box kind of UI.

I just noticed a post from Shrini about testing the Requirements Heuristics. Quite informative.

In summary, please, involve the business owner and the end users as part of the functional development and through the process till the end of the development/testing cycles. This helps the end users feel they are involved and will certainly be a lot of help to the dev/test teams as part of this process and at the same time, they get what they want and be accountable for what they have asked for since they were involved in design and decision process. At the end of the day, product is something that should help the end users to be effective in their activities and not hinder their productivity with a new piece of software application.

From the dev/test teams perspective, it is the quality output that we deliver to the end users / customers (note: the term quality output might be debatable, but let’s go with whatever you define quality as. this post doesn’t go into that level.)

(note: this post was not reviewed before posting to the blog)