Top 5 blog posts of 2013 - AgileDevTest

Just a little recap, It's been nearly 11 months since I started the AgileDevTest Blog.  This knowledge sharing and learning journey has been wonderful for me and hope my posts are informative to you.  In case you are not satisfied with any of the blog posts, as always, please feel free to post your feedback either as a blog comment or you can also contact me directly in my G+ account.  

As we are approaching the end of 2013, I just wanted to share the top 2013 blog posts of AgileDevTest Blog.  So here we go with the list

5.  Free Ebook for Beginner Programmers - Programmer's Motivation for Beginners

This blog post is about my free Ebook "Programmer's Motivation for Beginners".  More about this on the given link.  This post received good welcome and is #5 in AgileDevTest blog 2013.

4.  Attitudes of a Great Software Developer

This was my very first blog post in my own words.  I had a sense of feeling that Developers needed to have certain attitude if they had to classify as Developers, this blog post throws some light on those thoughts.  This is one of my personal best and it's #4 in AgileDevTest blog 2013.

Agile, Agile, Agile. What is so different about Agile for Developers and Testers?

The word Agile has taken the software world by storm.  Agile has grown well past it's hype cycle.  People have got increasing awareness about Agile, however doubts still remain in several minds especially developers and testers.  So what is so different about Agile and how does it matter if you are a developer or a tester?

Fast Paced Environment

Typically Agile Environments are fast paced.  It doesn't mean that there will be no breathing space.  No.  That is not the case.  In good Agile environments, the outputs are faster.  It takes lesser time to deliver same features in a good Agile environment.

More focused results

The problem with many focus is that they try to do too many things at once.  And many a times, multitasking is counter productive.  That is both true for an individual or a project.  So Agile puts more emphasis on providing proper attention to the things that really matter.

Focus towards customer rather than technical easiness

Given a choice between easy for the customer vs easy for us, we almost take the latter option.  And that makes sense sometimes, but not always.  However in Agile Projects, customers are kings and if there is something that will be easier for the customer, we will do that even though it means that it might not be technically easy.  There are of course technically infeasible aspects but that is a different point altogether.

What Software Developers can learn from Sachin Tendulkar's marathon career?

A great career is about to end.  One filled with many many runs that even the best can only dream of.  Yes, we are talking about the one and only Sachin Tendulkar.  As he is retiring, I just thought of how much I learned by just watching him.  That's when I realized why not pass that learning to others as well or at least highlight what we can learn from him. 

 

This post is specifically dedicated to software developers.  But this can be applied for anyone in any field.

 

So what are the things that software developers can learn from this great guy?  Here we go with the list.

 

 

 

 

Passion for the game

One thing that is pretty to hard to beat this guy at a young age or even now is his passion for the game of cricket.  He used to bat, bat and bat without getting tired at the nets day in and day out.  He loved the game so much that he lived it. 

Similarly developers should be passionate about developing great software.  It is the passion that keeps a man going and work never looks like work if you are passionate about it.

 

Natural Talent

14 Code Refactoring smells you can easily sense and What you can do about it?

This post is specifically intended to Project Managers although developers and testers can also get reasonable inputs from this post.  Generally projects tend to accumulate a lot of technical debt over time if refactoring is not applied and if good coding practices are not followed.  It is imperative that as a Project Manager you should understand this and deal with it effectively.  This is especially true in an Agile Project, where there is constant delivery of features and you would be surprised how quickly code quality can take a beating in if proper measures are not taken.  So what are the signs you can observe that your project’s code needs refactoring and what you can do about it?

·         Team is taking more time than expected to deliver features

o    This is probably the number one smell that a Project Manager can look out for in a project.  As a Project Manager you sense that a certain feature should not take so much time, yet it takes that time.  You talk to the team and they often give you a detailed explanation of how much change the feature needs to undergo and how it affects other features.  That is one of the sure smell that indicates that the code needs refactoring

·         Plenty of bug fixes after delivery

o    On one end, the code delivery is being delayed and at another end, there will be a lot of bugs too after delivery.  If you have observed this, then it is a sure sign that your project’s code needs refactoring.

·         Build Quality is on a decreasing trend

o    This is one of the excellent smells that surely indicate the need for refactoring.  If we try to build on bad code, the code quality will get reduced and this trend continues till we attempt to put a stop to it.  If you observe this as a Project Manager, then you need to put a stop to it.

Common excuses a Developer makes when a feature doesn't work [And how to avoid them in the future]

I always feel that Developers should have an attitude for development, which I have detailed in the blog post Attitudes of a Great Software Developer.  But generally when it comes to issues, a lot of developers make excuses.  As long they are genuine, it is not a matter of concern however if it is really an Excuse, then it is a cause for concern for the entire team.  I am guilty of a few of those myself however when I saw the big picture, I rectified those and understood why people make those excuses and how we can avoid them in the future.  I am detailing a few in my below post.

1.  It works fine in my machine

Come on guys, this is the number one excuse that developers give.  We often have a feeling that testers or the customers have a magical computer which injects bugs into our code.  But that is far from true.

The only way to avoid this excuse is to be aware of the environments that are used for development, testing and production.  By being aware of those, the first thing you would probably ask is, what sort of configuration/environment it is and get more details about the issue and check if it is really a valid bug.  Another way to avoid this is to have a Continuous Integration environment, where with each and every code check-in, code is compiled and deployed in some test machines.

Image courtesy: cheatcc.com

How to improve agility of an Agile Team

Often as an Agile Project Manager or an Agile Scrum Master, your very first challenge is to improve the agility of teams.  Before we try to go to the core topic, we will try to define what is Agility?

Wikipedia defines Agility as

"Agility or nimbleness is the ability to change the body's position efficiently, and requires the integration of isolated movement skills using a combination of balance, coordination, speed, reflexes, strength, and endurance"

From the definition, it is quite clear that Agility is a function of lot of factors such as Balance, Coordination, Speed, Reflexes, Strength and Endurance.

So in this article, I will try to post my thoughts on how to improve Agility of a Team in my own words of course and out of my experience.

 

 

1.  Change their mindset

Agile is a lot about mindset.  Once someone is into that mindset, obviously he/she will contribute the best to the team's cause and thereby it will increase the speed and also the agility of the team.
 

2.  Change your mindset

Acknowledge the fact that you need a mental conditioning as much as the team.  First of all, try to understand what Agile is all about and how it benefits the different stakeholders in the teams.  Try to understand that Agile is not a miracle game and it takes time, proper execution, support from every team member and support from team as a whole to reap its benefits.

 

 

3.  Improve collaboration

Agile is lot about team working together to complete challenging tasks rather than several team members working in silos.  Emphasize the fact that Agile is a team game.  So Improve the collaboration among the team members, ask them to pair up for some problems and encourage good collaborative team work and make collaboration a habit.

Free E-Book - Programmer's Motivation for Beginners

Hello everyone

I am proud to present my first E-Book which I have compiled based on my experience in the Software industry.  This book contains valuable piece of information and learning that will be very useful to those who are starting out their careers and also some intermediates.  This is a very short E-Book (40 pages) and spans across these following chapters.

Chapter 1 – What I learnt from my first real working code

Chapter 2 - How to learn programming

Chapter 3 – Thoughtful quotes for  programmers

Test Like a Villain!!

Welcome to AgileDevTest.  In this post, I am trying to project a Villain's mindset and how it resonates with a Tester's mindset, of course in my own point of view.




Do you have any other points of view? Please let me know.  Comments and critiques welcome!

About the Author

Rajaraman Raghuraman has 8 years of experience in the Information Technology industry focusing on Product Development, R&D, Test Data Management and Automation Testing.  He has architected a TDM product from scratch and currently leads the TDM Product Development team in an IT MNC.  He is passionate about Agile Methodologies and is a huge fan of Product Development, Agile Development and Agile Testing.  He blogs at Test Data Management Blog & Agile Blog.  Connect with him on Google+

Agile is not for you IF

In my previous posts I have tried to put forward my points on What an Agile Project needs for success, 11 areas an Agile Project Manager needs to focus o... and Scrum meeting. Are you kidding me?

In this post I am going to describe in my own words and experiences that Agile is not for you if you are among the following category.

1.  If you are not willing to change your mindset and continue to work the same way, you did before

2.  If as a manager, you think people are resources

3.  If as a developer, you think your job is just to code by specifications

4.  If your organization is run by bureaucrats

5.  If your team is not mature enough to handle changes frequently

6.  If you want to deliver something fixed within a fixed time frame

7.  If you can't have customer or Product Owner inputs on a regular basis

8.  If you have fairly straightforward requirements

Scrum meeting. Are you kidding me?

Recently I was part of a "Daily Scrum Meeting" in a reputed product development company (I travelled to work with this company on a joint initiative, anyway that is not the point of this blog post).  I was really baffled at the way the meeting was happening, because there were several things that didn't go well during that meeting.  Being a huge fan of Agile and a committed practitioner, it was concerning that people were actually adopting it the wrong way.  I felt like asking to them "Is this a Scrum meeting? Are you guys kidding me?".   In this blog post, I am sharing some of the learning from the meeting were:

• Everyone on time

A Daily Scrum is a commitment to the entire team.  So everyone needs to be on time for the meeting.  Never forget your meeting etiquette. :)

• It's for everyone team

A Daily Scrum meeting is for the entire Scrum.  It is not just a subset of the people.  Agile focuses highly on team collaboration and it's high time teams understand that.

• Everyone present throughout

Intention of the daily stand up is to have the team members communicate, collaborate and the team should be knowing what each others are doing.  No one should leave a meeting in the middle.

Thought Leaders who disrupted the Software Industry

There is something in common among thought leaders.  Their thought innovations simply disrupt an existing paradigm.  Today we will see a few of those who really disrupted the Software Industry, be it in Development or Testing or Databases through their inventive and innovative thinking.

Kent Beck:

Kent Beck is the creator of the revolutionary ExtremeProgramming or XP as it is shortly called, along with 2 other notable thought leaders and improvisational Test DrivenDevelopment.  He is also the mastermind behing JUnit, the xUnit class of Unit Testing Frameworks.  These innovations eventually formed the basis for what we currently call Agile SoftwareDevelopment.

Martin Fowler:

If you don’t know him, then probably you are not in touch with the Software industry recently.  MartinFowler is a chief Scientist in Thoughtworks.  He is a highly reputed international speaker and is a guru who popularized Agile and NoSQL to a great extent.  He along with other thought leaders formed the Agile Manifesto.  Some of his notable writings include Evolutionary Design, Agile, ContinuousIntegration, ContinuousDelivery, NoSQL and Mobile and is a author of several best selling books.

Ward Cunningham:

He is one of the 3 inventors of the Extreme Programming.  Also a pioneer in Design Patterns, Extreme Programming and the Agile movement and one of the thought leaders who framed the Agile Manifesto.  He is also the inventor of the Wiki and the popular FITframework. 

Ron Jeffries:

He is also one of the 3 inventors of the Extreme Programming.  He is also the author of one of the best selling books “ExtremeProgramming Adventures in C#” where he wrote about his journey through XPing using a new programming language (C#).

James Bach:

James Bach is a revolutionary thought leader in the field of Software Testing.  He is most notable for his works on Exploratory Testing along with other thought leaders, Session Based Testing and Context Driven School ofTesting. 

Ken Schwaber and Dr. Jeff Sutherland:

Inventors of the ever so popular Scrum methodology in Agile, which revolutionized the way of working for teams and brought a new perspective to Agile Projects.  They are also the initial signers of the Agile Manifesto.  Ken Schwaber is also a founder of the Agile Alliance and Scrum.org.  He is also a book writer and has written on varioustopics in Scrum.

Michael Stonebraker:

A computer scientist and one of the fathers in the Database Management Systems.   He is the inventor of the RDBMS Ingres and Postgres.  He is a pioneer in the field of Big Data and is most notable for his work in Vertica and VoltDB.  He is also one of the criticsof the NoSQL movement.

There are a handful lot of other Thought leaders in the industry, but unfortunately we would not be able to cover everyone in this post.  Do you aspire to become a Thought Leader?  Who is your most favorite and respected Thought Leader?

About the Author

Rajaraman Raghuraman has nearly 8 years of experience in the Information Technology industry focusing on Product Development, R&D, Test Data Management and Automation Testing.  He has architected a TDM product from scratch and currently leads the TDM Product Development team in an IT MNC.  He is passionate about Agile Methodologies and is a huge fan of Product Development, Agile Development and Agile Testing.  He blogs at Test Data Management Blog & Agile Blog.  Connect with him on Google+

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.  

MVP - Minimum Viable Product strategy

Not all good ideas turn out into great products.  There are quite a few products that fail in the market due to a variety of reasons.  But does it stop us from investing in the Products? How do we find out if a Product is going to be a hit in the market?  And more importantly how do we find that out by investing the minimum amount possible.  Enter MVP - The Minimum Viable Product.

The concept of MVP is getting acceptance throughout in the area of Product Development.  It is a concept largely used by start ups.  And it will immensely help new product design and development in larger organizations.

What is an MVP?

Our objective with a Minimum Viable Product is to provide a mechanism for maximum learning about the target audience or the target market with the minimum effort.  Does it mean that we only ship 3 out of the 10 features that is required to hit the market at the earliest.  No.  The concept is beyond just the product features.  A Minimum Viable Product takes into account the Product idea, how it generates interest among the users, what features that the customers or the market really wants, demand for the product, etc.  It is a strategy that is used for learning about the customers early into the product life cycle, so that they can make the changes for the good.

Strategies for MVP

Software Design in the 21st Century - Martin Fowler

Great talk from Martin Fowler, focussing on 3 topics

1.  Schemaless design
2.  NoSQL and consistency
3.  Software Design



A must watch !!!

11 Reasons why products fail in the market

Not all the product ideas get transformed into actual products.  Only a few pass that stage and get to the market as a Product.  And there are even fewer products that are actually successful.  So what are the reasons why products fail in the market.  In this post I am outlining a few reasons in my practical experience which can lead to the failure of a product.

• Not having a directed product vision

• A product needs to have a vision, a roadmap at least at a high level.  Product roadmaps might change depending on the feedback from the customers / prospective customers / market research, but you need to have a product vision as you go along.

• Not enough investments for the products

• It is highly important that all the investments need to be made for the product development, testing, marketing, sales and brand promotion.  Without investments, the product will eventually die a slow death.

• Too late into the market

• A product needs to be in the market at the right time.  If the product is late into the market, there will be many competitors for the same market, and hence competition will be tough.  It is highly desirable for any product to have that First Mover advantage.

• Too early in the market

• In my previous point, I mentioned that a product needs to be in the market at the right time.  Even though being early in the market is a highly desirable option, however being too early in the market when there is no maturity in the market will obviously lower the chance of product success.

What an Agile Project needs for success

In my previous posts I explained about the Attitude of a Great Software Developer and Attitude of a Great Software Tester.  I am a huge fan of Agile methodologies.  I believe, if an Agile project needs to be successful, there are certain factors that will make it happen.

• Technical Craft
• The technical capabilities of a team should be of top quality, if you want to run a successful Agile Project.  An Agile project is actually run by the collective strengths of the individual team members and hence they need to be highly adept at their jobs.
• Team maturity
• This is one of the critical success factors for an Agile Project.  Not everyone is comfortable in working in an environment where there are lot of changes.  Hence the team members and the team as a whole should be highly mature enough to understand the realities and make quick yet thoughtful decisions
• Collaboration
• I cannot stress this point enough.  The entire team should collaborate within themselves and also with external stakeholders.  This is actually one step ahead of an important point Communication.  It emphasizes the fact that it is a complete team game.  A developer needs to collaborate with Product Owners, Testers and vice versa.
• Team Morale
• Agile methodologies put a high emphasis on the people who run the projects.  It is a given that, a team with high morale will produce better quality work and with more speed.  It is important that the team is

Attitudes of a Great Software Tester

In my previous post, I explained in my own words the "Attitude of a Great Software Developer".  This post will focus on the testers.  Developers and Testers are two great personalities that work literally in the opposite direction but towards a common goal of producing good quality software.  One deals with the making aspect of the software and other with the breaking aspect of the software.

In this post, I will share the attitudes that a Great Software Tester should have, in my own views.

Attitude #1 - I want to break that software at any cost

Make no mistake about it.  A tester's job is to find out bugs and in the process, make the software better and better as time progresses.  A bug is a tester's best friend.  So his/her primary intent is to break the software at any cost, find the loop holes, find that best friend of his one way or the other.  Whether it is through a systematic process of executing test cases or adhoc testing or exploratory testing, the objective is clear.

If you want to be a Great Tester, your attitude has to be to "Break the software at any cost and find out that BUG".

Attitude #2 - Ms. Great Developer, I challenge you that I can find bugs in your code.

I seriously doubt how many testers have this attitude.  

But if a person wants to be a Great Tester,

I want to run an Agile Project

This 2 part video clearly explains the challenges in running an "Agile Project".  Funny but very thoughful videos.

"I want to run an Agile Project" - Part 1




"I want to run an Agile Project" - Part 2

Attitudes of a Great Software Developer !!!

Software development is an art, not just a science.  You can learn all the technicalities of software development, but you need to be absolutely passionate about coding and perceive it as an art to be extremely good at it.  If you are one such person, I will introduce you to the journey of becoming a "Great Developer".  The objective of a Great Developer, as i name him/her is to make his/her art as beautiful as possible and make it the best.

In my own thoughts, I will share some attitudes which a great developer should have apart from the general expectations of being technically and analytically sound, understanding requirements in detail, good design skills, etc.

Image Courtesy: minfullychange.blogspot.com

 

Attitude #1 -  A bug is a question of my ability to write good code

Fixing bugs is part and parcel of a software developer's activities.  A bug is obviously the worst enemy of a Developer.  But how many developers think in the following lines while fixing the defects

• What I could have done to avoid this bug in the first place?
• How did I allow this bug to escape my eyes?
• OK, something wrong has happened this time.  How do I avoid the same mistake next time? What steps do I need to take?

Truth is very few developers think on those lines.

A  person willing to be a great developer should consider a bug as a threat to his position, as a threat to his credibility, as a threat to his programming skills.  That is the attitude that will make him/her a great developer.

Attitude #2 - Mr. Tester, I challenge you to find bugs in my code

How many developers have this attitude?  Many developers think that the job of the testers is to find bugs.  Yes.  Obviously, but that doesn't mean as developers, we can take bugs for granted.

A great developer or a person willing to be a great developer should