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+