What Is AGILE and How Do Programmers See It

Before we get started, it is vital to identify AGILE as a term. That is an iterative approach to managing projects, which is general for a bunch of procedures and practices stemming from the Agile manifesto. Its main principles are:

1. People and interactions are more important than tools and processes.
2. A product that works is better than sufficient guides that exist.
3. Collaboration with a customer comes before contract terms confirmation.
4. Navigating changes matter more than sticking to an initial plan.

Our communications are done via SLACK, and it's a friendly and cooperative ambiance there; whoever is online is ready to help or share some new tips. We connect with people worldwide, so jet lags are unavoidable, which obviously leads to some pings. We keep the work tradition alive with daily team meetings to discuss issues, blockers, or current tasks to keep that in check. By the way, everyone is absolutely open for a private call to mull over some issues arising or approaches to existing problems, to swap opinions, or give a piece of friendly advice. We value development and personal growth, which is impossible without knowledge exchange. We take our spare time and privacy seriously above every other work; we respect each other's privacy, and communication stops after working hours. Whatever has not been done will be carried over to the next day. It is an excellent way to feel what jet lag is like in other countries and fine-tune your schedule like you simultaneously exist in several countries just sitting in your cozy armchair. Respect and transparency are the milestones of teamwork, though pulling request checks should be considered, so we do not get snowed under with backlogs.

I have to mention that a perfectly fine-tuned Agile is the one that we programmers do not even notice. So, everything goes smoothly, and we just co-exist in one amicable vacuum community, where everything goes smoothly. Everyone can easily balance his pull requests, learning, and private time with a cup of tea and a great book.

A Working Product Is Better Than An Existing Guideline

The working product is more critical than an acceptable guideline that just exists. When working with the weighted shortest job approach, we sometimes need to choose between preparing a procedure or checking the task for sustainability and efficacy.

We do care about the client's guidelines, but the best approach is a clear and transparent code. I am a Golang developer, so my cases will be based on it. To avoid type-too-many-words-for-a-guideline work, we perform tests. Numerous tests. Thus we check it for any minor error and create a demo using one method or function. We use commentaries everywhere necessary and never forget about linters to check for syntax errors and control safety. Do not hesitate to use them -- it significantly improves sustainability. Who can refuse a product that works?

What else?

We have a staging environment to check the workability of tasks and avoid standalone unit test coverage - various scenarios with as close-to-real data as possible to prevent production errors.

Ready to push it to a staging environment?

Hold on, we have a Docker that performs locally and to your (just imagine!) environment with a perfectly tailored dataset. You do not be scared of facing a task alone; the team is around and ready to share tips to make the work better in the best way possible, but only when necessary. We do not park our noses where we are not welcome. Literally, we also use make files to prepare some scenarios for peers, so the files usually have a make help command to show some additional info about available commands and short descriptions. And we never avoid GRPC with code generation to maintain our guidelines (the ones that we do have time for) fresh and supportive.

So, I believe you clean your floor instead of just writing a massive guideline on walking on it. If you have time for both -- that is gorgeous; if you do not -- the priority is evident.

Cooperation over perfection.

We help our clients with their tasks, so this is crucial to understand how our cooperation with a customer works. It is not only about microclimate inside the team; clients do matter.

We are transparent. Whenever a developer sees a more straightforward and better approach to deal with client's SOW, we put our heads together to offer a way out. We do our best to improve the service—not just to work with what is written but to analyze and contribute. Jira makes it simpler and more sustainable, so a developer can reach out to discuss details and solutions with a task-giver. If there is no one responding, a manager is doing his best to either create a solution or give you a hint on the problem.

This approach is a pure and vital part of the principle mentioned above as a client brings SOW to developers, trusts them, comes in half a year, and blissfully waits for a great result to come and work. Imagine nothing has been done. The customer gets furious, throws stones, and misses deadlines at the team, which is understandable, but we are less concerned about the reasons for failure. Thus, I see that the first communication principle has been severely violated. Agile is all about continuous communication. That is the only way we come from a Customer's word to understand a Product Owner concept and cooperation with the team.

You know, it is like in a relationship with your partner, sometimes a simple straight question is enough, just offer a solution instead of mechanical typing or, what is worse, keeping a solution in mind and hesitating to share. That solution can be better even if it comes later, and your SOW is just a paper that can be reprinted. But do not abuse it.

Navigate changes as initial plans tend to sink.

We are unique but not perfect, so we also follow a sprint system to deal with arising issues. Yes, we get some ad-hoc and sudden hurdles to be solved right here. It usually directly affects project sustainability or critical business objectives, though we are blessed to face it slightly more often than never. And that only proves that we are all human, and humankind likes to make mistakes. We always own up to our mistakes and apologize for them.

Why is it so important for a developer?

Well, our several-times-a-week team syncs allow us to get feedback from clients and be ready to act. It is like a developer with a helicopter that can view both inside and outside. The developer can fix issues when viewing from both ends (especially the trouble-maker). He can offer a way out.

People tend to be scared of navigating the uncharted territory of changes, especially when a developer has to make amendments to satisfy the business. Still, we CO-exist, so we know we are helping businesses and still working with the technical call to being agile. Lack of flexibility between the necessity and impossibility of implementation (yes, some people want more than others can do) is a clue in avoiding some stalemates and conflicts.

Well, as a wrap-up, people make statements of work and plans. Try to have a day following the procedure you wrote somewhat a month ago, and that is how you can understand why changes are crucial for both sides. Navigation is not only about point A or B, and it is all about balance in a crew. And your client is a part of your crew. Keep that in mind.

Written by:

Vladimir Goncharov

Senior GoLang Developer

Vladimir is an exceptional Golang developer with an impressive track record. Vladimir is a problem solver, an architect of efficient and scalable solutions, and a constant learner in the dynamic landscape of Golang development.

What is AGILE and How Do Programmers See It