The Agile Principles for Developers – Part 2

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Waterfall development is notorious for having copious amounts of documentation. There are contracts and specifications, and most of the communication is done via email or other written approaches. The upside of this is accountability. The caveat is that the documentation quickly becomes overwhelming. When team members receive hundreds of emails, they begin to overlook individual messages.

In contrast, Agile emphasizes face-to-face communication. It is much harder to ignore personal communication than it is to skim through an email inbox. For developers, this gives them a presence in the team. When each developer gives an update on their current work, it carries weight. Everyone is listening, so everyone has an idea of how far along each task is. Developers know better what each other developer is working on, and can avoid interfering with other tasks.

7. Working software is the primary measure of progress.

Metrics are a large part of traditional development approaches. Management looks at figures like lines of code added per day, or the number of commits that developers perform. These numbers are supposed to show progress and indicate how much work is getting done. However, metrics do not show the bigger picture. Massive changes may only require a few lines of code. On the other hand, small fixes may take several commits in a short time frame.

Agile uses the working software as the main metric for the Scrum team. New features indicate that work is being done. Fixed problems show that developers are doing their work. As such, the developer role can worry less about how their metrics look. If a developer spends several days working on a feature without many additional lines of code, they don’t have to worry about bad reviews. As long as developers create working features, the project is moving along adequately.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

One of the biggest problems with traditional development is technical debt. As the project continues, new development slows as problems and bug fixes crop up. Near the end of the timeline, teams are spending more time fixing things and less time developing new code. As such, the pace for new features is drastically lower than near the beginning of the project.

Agile avoids this by having all new features developed and debugged within each sprint. At the end of a sprint, new features are fully developed, tested, and shipped to customers. Problems and bugs aren’t postponed until later in the process, they are handled immediately. This gives a pace that a Scrum team can sustain indefinitely. The release of new features stays mostly consistent for the entire life of the project. For developers, this means developing and debugging almost concurrently. Instead of writing new code and coming back to it months later once the code has reached testing, they fix problems within days or weeks. As soon as the developers pass developed features to be tested, other roles on the Scrum team begin looking at the features and testing them. This reduces the total amount of research developers must do to remember what code does and how it works.

9. Continuous attention to technical excellence and good design enhances agility.

The mindset of waterfall development is to plan out everything at the beginning of a project and then execute. Once the design is set, that is how the entire future of the product will work. Problems come up with this approach when developers discover that the planned design will not work as well as other options. However, they have committed to the original design and cannot easily deviate. Changes are very difficult to implement, and research time has been wasted.

To combat that risk, Agile development regularly revisits the design. Instead of committing to a plan at the beginning, the Scrum team takes a project piece by piece. What seems best, in the beginning, may not actually work well for all features of a product. For developers, this means less time planning for a certain architecture or design. If plans change, they can adapt quickly and go in a different direction. This wastes much less time shifting designs to a better option.

10. Simplicity – the art of maximizing the amount of work not done – is essential.

Much like the documentation of waterfall approaches, traditional development does a large amount of unnecessary work. This work wastes time and resources and reduces how much the team can accomplish on the product. As such, the team is overall less efficient.

Agile development seeks to only do what is absolutely necessary. Documentation is kept to a minimum. Research is done at the last minute. Bugs are caught and fixed before developers move onto other tasks. For developers, this often means spending less time writing and reading specifications, and more time writing code.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

As with focusing on methods over the individual, traditional development assigns teams rather than allowing them to organize themselves. This often results in a team that is less cohesive. Certain team members may not work well together. Team members may have different plans for a project, and it can be difficult to reconcile these differences.

In Agile, teams organize themselves. This improves the architectures, requirements, and designs that the team creates. With developers, this allows them to find an environment where they work best. With the right teammates and ideas, a self-organized team is much more efficient.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Since waterfall development handles each step in one pass, there are no stopping points to look back and examine progress. The team must stick with their current approach until the end of the current project at least. After each project, the team can examine how things went and adapt for the next project. The problem with this is that every project is different, and what worked for one project may not be ideal for the next.

The cyclical nature of Agile software development means that there are numerous stopping points to look at the team’s progress. The end of every sprint shows a small slice of every step in the process. Therefore, after each sprint, the entire team can look back on what went well, what went badly and adjust to improve the next sprint. These are accomplished within the same project, so there is ample time to improve the project before the end. For developers, this means being more cognizant of their own work, and how they interface with others. By the end of each sprint, developers need to know how the process can be improved. Without an opinion, things will remain at status quo.

The twelve Agile principles are obviously a lot of material, but they all do have tremendous value. For developers, especially, the Agile principles create a cohesive and more productive team. By cutting out all of the unnecessary parts of traditional development and encouraging communication, Agile creates an environment that generates quality code efficiently.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum:

Master of Agile – Agile Scrum Developer With 59 Seconds Agile (Video Training Course)

Introductory Offer: Free Course