Agile methodology in software development: types and principles

 
So basically… What’s Agile?
 
Many teams that are using Agile probably won’t be able to clearly define its meaning. What is it? A philosophy? Some list of principles? A methodology? Well, actually, all of those are correct. Yes, even a philosophy (though it has nothing to do with Socrates, Kant or Descartes).

Agile methodology stands for flexibility and mobility, meaning that it’s ready for changes. It’s opposed to classical software development methods (though Agile principles themselves can be used everywhere, not only in the IT industry).

People and their communications are more important than work tools and processes. The application itself is more important than loads of technical documentation.

Cooperation and communication with the client are much more important than contractual obligations, which only will give you an additional headache. Finally, readiness for change.

Changes define Agile. Even if you think that your initial project is a true masterpiece, you cannot be 100% sure. Nobody can come up with a flawless plan, especially when you have months of development ahead.

It’s rather obvious that Agile development teams didn’t appear from anywhere. Agile principles came out from initial problems, which developers had to face during software development in the early 90s (and even before).

• Dedicated project team gets some project. But here is a problem – the customer himself doesn’t know exactly what he needs. Thanks to Agile’s openness to change, there is no need for the client to be extremely precise while describing his project – project requirements can always be altered.
   
  Well, at least while the changes remain reasonable. Surely, you don’t want to stop your mobile application development halfway through and turn it into a web application.

• New functionality is added very slowly. This issue came from the last century when every application had to be installed on each device. Lucky us! That’s when the internet started to develop really fast.
   
  It made possible running web applications on the server side. And thanks to this we now have one of the coolest Agile features – short iteration cycle, which allows us to add new functions more often. Now you can try out your software (well, at least partially) long before the end of the development cycle.

• Documentation. Tons of documentation. It’s that annoying black hole with almost no practical use, that sucks your money and time, even if you have a very experienced dedicated team.
   
  Agile doesn’t deny that some documents are required, but only some. Frequent communication with a product owner (latest application build discussion, change of requirements, etc.) can significantly simplify the whole development process.

 
Now let’s talk about most popular Agile variations:

• Scrum. One of the most popular options. Basically, Scrum splits project requirements (or, so-called, project backlog) into small independent groups.
   
  Because of that, an Agile development team can add new features during every sprint (time intervals between new product versions). Scrum implies constant communication – either it’s a regular sprint discussion with a product owner, or daily scrum meetings, where the team can discuss the project’s issues.

• Lean. In our blog, we already talked about lean methodology being applied to startups. But let’s have a recap. Lean is all about reasonable resources usage and unnecessary resource expense reduction.
   
  Initial product features are limited to the minimum, but this minimum has to contain the most useful features for the product owner. Therefore, the team finishes the product by adding new features gradually (step by step).
   
  For instance, you want to hire mobile app developers and make a messenger application. Will those video calls, fancy stickers or complicated premium account system be of any use for your target audience if your app can’t… Send messages? It’s pretty obvious that initial features should include message delivery.
   
  All other stuff can be added later by your dedicated Agile team. By the way, you can read about lean methodology in our blog!

• Kanban. Just like many other awesome business practices, Kanban came to us from the Japanese car industry. Kanban has three main guidelines. First one – visualization (that’s what hieroglyph “kan” stands for).
   
  By visualizing the development process, the team splits it into separate phases (planning, development, QA, done, etc.). It helps to keep the development process structure simple.
   
  Second guideline: you have to limit the number of tasks in every phase. Remember: keep it simple! Every team member can focus on his work if he doesn’t have to switch between different tasks.
   
  And finally, the third one – work process optimization. You track the time needed for operation, analyze the results and try to improve KPIs. It’s as simple as that. Keep in mind that team members shouldn’t overdo or underdo their work.

 
A long time ago in a galaxy far, far away…
 
But our Agile review won’t be complete until we compare it to one of classic software development models – waterfall. It’s a common thing to say that waterfall is outdated and nowadays is useless.

Still, one rarely mentions that waterfall is quite good for massive and complex projects which don’t need any changes. It’s doubtful that you would try to alter initial blueprints of a space shuttle (it could lead to a catastrophe).

However, it’s barely usable if you decide to hire mobile app developers for a much smaller project. But let’s talk about the model itself.

Imagine a real waterfall. Can the water go back, once it has flowed off the cliff? Unless gravity has stopped working, the answer is “no”. The same thing happens to Waterfall model.

It’s linear and very hard to modify. You have to specify almost every detail of the project – and, just like water, the project can’t turn back. That’s why some serious issues will most likely pop out only during the testing of your application (when the development process is complete).

Now it’s pretty obvious that Agile methodology is far more flexible than Waterfall. Nevertheless, Waterfall is rather suitable for less skilled offshore development teams as the model itself is well structured and is hard to misinterpret.

It also can be used if time isn’t an issue for you, and your company is ready to spend a lot of resources while polishing up the project. And if it’s not? That’s when Agile hits the stage!
 

Agile teams features
 
Many Agile teams can’t actually define which type of Agile they are using. You most likely won’t be able to find a dedicated development team that will use pure Scrum or Lean.

There are a lot of effective practices that can be used by every offshore development team: daily scrum-meetings, usage of backlog and roadmap, iterative development with fixed sprint size, retrospective, etc.

Be ready to constant contacts with your dedicated Agile team in order to clarify all the requirements and provide feedback. If you want to get exactly what you want, it’s the best way for you.

Luckily, almost everything is possible when you use Agile. Especially when you have your own experienced dedicated project team.