Probably you already hear Agile process at least one time in your software development life. Yes, this word becomes very popular nowadays. Google 'Agile' return many search results, you can see many successful case studies of Agile also the failures too. Many blames to Agile such as 'no documentation at all', 'suitable for small projects only', 'Agile is worth for process consultant not for enterprise' etc. Actually, Agile process is not suitable for all teams, it is different with older process (that the old manager already have experience) that it focuses on people, their skills and work attitude not project artifacts (use-cases, design document, process checklists, various project reports). The different focused items could cause guy, who is familiar with traditional process model, confused. If you want to applying Agile process to your real project (or the pilot one), your team must meet some pre-conditions to meet Agile, if not your project probably be failed. Here they are:

• Transparency:
  
  All project artifacts are available and visible to all members. People can know the status of other works, project status. I saw some people show their importance by hiding source of information, or keep the knowledge of their side. We must prohibit such actions in Agile process. The clear, simple communication plan or good knowledge sharing system will increase the transparency in your project.
• Ethics:

  
  Sometimes, I must deal with the meaning 'What is done?'. Whether people tell the truth when they said they complete their tasks on time (usually, the developer means when they complete 100% functional coding but they do not focus on their implementation quality - I give another blog post about this in future). Give the clear definition of terms you expect all have the same understanding and people must follow the rules. The short iteration requires people report the their statuses, problems exactly daily or bi-daily - They should not hide the facts that could make the bad domino affect to project.

• Team work:

  
  Could we lack team work when we work in a team especially in the environment requires frequent communication among members?

• Freedom:

  

  Think outside the box, the goal is making your project success not 'how to write the use case document and scare customer how professional we are', 'write the complexity architecture to show our high technical competence skills'. Think and do whatever makes your project successfully. Do not fix in one pattern solution to problem, for example 'We only use long pages use case to describe our requirements'.

• Open communication:

  

  You can talk anything in a party, you can show your weakness with your friend but some people can not share the similar things in their project team. They are scared if their project managers know they have the unsolved problems (while their colleague used to have experience and he could solve it in minute), they are scared if they raise their hand and ask a silly question etc. Removing the barrier in communication, listen your colleagues is the key to make inter-communication among members becomes better.

• Maturity:

  

  I believe that fresher could not follow Agile practices successfully without coaching. Some people think that Agile just is the chaotic process, that people just coding and coding (no requirement document, you write code and test) etc. Every one could join Agile process but how about quality? Writing the right unit test is no easy and follow Agile practices such as YAGNI is not simple as what it stated. The responsibilities of Agile developer is harder than the normal one: they must write the test code, they more involve to requirements process/estimation and actively manage their tasks. The works of product owner, tester, BA are different than traditional roles too. What they learn from Agile is different from what they learn before: it is not the definition of milestone, what artifacts must have in some specific integration but the software practices, attitude and flexibility combines with their job competence skills.

The rest of Agile introduction, you can see in my 'Agile introduction' presentation at here .

Related posts:

1. Pair review process – it should be better than pair programming I am a supporter of XP process with unit test,...
2. Having one big process for all kinds of projects, it is wrong! Nowadays, there are many processes as RUP, Scrum, FDD, XP...
3. Case study of applying continuous integration for enterprise project Continuous integration is one of good development practices that we...
4. I need ‘lazy’ developers It is the gif I can recruit the 'lazy' developers...
5. The interview experience I have chance to interview many candidates join to my...