Monday, 20 January 2014

Biggest hindrances to being agile

I often wonder how projects fail to be agile enough even though the team consists of talented team members.  So today I am planning to summarize few points that are the biggest hindrances to being agile in a team based environment.

1.  Laziness / Procrastination

I think this is by far the number one hindrance to being agile.  This habit by individuals will result in a gap that widens with each work that is being delayed.  Let me explain this a bit better.  If you are part of a QA team, your responsibilities will primarily include testing of your module perfectly.  Obviously everyone will do that.  But automating the current testing will act as a regression suite for your future needs.  How many of you would do that if automation is not mandated in your process?  The answer is not all.  

So the laziness / Procrastination sets in and the gap widens with each delayed item.  So unless automation is mandated, it will not be implemented by everyone.  So the Agile Definition of Done should include all these nitty and gritty details that makes the entire process more agile.

2.  Lack of understanding

Not everyone is comfortable with Agile concepts and the lack of understanding of Agile has a direct impact on the team performance.  No Agile is almost always better than bad Agile.  For example, trying to be Agile without giving importance

3.  Lack of engineering mindset

If you lack the engineering mindset, you will not give adequate importance to day to day efficiency improvements.  For example, automating a setup or automating an installation for testing can't be done if the focus is not given on the engineering part.

Image Courtesy:

4.  Comfort Zone

Everyone likes certainty and look forward to a comfort zone.  Once in that comfort zone, they don't try to come out of it as it is tried and tested.  But the whole concept of Agile is to improve continuously, which means you have to come out of your comfort zone and try out newer things or to make that extra effort to make things better.

So it might mean improving your process day by day, focussing lot on automation, refining of the user stories, changing management thinking and team thinking on Agile and even completely restructuring the team if required.  

5.  Short Term thinking

Let me give a typical example.  Let's assume we have an installation process for our application and it takes approximately 2 hours for completion.  Let's assume we need to test it almost daily assuming there is a daily build process in place.  So let's assume you wish to automate it, but you don't because it takes around 3 days to automate it completely.  Now you lose 2 hrs * 10 = 20 hours per sprint and you can't test it until your installation is over.  So let's assume it affects a test team of 4 members.  

Now we are literally wasting 80 hours per sprint whereas automation would take just 24 hours on the whole.  So does it make sense to waste 80 hours per sprint till the product release or to spend 96 hours to completely automate the process which obviously save you plenty of hours from the forthcoming sprints.  But many people think short term and forget the long term benefits.  This is one of the biggest hindrances to being agile.  As always it is always the small waste that accumulates quickly especially when it is repeated over and over.

6.  Ego clashes

There might be ego clashes within the team and that can have a drastic effect on the team morale and hence the agility of the team.  It is often forgotten that Agile is first of run by the people and if people are not motivated properly and there are ego clashes within the team to be resolved, then it makes sense to tackle those issues head on and solve them before even trying to do anything else.

Are there any other major hindrances to being Agile as a team?  Please post your comments.

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  AgileDevTest Blog.  He is also the author of an Ebook "Programmer's Motivation for Beginners".  Connect with him on Google+

1 comment:

  1. Reducing the dev/test barrier is also crucial. Dev and Test teams shouldn't function as separate entities but as a team!