Agile or Agile Development – we hear these words more often these days. But do we really know what it is all about? How can it help us become more effective, while having lots of fun developing software? How can we use it to communicate with business people and make this communication easy and constructive for both sides?

What is Agile Development?

There were a bunch of very talented and experienced guys developing some serious software. These developers observed other companies and development teams, and how their processes made their work easier. They compiled their observations to create the Agile Manifesto. And they said:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

In this article, I will present twelve theories and techniques of Agile Development. This is just the first step to the new world of Software Development process.

1 - Customer Satisfaction

Our highest priority is to satisfy the customer through early and continuous delivery of valuable, but not full-featured, software. This means we're developing software and adding at least one feature, per iteration.

Let's imagine that we want to create a blog engine; we might do so using the following process:

It is a simple approach, but the customer sees the real progress of his software and gives you immediate feedback on each new feature. It may be perfect or require tweaking, but you can quickly respond to changes: a win-win situation.

2 - Adapt to Changing Requirements

Even late in the development cycle, Agile processes allow you to welcome changes for the customer's competitive advantage.

The customer wants the project finished quickly and as close to the design drawn in their mind as possible. This is easily achieved by simply listening to their input and being ready for changes. If we are able to react quickly to changing requirements, we are probably the best choice our client has ever made. Agile is all about communication and changes. We do the things as we are asked to do them, making the software development process finish faster. This is achieved because we develop small pieces of software, and a change in the requirements doesn't really affect us.

3 - Deliver Frequently

We should deliver updates from a couple of weeks to a couple of months; the shorter the timespan, the better.

customers feel more confident in us and our product as it is updated

From my experiences, customers feel more confident in us and our product as it is updated - which is vital to our relationship with them. Another advantage is the feedback from our client; allowing us to react by changing classes, features, modules or even the architecture. We won't wake up after days or months of work, only to see that everything is going into the trash. Let's consider a hypothetical situation:

You have been asked to create a module that will display some simple text in a content manager. Suddenly, the requirements change and you have to add a form that should send an email to a configured address. Additionally, the form should be customizable so the user can add new fields and define validators. So, you basically have to forget about the original simple text requirement. How soon would you like to know about this change?

If you work on a project with your client and deliver frequently, you'll know about these changes faster, and changes such as this will become easier for both of you.

4 - Work Together Frequently

This may prove to be the most difficult principle to get accustomed to, if you've been developing software in the old waterfall style. You, as a developer, typically do not speak the same language as your client, but you can find ways to maintain meaningful communication with them. One of the best ways, in my opinion, is to describe everything  with a simple story that tells us, the developer, for whom the feature is, what its responsibility is and why we need it at all. Of course, this gets easier the more we work with our client. Another helpful approach is Behavior Driven Development (BDD), but that is a topic for a different article.

5 - Build Projects with Motivated Individuals

Give the people you work with the environment and support they need, and, above all, trust them to get the job done.

It is important to provide an engaging atmosphere and all the tools necessary to create good software. Companies lose their best workers mostly because they don't truly care about them. The belief that developers can write, test and deploy software on some server using an FTP client and editing live production files got lost somewhere. If you haven't condemned those old school habits, you better do it now.

Retaining employees is just one benefit; you can also develop better and bigger software at a quicker pace. Just think about it: writing reusable code, automated tests, and automated deployment on any server (among other things) can positively affect development time. We usually think we slow down a project because we have to learn how to use helpful tools, like Jenkins, GIT, SVN, Gerrit, Behat, etc. Frankly, we do, but we can then reuse those tools and concepts in future projects.

6 - Use Face to Face Communication

It's the most efficient and effective method of conveying information to our clients and development team.

Who hasn't gotten overwhelmed and/or angry by seeing 6,255,384 emails in your inbox, because your company demands all conversations be "on paper"? I've personally seen that a few times in my life, and I do not recommend working in a company with such habits. Face to face conversations make communication easier and smoother, and allow us to give more information. We can use verbal and nonverbal ways of communication to show our teammates what we are thinking. It's obviously faster than emailing each other.

But above all, we need to trust each other; trust is easily gained in an environment that encourages face to face communication.

7 - Measure Progress with Working Software

This is one of my favorite rules; it lets us freely work according to our own processes. Software developers are different than other employees; so naturally, they should be treated as such. From my personal experience, I've learned not to judge anyone from the development team as long as the job is done. Developers don't want to create bad software, and they are less likely to do so if we let them work according to their own preferences. After all, the customer is happy as long as the work they commissioned is done correctly; they don't care how it was done.

8 - Maintain a Constant Pace

Agile processes promote sustainable development, allowing a constant pace to be maintained indefinitely.

Agile's most well-known advantages (such as the acceptance of changing requirements, fast reaction to feedback, etc) are widely appreciated, but the best advantage, in my opinion, is the ability to precisely determine the amount of time a project or feature will consume. After a few deliveries, the dev team will produce the most valuable business number: capacity. Capacity is the amount of work the team can do in one iteration. The capacity number is stable after a few iterations, and we can avoid the ridiculous deadlines and time estimates that are "pulled out of a hat" while presenting our company's offer to the customer.

Many people say it's impossible and scheduling proves to be more accurate. I disagree; the schedule assumes that there will be no mistakes or unavoidable delays.

It's a perfect plan for a perfect team, and that does not exist.

9 - Pay Attention to Industrial Progress

Continuous attention to our industry enhances agility.

We are expected to evolve and make progress. We must continue to learn each day, because the industry moves at such a fast pace. As both hardware and software get better, we must keep up-to-date; otherwise, we'll find ourselves lost in the "sea of new" and it will be hard to get back on track.

Refactoring is the solution to most problems. By constantly refactoring (when needed), we can easily apply new techniques and better our software architecture.

10 - Simplicity is Essential

Bill Gates once said:

If I have some complicated work to do, I will give it to the laziest person I have, because they will find the simplest way to do it.

Simplicity is the golden rule. This does not mean that you have to be lazy, but it does means that developers complicate their own work the majority of the time. If you only do the job the client wants, without any additional functionalities and improvements, your work load will lighten, and you'll achieve your goals. Ultimately, that is all the customer cares about.

11 - Self-Organize

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

We are only humans; we can’t predict everything.

Have you ever been in a situation where you developed a large and time consuming application, and after spending countless hours in front of the screen writing thousands of lines of code and reading articles, tutorials and books, you sat down looking at some bad (but working) code thought, “Now I know how to write it better”? I think we've all had these moments.

This is where the eleventh rule comes in. We have a team of developers who can follow the principles of Test Driven Development (TDD), where refactoring is a part of the process. In some magical way, our software is useful, beautiful, well written, tested, and created quickly. We are only humans; we can't predict everything.

This all comes from the idea of a self-organizing team, where each member has a role - not given or forced - but one that has emerged after some amount of time working together. That's the beauty of team work.

12 - Reflect and Adjust

At regular intervals, your dev team needs to reflect on how to become more effective, and adjust its behavior, accordingly.

This may require a few development cycles, but the team will work in perfect harmony. Even adding new people to this team would not be harmful. An Agile development team is all about getting the job done. If they work in a friendly environment, they will find the “melody of work” and you'll see how fast software development can be.

A Few Agile Development Methodologies

There are a few methodologies derived from and built upon Agile principles. I won't describe them all because each methodology can be covered in its own article. I will, however, outline some of the more well-known Agile approaches. One thing to remember is that there is no one methodology to rule them all. Choose one that fits your needs best, and even “configure” it to fit your specific requirements.

SCRUM

Created by Ken Schwaber and Jeff Sutherland, SCRUM is a business-oriented framework for managing software development processes. There are many different types of SCRUM; just remember that the main goal is to work effectively, and efficiently and not to stick to rules.

Extreme Programing (XP)

Created by Kent Back, XP is a list of best practices that developers should follow while creating software. It's often called “the extension of SCRUM”. This methodology of development-oriented rules was born, due to SCRUM being rather business-oriented.

Lean Software Development

Two of Lean's main principles are: DALAP (Decide As Late As Possible) and DAFAP (Deliver As Fast As Possible). I personally recommend reading more about this methodology, as it can be very useful.

There are more methodologies in the Agile family; I've simply referenced the most popular options. If you decide to use Agile in your development process, you need to know what these methodologies are, in order to choose the right one for you.

Final Thoughts

Do Agile techniques really work?

Do Agile techniques really work, and are the methodologies really as magical as everyone says? Not always.

The problem I encountered in companies, where Agile methods did not provide results (or even made things worse), was a badly chosen methodology and the lack of conviction among its users (business members, the development team, etc). That's why, in this writer's opinion, you need to be sure that everyone involved in the process understands the rules, and they know “what it's all about.”

Thanks for reading!