- Which one is the best Agile APPROACH?
- How often should we do Code Reviews, Does it slow you down?
- How does Agile work for Consultancy scenarios?
- What if the client is not part of the team, who acts as a proxy in Agile team?
- Whats the role of an Architect in an Agile team?
- How does estimation work in an Agile practice?
Before I move on to answering these questions, to set the context right, i would like to bring your attention to "The Agile Manifesto", it says:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
1- Which one is the best Agile APPROACH?
There are a bunch of available methodologies:-
Scrum
Extreme Programming (XP)
Agile Unified Process (AUP)
DSDM
Essential Unified Process (EssUP)
Feature Driven Development (FDD)
Open Unified Process (OpenUP)
Lean software development
etc.
IMHO, generally, the combination of SCRUM and XP works the best. In this combination, SCRUM dictates management aspects whereas XP rules software development practices like, Pair Programming, Refactoring, Continous Integration, TDD etc.
2 - How often should we do Code Reviews, Does it slow you down?
There are two common types of code reviews. One is formal code review which comes with all the bells and whistles (i.e. all the formality of setting up schedules, e.g. weekly code review by so and so to check this and that etc). Purists/Agilists tend to steer clear of this type of approach. The second approach, which is inline with heart of agile, is lean and mean.
If you are following XP then you are, by virtue of pair programming; pretty much getting code reviews all the time.
IMHO, in practice, its good to have atleast daily code-reviews (i.e. if you are not doing pair-programming 24X7). It also makes sense to run automated constraints at check-ins/builds (and validate some coding/design principles with the help of tools e.g. TFS's code analysis check in policies)
This is one of the classical scenarios where Architects come in handy (more on it later).
In a nut shell, code reviews dont slow you down, if anything, they help you with the quality of the software which makes it easy to maintain and undestand as well as less pain to change later on.
3- How does Agile work for Consultancy scenarios?
This is a bit tricky question. In a nut shell, it depends on the client. If we cast aside some misconceptions (like agile means no documentation, no planning, no up front design etc) about Agile then we can certainly benifit from it for most of the software development scenarios. As consultants we should definately try and sell our side of the story.
However in practice, we will win some and we will loose some.
4- What if the client is not part of the team, who acts as a proxy in Agile team?
It's generally accepted that If you dont have customer then you have to invent one. I would say it makes sense to invent more than one, infact ideally, each developer should understand the domain of the business problem. Practically some one senior (read 'Architect', more on it later) from the team should/could act as a so called proxy.
5- Whats the role of an Architect in an Agile team?
6- How does estimation work in an Agile practice?
to be covered in separate dedicated posts.
I will need to sign off now and hope to answer the remaining questions sometimes tomorrow.
Untill then happy reading and feel free to post your comments/questions and i will make sure that i will get back to you ASAP.
you can also follow me on twitter @ http://twitter.com/hammadrajjoub
2 - How often should we do Code Reviews, Does it slow you down?
There are two common types of code reviews. One is formal code review which comes with all the bells and whistles (i.e. all the formality of setting up schedules, e.g. weekly code review by so and so to check this and that etc). Purists/Agilists tend to steer clear of this type of approach. The second approach, which is inline with heart of agile, is lean and mean.
If you are following XP then you are, by virtue of pair programming; pretty much getting code reviews all the time.
IMHO, in practice, its good to have atleast daily code-reviews (i.e. if you are not doing pair-programming 24X7). It also makes sense to run automated constraints at check-ins/builds (and validate some coding/design principles with the help of tools e.g. TFS's code analysis check in policies)
This is one of the classical scenarios where Architects come in handy (more on it later).
In a nut shell, code reviews dont slow you down, if anything, they help you with the quality of the software which makes it easy to maintain and undestand as well as less pain to change later on.
3- How does Agile work for Consultancy scenarios?
This is a bit tricky question. In a nut shell, it depends on the client. If we cast aside some misconceptions (like agile means no documentation, no planning, no up front design etc) about Agile then we can certainly benifit from it for most of the software development scenarios. As consultants we should definately try and sell our side of the story.
However in practice, we will win some and we will loose some.
4- What if the client is not part of the team, who acts as a proxy in Agile team?
It's generally accepted that If you dont have customer then you have to invent one. I would say it makes sense to invent more than one, infact ideally, each developer should understand the domain of the business problem. Practically some one senior (read 'Architect', more on it later) from the team should/could act as a so called proxy.
5- Whats the role of an Architect in an Agile team?
6- How does estimation work in an Agile practice?
to be covered in separate dedicated posts.
I will need to sign off now and hope to answer the remaining questions sometimes tomorrow.
Untill then happy reading and feel free to post your comments/questions and i will make sure that i will get back to you ASAP.
you can also follow me on twitter @ http://twitter.com/hammadrajjoub
Edit 1: fixed the links.
