Getting Started with Agile – Part 2

February 11, 2016 | Editor


In our previous blog we touched on the history of Agile, what it means for a company to say they are ‘Agile’ and how to make Agile work for you. This week we’re going to go more in detail about what exactly Agile entails. As previously discussed there a number of reasons why you would want Agile to work for you. Some of them are that through Agile you increase customer satisfaction, you get a bunch of data that you can use to your advantage, there is a clear understanding of the size of the project so the question of whether it becomes manageable is answered, the product that you are making is of a greater quality and the risk on any given project will be much more bite-sized.

The best thing about Agile is that it can be tailored to your needs and can be used in any way that you see fit. If you are just starting to get the hang of it then delve a little more into the system, after you’re a bit more comfortable then use it sparingly til you know the ins and outs completely. Use Agile to then govern your project as you see fit.

Gearing up

To get started first you’ll need a team that’s perfect for the project you’re about to start. Choose people based on the roles that you foresee will move your project forward. In a way, choosing your team means choosing the technology that you’re going to be using. Aim for self-sufficient, independent workers that are able to take on more than one role. Your team sizes should be no more than 7 or 8 people.


If there are more then you might want to consider using Agile project management or assigning larger teams in charge of a relatively smaller portion of the project.
With the right team selected, guide them on how to best use Agile in variety of ways. Identify the behaviors, techniques, methodologies and frameworks that best support this scenario. Get people that form you team to give requests so that a servant-leader relationship can be established. Give your team-members adequate training in these methodologies so that nothing is left to chance.

The Project Brief

This is pretty much documentation of what your project is exactly and it allows for your team and stakeholders to get a clear idea of what they’re headed for. The project brief is imperative for a project using the Agile system because it will have the scope, purpose, and objective of the project as well as a singular idea between all the people concerned. The success of any project can be attributed to how well the people concerned are able to communicate with each other By making a project brief the ins and outs and minute details will be listed in this brief.

The company that you work for is imperative to how well company does. Along with that said it will give you an idea of how open our place of work is to new ideas and experimenting with different methods to achieve the best possible outcome.



The project brief also hires a few other very important factors. The project brief also clears an ambiguity on a few things. First of all i makes your expectations more realistic since they are on paper and not just a random figure at someone is throwing. There will also be a sort of protection on your investment since there is a crude document i.e the project brief which can be immensely important for any financial undertaking.

Overcoming the unbelievers

One thing that you should understand from the get-go is that not everybody might be as enthusiastic about using Agile as you. Some people might need convincing, and some people might outright reject the concept. The crux of the problem is that maybe the find the whole deal a bit confusing. If you give these individuals their due respect and understanding then the might come over to his side. Or they still might not. But it’s worth a try.



Start by implementing Agile in your own team. When you stat churning out software that’s a treat to look at then that could be more in favor of Agile then you could ever put in words. There must be a reason why there a recognizable improvement in the software right? Maybe it’s because of Agile. Maybe other team leaders could try implementing it in their own projects. There’s no harm in trying right?

In next week’s series

We’ve already covered the basics of Agile and why a company should be considering when adapting it, in the next blog we’ll talk about what makes Agile a great system and how it makes your project successful by minimizing your back-log though on intelligent prioritization






Leave a Reply

Your email address will not be published. Required fields are marked *

Follow Us