10 Tips for programmers in agile development team

If you face few challenges as a programmer in an agile project you should try to convince your team, scrum master and product owner (or manager if there is a manager) about few practices which may make your life easy and can help project.

Note: This post is not for architects, managers and experts. It is intended to developers who are new to this discipline.

Challenges faced by some programmers

One line story

Stories are one liners "As a user I want to use online banking". Many among us will jump start commenting: "this is not a story at right level". May be this is a wrong example but in other domains it may happen. Why? Because people know less about the domain so they look at the things at system level and story is about building a system. Story should be about feature of that system (which means system should be divided into different features. Grade 6 lessons you must be thinking but we often miss this grade 6 lesson too). You don't have detail and you start building with your own assumptions and those assumptions become wrong at the end so the implementation becomes wrong and hence you have bugs.

Jump to code

In some cases there is no analysis or design and we assume our code is our specification. Even if code is my specification, I should have thought about how system should be built from different parts and pieces. How the pieces will fit together so that they should not create problem later.

Eclipse or Visual Studio IDE is open in front of me, I have to write code in the IDE. When should I think about above? I have not left any room for that thinking, analysis, design. I am doing an agile project and there is no upfront design or architecture in agile. So I have only one option left: Take one liner story "As a user I was to do online banking" and open IDE to code. During declaration of variables I will get an analysed system and during writing method signature I will have my design (automatically without thinking it will be thrown out by IDE).

Obviously above is wrong. Then? What your agile coach said? When you do anything to avoid above situation during that 2 week sprint or before that?

Great architects are busy with great agile gurus to discuss whether

a. architecture should be defined prior to start of an agile development work( project) and once solution design is available implementation is done with scrum or

b. solution design itself is a zero sprint or

c. it can be taken up as a spike within the sprint.

Let them debate and come to a conclusion but for the time being try following tips I have received from some practicing developers:

Tips for developers in agile project

Put your analysis of the story

You can use a template in Gitlab (or any other place where you have your story) to have story description and analysis part Or you can put few points of analysis in the description or comments section of the story.

Put your solution (design) of the story

• You can use a section of the description or comments section.
• It can be a document/report coming out of a spike or a study which is attached to the Gitlab Issue or Jira Issue
• Sharing your understanding of the solution (which is kind of informal design) is important so that you discover important aspects during defining this solution and others should know what did you understand

This way any wrong perception or understanding may be corrected very early by PO or Architect compared to very late when you implement it based on your understanding but other discover after implementation

Design and coding best practices

• Follow design principles like re-usability, adaptability, lose coupling simplicity related design and coding practices
• Please refer to : GRASP, DRY, SOLID, YAGNI etc and where to use, why to use, how to implement it?
• Design and code for quality (performance, security, robustness, changeability, transferability). Adopt design and coding practices which help achieving these quality goals.

Test first approach

• Always think about how to test this feature before developing it
• Don’t forget to adopt automatic unit testing
• Ensure test coverage as per project requirements and standards set (for example between 90 to 100%)

Continuous integration delivery and deployment

Whatever is claimed as benefit of agile or incremental development can't be achieved without automation, automatic integration and tools. To fail early you need to code, compile, test, deploy from day 1. Without automation how is it possible?

• Implement CICD with standard automation tools
• Include build, unit test, security scanning, code analysis, deployment steps as part of your CICD pipeline from day 1
• There should be threshold values defined for pipeline to fail if one of the stage is not up to the defined level (for example is coverage is less than 90% the stage should fail and the pipeline )
• Reports of coverage, static code analysis should be available to all. They are not for looking at the time of release and fixing all together. Corrective actions based on these reports should happen for every code merge.

Code repository, version control and standard CI practices

Repository can help streamlining everything

Gitlab kind of systems can be one stop shop for all the needs and may provide requirements handling (Gitlab issues), backlog management, Code repo, version control, manual code review, CICD and much more.

Incremental development

• Build small features , which have value for the end user
• Develop in feature branch, small and frequent commits
• Every merge request to be reviewed by a peer or tech lead before merging feature branch
• Try to adopt weekly demo by end of the week of whatever is developed. Develop what can be demonstrated in a week’s time

Clean code

If you have worked on your analysis and solution part well your code should be fine but

• Take care of clean coding practices, avoid pitfalls and anti-patterns (please refer to coding best practices of related technology area)
• Look for code smell in the code and mark it for fixing.
• Adhere to design and design principles while implementing

Risk identification and adopting strategies

It is responsibility of each team member to identify, foresee technical and other risks. Not only report risks but also find and implement strategies through design and code to avoid those risks

Find out the right reference

To understand above, lots of reading is required

• Learn right engineering practices and learn how to adopt them. Why and how part is after the basic Wikipedia definition.
• Refer to authentic references of engineering principles, random blogs and videos may have partial information so refer to standards, try to find out what is the standard related to it, why this should be referred to as standard
• There are some organizations, institutes and academic research related to various fields and referring to them is always good. 

Feel free to add your suggestions, recommendations in the comments box.