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.

Working software over comprehensive documentation

You might have seen this in the Agile Manifesto.  What this means is that instead of hours and hours of documenting what we are going to do (Excessive planning and documentation), we will focus on developing the actual product or software. 

Think about it in this way, having a working software in 3 months (Even a very simple version) that the actual users can use is way better than writing very detailed requirement specifications, writing high level design documents, low level design documents, test plan documents, detailed test cases upfront lets say for 3 months.  The working software provides user feedback whereas the excessive documentation doesn't do that.

Another common misconception is that Agile = No documentation.  This is far from true.  What Agile recommends is that working software over comprehensive documentation.  So we will document whatever is really required or makes sense in the future but we are not going to waste time in documentation if we feel that it doesn't make sense in the future.  It is as simple as that.

User Stories instead of Detailed Specifications

Since the primary focus is on the users of the software, User Stories will be defined instead of the detailed Requirement specifications.  That makes it very simple for everyone, but its upto the developers and testers to understand more in detail about what user stories mean.  So instead of defining the software in terms of the actual screens and fields, we are actually trying to define what the users are going to do.

Way of estimating changes

Generally developers and testers are very familiar with estimating in number of hours.  We follow popular methods like Functional point estimation, Test script point estimation, etc.  However in Agile, we will be doing something very relative.  Usually in Scrum (One of the Agile Methodologies), we have a practice of story points based estimation, wherein we will estimate based on the effort required for the User Stories.  A popular way of estimation is Poker Estimation in Scrum.

No detailed planning for 6 months

Again the focus here is on working software instead of trying to do excessive planning for a long time.  Because in software development life cycle, things can change fairly quickly because business requirements change frequently.

Long term solutions instead of quick fixes

In Agile, we focus on long term solutions to problems instead of building quick fixes.  Occasionally we tend to do quick fixes, however we also think of a viable long term option.  We understand that short term fixes will create bigger problems later on, and hence we will mitigate that risk.

Focus on automation

One way we gain speed in Agile is by focussing on automation.  You can automate basically everything right from your Unit Testing Execution, Code building, Code deployment, Code analysis, Running all sorts of tests, etc.  The huge advantage of automation is that we can save a lot of redundant manual effort that can be used to better the quality of the product or software.

Process efficiency

In Agile, the focus will be more on improving the efficiency of the overall process being followed.  That means trying to automate anything that's worth automating.  That also means carefully inspecting what is going wrong, what is going right, etc. and try to make changes if something is not working.

More collaboration

The very nature of Agile Projects is on collaboration, whether it is with the customers or among the team members itself.  There should be no developer vs. tester battles. There should be no Project Manager Vs. Team battles.  In fact it should be the opposite.  Everyone should complement each other, so that they will collaborate and work towards a common goal.

Smaller increments

Problems with traditional development methodologies is that it tried to do too much at once.  So as we were trying to solve bigger and bigger problems, we were taking big steps.  But now with Agile, we will break down bigger problems into smaller ones and take smaller steps.  It is easier to attack smaller problems one at a time than solving a big problem at one shot.  So we develop and ship the product in smaller increments, typically a 2 week increment, but a completely working software.

Less ego, more productivity

When it comes to teams, ego is definitely a team spirit killer.  And with Agile focussing on collaboration and the people aspect of it, we will need to keep aside our egos and look at solving the problems at hand as a team thereby increasing the productivity of self and the entire team.

Ownership instead of blame games

If anything goes wrong, the team as a whole takes ownership instead of playing the finger pointing game.  That increases team morale and emphasizes the team to take ownership of the problems and the software.

It's about working as a Team rather than in silos

Generally in traditional teams, you tend to see people working in silos.  In Agile, the emphasis is again on team work rather than working on silos.  The advantage of not working in silos is that team members tend to support each other in case of trouble and tackle problems head on.

Do you think there are any points that I missed to mention here?  If you are a developer or a tester, what else do you think is different in Agile?  Please shoot out your comments.

If you found this post useful, please share it with your circles.  You can also stay updated with the latest blog post by submitting your email id to the right in the "Get Updates by Email" section.

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+