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.