Agile – there is a lot of talks going around in the technology market “Agile Development”, “Agile Methodology”, ” Agile Developer”, “Agile”, “Agile”,,,,, stop it man, let’s see what’s all the hype about. Agile is a different way of approaching the problem in software development and it’s about getting the project complete (get things done) in an efficient way and on time.
I know I’ve a very good experience in software development but definitely not in an Agile Development and this is a new topic creating hype in the market and off-course it’s one of the best development methodologies I have come to know off. So what’s next?, I want to be an Agile Developer too, not only because it’s hyped or it’s the best but it’s something new to me and I want to learn. We follow “SCRUM” in my company which is one of the agile development, hence, it’s an attempt to be the best in this process.
I got the chance to read a book on Agile Developer
, I recommend reading (“Practices of an Agile Developer” by Venkat Subramanian and Andy Hunt from a pragmatic bookshelf release – you can buy this from amazon) for a detail understanding. After reading the book, it’s clear and I have no doubt that I can say I am an Agile Developer.
I made a sheet, listing all the practices of an agile developer and check out daily, am I doing a right thing in SCRUM? Oh yeah, I use to mark it out and see what went wrong, that helped me to reach my goal effectively. I have listed those practices below which helped me become an Agile Developer, hope it helps you too.
Blame doesn’t fix bugs:
The first and important step in addressing a problem is to determine the root cause. Once you have found the problem and fix it, then make sure the problem does not happen again, ever. Instead of pointing fingers on others, point to possible solutions. This way it feels like you working together with the team, not blaming others and it’s the positive outcome that counts.
Criticize ideas, not people (keep it professional and not personal):
In the design discussion never let your emotions take over, because we are going to create a product which helps millions of people including us. So, when the team discusses the merits and possible drawbacks of your ideas, take it as a chance to perfect it and make sure you’re doing the best. Take pride in arriving at a solution rather than proving whose idea is better.
Keep up with changing technology and share:
You don’t have to become an expert at everything, but stay aware of where the industry is headed, and plan your projects accordingly. Learn the technologies and share the knowledge what you have with the team. This way you are helping the team to become stronger and stronger.
Raise the bar for you and your team:
Use sessions once a week to increase everyone’s knowledge and skills and help bring people together. Get the team excited about technologies or techniques that will benefit your project.
Learn the new; unlearn the old:
New technology feels a little scary. It feels like you have a lot to learn and you do. You can use your existing skills and habits as a base, not as a crutch. When learning a new technology unlearn any old habits that might hold you back. After all, there’s much more to a car than just a horseless carriage.
Keep asking why:
Accept the explanation you’ve been given. If you are told where the problem lies, that’s where you look. Don’t waste time chasing the ghosts. Don’t just accept what you’re told at face value. Keep questioning until you understand the root of the issue.
Tackle tasks before they bunch up:
Always run a quick review & unit test over a consistent iteration length and release. This way it feels like we are comfortable on the task we release.
A good design is a map; let it evolve:
Design points you in the right direction. It’s not the territory itself; Be sure to include the information on the implementations of methods and notes on their parameters. Don’t forget all the fields of the class. Never deviate from the design, no matter what you discover while writing code. This way it feels more comfortable on the implementation of the feature.
Choose technology based on need:
Determine your needs first, and then evaluate the use of technologies for those specific problems. Ask critical questions about the use of any technology, and answer them genuinely.
Integrate early, integrate often; Keep your project releasable at times:
Code integration is a major source of risk. To mitigate that risk, start integration early and continue to do it regularly. Ensure that the project is always compilable, runnable, tested, and ready to deploy at a moment’s notice. This way we have earned the trust from your boss :-).
Estimate based on real work:
Your estimate will change throughout the project they aren’t fixed. But you feel increasingly confident that you can forecast the amount accomplished with each iteration better and better. Your estimates improve over time.
Use automated unit tests:
Good unit tests warn you about problems immediately. Don’t make any design or code changes without solid unit tests in place. Use test driven development as a design tool. It will lead you to a more pragmatic and simpler design.
Measure how much work is left:
Measure the backlog of work to do. You feel comfortable that you know what has been done, what’s left and what your priorities are.
Write code to be clear; not clever:
You’ve probably seen a lot of code that’s hard to understand, that’s hard to maintain and (worst of all) has errors. What good is a piece of code if no one can understand how it works? Nah, when developing code, you should always choose readability over convenience. Express intentions clearly to the reader of the code. Unreadable code isn’t clever.
Comment to communicate:
Document code using well-chosen, meaningful names. Comments should help out when the code is too tangled to read. Explain exactly what the code is doing, line by line. Don’t worry about why; Use comments to describe its purpose and constraints. Don’t use commenting as a substitute for good code. You can read more here
Actively evaluate trade-offs:
Consider performance, convenience, productivity, cost and time to market. If performance is adequate, then focus on improving the other factors. Don’t complicate the design for the sake of perceived performance or elegance.
Keep classes focused and components small:
Incorporate patterns, principles, and technology only if you have a compelling reason to use them. Avoid the temptation to build large classes or components or miscellaneous classes. Always write a class/function on its own job, don’t take on another object’s or component’s job. Tell it what to do and stick to your own jobs.
Maintain a log of problems and their solutions:
Do you often get the problem in your web-app?, not able to figure how it happen?, maintaining a log of process will help you fix the issue soon. Part of fixing a problem is retaining details of the solution so you can find and apply it later.
Treat warnings as errors:
Checking in code with warnings is just as bad as checking in code with errors or code that fails its tests. No checked-in code should produce any warnings from the build tools.
Attack problems in isolation; Handle or propagate all exceptions:
Separate a problem area from its surroundings when working on it, especially in a large application. Stepping line by line through a massive code base is pretty scary. But the only way to debug a significant problem is to look at their entire system. All at once, after all, you don’t know where the problem may be, and that’s all the only way to find it.
Ah, that’s all, I’m an Agile Developer yooohoooo!. Keep it as a checklist and see how it helps you, I am sure you can be a better Agile Developer 🙂 too.