Agile software development believes that software requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customers and end users, not by following the waterfall approach. Agile is not a process or a set of steps or tasks. Agile requires discipline, attention to detail, professionalism, making and keeping promises. Agile involves ethical statements and statements of morality.

Business understands discipline. Businesses really liked Scrum (see below). Business liked the idea and liked the idea of certification. However, business people do not understand the technical specifics of computer programming. Therefore they cannot evaluate and approve and technical practices and programming disciplines. Business doesn’t understand test-driven development or code refactoring. Therefore programmers cannot go to business and ask if it is okay if they write tests. Why not? It’s about risk. As soon as you ask you are sending the risk over to business. They don’t want it because they can’t evaluate it. Programmers who are professional will take the risk and be willing to take the risk of making the decisions on what needs to be done. One problem is that programmers don’t all agree on the technical disciplines we should follow. Some believe in test-driven development (TDD) and some do not.

Soon after the Agile manifesto in 2001, the project managers (business) invaded and took over Agile. Now we have two groups of Agile: business practices and technical practices (craftmanship). As a movement, Agile today is primarily business oriented. In actual practice (in offices in projects) both sides exist. We still have not healed the divide between business and programming. Programmers need to take the lead and do this. Programmers, according to Bob Martin, must define their discipline and agree, otherwise business will attempt to define it for us through legislation. Will they one day do this? A poorly written piece of software may kill thousands of people at once. The computer programming profession needs to be regulated. Regulation means certifications to get, books to read, principles to follow and so on. This means having ethics, saying no to your boss sometimes and taking an oath.

One Agile principle encourages the use of self-organizing teams. A self-organizing team is one that has the flexibility and authority to find its own methods for achieving its goals. Teams with different levels of authority may also set their own goals, track their progress, and even pick the team members.

The opposite of a self‐organizing team is a micromanaged team where the manager tells everyone else exactly what to do and when.

Agile Techniques

There are a number of techniques that are common to most agile methods, although the agile manifesto doesn’t tell you how to implement the values and principals, probably because that would go against agile values. Here is a list: communication, incremental development, and focus on quality.

Scrum

“Uncle” Bob Martin in his Clean Code book recommends reading Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle, although there may be other books on the topic that are better. What is Scrum? Wikipedia says: “Scrum is an agile process framework for managing complex knowledge work, with an initial emphasis on software development, although it has been used in other fields.” It goes on to say: “It is designed for teams of ten or fewer members, who break their work into goals that can be completed within timeboxed iterations, called sprints, no longer than one month and most commonly two weeks, then track progress and re-plan in 15-minute time-boxed stand-up meetings, called daily scrums.” (the bold is mine).

At the end of the sprint (about two weeks, but preferably one week), the software should be ready to deploy! Every two weeks we should be ready to deploy. It may not have enough features to deploy, but features are a business decision. From a technical point of view, it is ready to deploy. Therefore all of the changes to the code and the testing will be done and be ready to deploy at the end of each sprint.