Agile and TDD: It may not be what you think.

I am an Agile developer. I have had many many discussions with people who are not working on Agile and TDD or are new in Agile and TDD. Also People who hate Agile and TDD.

The most important thing that has occurred to me is that people (including me sometimes) has their own theory of Agile and TDD and have their own concepts. Very few people have put a good amount of effort to understand what is Agile and how it can help you to have a good product on Time!

First of all if you are really interested in working in Agile or want to have detail knowledge of Agile and TDD I would recommend few books by some great people:

When I started working on Agile and TDD. I hated it. I was like why the hell I should have discussions and why the hell I should write Test case. I am not a tester. If my company can't trust my decisions and need a team discussion or a pair discussion I can't work for them. They have to trust my knowledge and experience.

I have seen similar kind of thoughts in other's minds as well. Even if It hurts our ego or respect all of them are true. No body is perfect and nobody knows everything. Single person can not invent everything. If you want to work in Agile you have to accept it and you have to be ready for open discussions,  arguments. All this is acceptable if we can produce a good product after all this. But if we do not discuss and keep faith in the heart that whatever I am doing is the best. Most of times We are wrong!

Let's go through them one by one and see the advantages of these things and some best practices that I have learnt:

Open discussions

In one of my company we had a Guy who will call a team meeting for every design decision he has to take. We were really irritated by all this. Can you imagine you are working through some concept of ThreadLocal class of Java and somebody says, "Hey!! can we have a meeting on Where to display this button on the Settings page!". I know it sounds crap. But actually it's not. We have realized it many times. Suppose somebody else is also planning to put some other link or search box or any button at the same place and what if he has already got approval from the business team (The best part is no body else knows about it.). If team will not discuss about each and every single feature they will be repeating things and changing stuff all the time. In some cases may be fighting on the places!! So discussion is very important.

Best Practices I have used:

      • Blow the whistle: Imagine you have release in a week( or like Facebook who pushes a production release every day!) and you are stuck in a problem. You are trying hard but not able to find a solution. In Agile world you should blow the whistle. Which means you should immediately gather your team and discuss your problem. If they will not be able to find the solution at least they will be able to suggest something. Do not stop yourself thinking that problem is very small and teammates will see you as a Fool. Problem may be small but the solution you will write may have big impacts. So blow the whistle in bad times.
      • Stand Up on Story board: This is time taking but very helpful during initial days(or during whole release) of your project. Having a stand up or status update in front of Story board helps you not to miss anything you are doing! Generally in normal stand-up people tend to forget some issues of features they have worked on. Also it will help team understand whether they are working on the priority things or not. Having a big picture of things undergoing in the project helps everybody.
      •  Business people are not Stupid: There is one most important thing related to Open discussions. Do not assume that business people are stupid and won't understand technical things. If you can make them part of your discussion. It will help you in two ways. First one is people will try to simplify things while explaining as they will think business people will not understand technical thing and technical people will actually understand how this piece of code will be used in real world.
      • Retrospective: This is the best part of Open culture. Weekly you should have retrospectives within your team or company level in case company has small number of people. Here team look at what went well in the week, what was bad and issues team saw in that week and what are the plans and solutions for next week. This is fun and off-course useful to decide things on priority for next week.
      •  Tech Hurdle:  This meeting belongs to all the developers. You don't need any business people or any tester in this. Because here you will talk any issue you are facing related to programming language or pattern team is using or coding conventions etc. This is very important part as you can solve your problems in quick time. It may look like first point but this is just for technical issues nothing else.

Writing Test case

Don't remember how many arguments I had about this. People think it takes time to write test case which is actually a wastage. They feel instead of writing test cases why not hire good developer who can write bug less code. But we all know it's not possible and it will never be(Even with TDD!!). But from my experience I can tell you that practicing TDD will reduce number of bugs and also will improve your code quality if you go through the process of "Red Green Re-factor". Now one big misconception is you have to write test for every single method you write. It's not true. You have to write a test only for features that you feel are complex and probability of bugs is more.

I hope you all know Kent Beck. A great author of so many great books and JUnit framework. Read what he says in one of his comment on StackOverFlow 

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it. I do tend to make sense of test errors, so I'm extra careful when I have logic with complicated conditionals. When coding on a team, I modify my strategy to carefully test code that we, collectively, tend to get wrong. Different people will have different testing strategies based on this philosophy, but that seems reasonable to me given the immature state of understanding of how tests can best fit into the inner loop of coding. Ten or twenty years from now we'll likely have a more universal theory of which tests to write, which tests not to write, and how to tell the difference. In the meantime, experimentation seems in order." Writing Unit tests, Integration tests and even testing the JavaScript with Jasmin.js or testing webpages flow with tools like Selenium is very important and helps you in long term.

Another advantage is New Joiner is not a problem anymore. If you have tests for your product. You are not worried that some new joiner will do something unexpected in the code and break some feature before going to production. Also Unit tests help new joiner to understand the feature in better and simple way.

Best Practices I have used:

 

        • Pair Programming: Pairing it self is a big topic but we will not go into depth of this. Generally in TDD one developer writes the test and other one writes the implementation. This is a good practice.                                          This is very very hard thing to do in most of the companies. Because business will think they are paying double for one feature. But this is not completely true and you don't have to program in pair all the time.                                      I will suggest when you are implementing a new feature and trying to decide what domain objects or what interfaces you want to have It will be great if you have a pair.                                                                                              Another important part is in Pair programming you rotate pairs so that everybody gets a chance to pair with each other. I like rotating weekly but some teams rotate after feature is done or similar to this.                                   I will be writing another blog entry on Pair Programming.                            Pair Programming helps in couple of things:                                                         
          1.  You share different ideas.
          2. Every single line of code you write is reviewed automatically
          3.  You exchange knowledge of programming languages when you tell each other different ways to do some logic.
          4.  You are not alone anymore to take a blame :P (We will talk about blames and credits later)
          5.  By rotating pair you create a great relationship between team members and new people learn more.


        • Use Some great tools: This is open source world and some great tools are available in the market for testing and analysis. Use them but before that review them for sure. We will talk more about tools.



 Defining cost

This is most useful thing to do for both developers and business people. Before Agile, developers were not involved in product cost and all those discussions. Some manager will come and tell them "Hey do this in 5 hours!". Then developers will curse him while having coffee and think why the hell they are doing programming. It's fun to sell Starbucks coffee ;).

But in Agile,  developers are involved in the discussions related to cost of a feature and number hours it will take. They get a chance to explain business people reason behind that. This kind of communication improves relationship between business people and developers.

Best Practices:

        • Generally tools like Jira have feature to define number of hours to each story or bug. Business can allocate for example 200 hours to a release and then developers have to estimate different stories and bugs they can do in that release. By doing this both have clear idea that what is going on and what customer should expect out of this release.



More on Agile......

These things may sound silly in the beginning but at the end you will see that there is a lot of value in all this. There are some more best practices you can follow:

        •  There is no "I" in Agile. So many people who like to create dependency in the projects and try to be "God Father" (Read More on this..) will never like this approach. But it's true and good for the team. You keep sharing your knowledge. Credit is for team and Blame is for team not for an individual.
        •  Show demo to customer on weekly basis. When I say customer that means actual users. If it's not possible try to find some of them. I am sure they will be very happy.
        •  User testing is very important hire some common people for 1 hour and ask him to use your tool. Do not explain him any feature or anything. It will be great if you can find someone who has used similar tool in the past.
        •  Continues integration is very important. Ask your programmer to commit frequently so that you know st very early stage is something is going wrong to breaking any feature.
        • Use great tools like Jenkins for continues integration, Jira for project tracking etc. Bugzilla for bug tracking.



There is so much in Agile that can help you to create a great product on time and keep your customers happy. I will add more in upcoming blogs and may be I will try to go in depth of each of these topics. I welcome any suggestions or if anyone has anything to add. I believe I have done my best to explain things. But I would love to hear opinions. Thanks and keep an eye on blog for more stuff on Agile.

Share on : Twitter, Facebook or Google+