Power of the Startup Culture - Small or Big Organization

Everyone knows a thing or two about Startups.  Either they are involved in one or read about one.  The most important thing about the Startups and why it is so exciting is the culture within the startups.  And it is quite true that, even though rare, startup cultures can prevail even in large organizations.  But definitely not without the support of the management.  So that brings us to the question, what exactly is this startup culture and what are the exciting things that are associated with this so called startup culture.  In this article, I am going to point out few things that make together the startup culture.

• Passion
• One thing that you get a lot from people working in a startup or a startup setup (like a very small team in a large organization) is plenty of passion.  People are passionate about their work, their team, their product or their service, their organization, their managers, they are passionate about literally everything.
• Lots of energy
• The thing that passion brings to the table is the high energy, it almost feels like you have plenty of electricity, we will only need to utilize the energy in an effective way.
• Group & Individual Ownership
• People tend to take / have a lot of individual as well as collective ownership in a startup setup.  Every loss of the product/service/company is treated as their personal & team loss and they take collective responsibility and every victory is cherished as their personal and team victory.

Lessons Learnt in Product Development

Product development is an interesting activity.  It involves a lot of challenges and lot of learnings.  But over time, we get to learn a lot of crucial lessons.  In this post, I am going to share some of my learnings based on my experience in Product Development.

• Go for an MVP rather than a full blown product
• A product might require lot of changes according to the changes in the market.  Hence it is imperative that a product needs to be shipped as soon as possible to the customers to get their feedback.  But how do we ship our product in 3 months when the actual development takes around 2 years.  That's when a Minimum Viable Product Strategy will help.
• Assess what the market requires and prioritize that over the internal product roadmap
• A lot of times, we have fancy features or features that provide extra punch to the product.  Those can wait.  What really needs to go to the market quicker are the features what the market really requires at present, solves the problems at present.  It is like "A bird in hand is worth 2 in a bush".  Do not include features envisioned by us too early in the life cycle, they can wait until they are absolute killer features / selling points.
• If a product takes shape, increase the investments on the Product to take it to completion
• Typically things start small and then the product gains momentum in terms of popularity or demand and is seen as a value proposition.  Then it is time to increase the investments in the product to make it more robust, stable and to deliver it fast to the market.

Video - Testing in an Agile Environment by James Bach

A nice video about Testing in Agile Environment by James Bach.

Some key notes from the video:

Testers are like the headlights of a car.  Testers don't steer the product/project, they illuminate the status of the product to the different stakeholders

Some of the important things that a tester needs to do during a sprint planning phase

• Learn (Ask a lot of questions)
• Know about Testability
• Observability
• Controllability (control states, configurable)
• Simplicity - Some features can take longer to test than to develop - Alert the Dev and managers about this
• Going through spec and highlighting dodgy things

Other points:

• Testing directly on the developer machine (Shake n Bake) - a session for 90 minutes or lesser
• Try to test defects as soon as they are fixed, that's when the developers are still thinking about the defects.

To be aware of:

Automation - tendency to be biased towards automation, play with tools rather than testing

The art of debugging

In software, everyone faces issues almost daily.  We need to be highly equipped to solve those issues.  Not all problems are straightforward to find out and require a lot of debugging to be done.  Hence debugging skills is of prime importance.  I would like to reiterate that everything in software development is an art.  Similarly debugging is also an art.  In this post I will focus on how to debug a software problem.

• Understand the architecture
• The more the number of components in a system, the more complex it gets to solve an issue.  It is critical to understand the architecture of the software / the module in order to debug a problem.  Suppose your system has a client web browser and at the server side a web server and a database server.  What if this setup is required to be able to work through a VPN connection? And you get an error in your web server mentioning that you "Could not connect to the database server", where do you think the problem might be.  The problem might be anywhere.  Hence it is very important to understand the architecture if you want to solve the problem quickly.
• Analyze the entire picture
• Once you get the entire picture, analyze the entire picture and try to see where the symptoms are lying.  I refer symptoms here because whatever you see is only a symptom, we need to trace to the problem in order to solve it.
• From the symptom, try to trace the problem
• Many problems tend to have more than one symptom, look out for those and try to get those hints.  In our example, "Could not connect to the database" is a symptom.  The problem might be due to various reasons.

MongoDB Schema Design - How to think Non-Relational

A nice video about MongoDB schema design.  To all who are new to MongoDB, MongoDB is a leading NoSQL document oriented database.  A table in RDBMS can be contrasted to a Collection in MongoDB, and a row in RDBMS table corresponds to a JSON document in MongoDB.

Key Points:

• MongoDB introduction
• Comarison of concepts of MongoDB Vs Traditional RDBMS
• Schema Evolution
• How to Model 1-Many and Many-Many relationships in Mongo
• Queries and Indexes

Introduction to NoSQL - Martin Fowler

Excellent video about Introduction to NoSQL by Martin Fowler.

Main Theme:

• History of NoSQL
• Families of NoSQL
• Key Value Database
• Document Oriented Database
• Graph Database
• NoSQL and Consistency
• NoSQL Usage

Enjoy this video !! Very informative !!

11 areas an Agile Project Manager needs to focus on

In my previous posts I focused on the Attitudes of a Great Software Developer and the Attitudes of a Great Software Tester.  

An Agile project's success also depends a lot on the Agile Project Manager.  The decisions he takes and the emphasis he provides on certain areas will pave the way for a successful Agile Project.  In this post, I provide some key points that an Agile Project Manager should focus on, for the betterment of an Agile Project

• Employee hiring
• First and foremost, an Agile Project Manager needs to hire the right people for the project.  Apart from the technical skills and non-technical skills required of Agile teams, it is imperative that the chosen candidates adopt to the Agile practices and are themselves Agile.
• Technical and Non-technical grooming
• Once into the project, the candidates needs to be groomed to meet the project needs and also grow further.
• Employee motivation
• I always believed that Employee motivation is one of the Critical Success Factor of an Agile Project, for that matter any project.  Motivated employees can do wonders if provided with the right environment.  Motivated employees go that extra mile to achieve the common goals.  Hence an Agile Project Manager needs to put high emphasis on this point.
• Engineering Practices
• There are a lot of engineering practices that make an Agile project successful.  An Agile Project Manager should focus on putting the right Engineering Practices to place. He/She should not forget that there is an overhead in following certain practices, but once fully functional, they start to provide high returns on the investment.  For ex. following Automated Unit tests and TDD can be very difficult to start with, but over time, developers get into that practice and the results start to follow.