Monday, January 25, 2010

Agile Discussion - Part 1 of X

Last week I was invited by @RolfEleveld to participate in an Agile development discussion for his user group (TechiesUG) event. It was fun sitting with a bunch of geeks and having an open discussion on what is Agile development and how to convince stake holders (including customers/senior managers) to adapt to it. During the discussion following questions were raised (specially by ZubairDotNet)...


- 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
Now let me try and answer these questions, one by one:-

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

Edit 1: fixed the links.

7 comments:

Unknown said...

It's a nice brief and precise discussion on a beast called Agile.

I would like to comment on the first two questions which you posed and wrote about in this discussion:

1- Which one is the best Agile APPROACH?

I agree that SCRUM and XP are the most widely used and maybe most appropriate methodologies when using Agile development. Personally, I believe that the decision to use which one agile methodology or an hybrid approach depends on many other factors like the nature of the project, timeline, type of resources available, etc. I haven't come across many articles or research papers which discusses the adaption of agile methodologies or fusion of these methodologies from the the perspective of different project types.

2 - How often should we do Code Reviews, Does it slow you down?

Code review is an essential thing, but as you outlined what level of code review? I agree that most of the things like coding practices and standards can be automated and we can use tools like FXCop to make sure the formulated policies are being followed.

One thing that can't be automated is the review of implemented logic. What do you think is the best way for that? I personally believe this is a problem even in pair programming as it depends on the type and level of resources paired. I think once a requirement or unit is completed and is ready, an Architect level person or someone senior should check those logics to make sure they are implemented in the best possible way, people in haste of completing a requirement often choose incorrect or inefficient ways to implement.

Looking forward to the rest of the discussions in this series.

Ronald Widha said...

oh Hammad, why blogger? ;) I sooo dislike bloggers comment engine. anyways...

"like agile means no documentation, no planning, no up front design"
I halfly agree with that statement. Although agile does not mean that it has no documentation, it prefers working softare than documentation. And lookinf grom the lean approach, up front design and planning are potentially wasteful activities. Having said that I agree with you on the part where you say it's take and give. Finding the best balance is the art that we need to master a agile consultants.

There are different keys (more than just the lack of overall vision) to why I think agile might be a harder challenge for consultant. They will be a long post, I'll post these concerns on a separate post, which you can reply on part 2 of X ;)

As for your point about proxies. I'm not convinced about the usefullness of proxies. Even more so on putting the architect as a proxy. If a proxy have to exist, business analyst would be the closest position that can handle the responsibility. Architect should be apart of the dev team acting as a 'specialist' in the area of helping to make 'the hard decision'.

Note the word 'help'. Agile is about self managing/organizing team. The specialist should help the process of doing something and not doing it on someone else's behalf.

Hammad said...

Thanks for your comments @FarhanShahid:

1- Which one is the best Agile APPROACH?
I agree there are no silver bullets here. And its still a bit of a grey area at the moment. However IMHO i have seen SCRUM + XP generally works well. But there are no one-size-fits-all approach here.

2- How often should we do Code Reviews, Does it slow you down?
I have learned a few things over the years and i have seen them work pretty well. code reviews (at least everyday if not on every check single check-in) . Now who does these reviews and how this knowledge is shared across the team is a different dimension. I will dedicate a full blog post on it. stay tuned...

Hammad said...

thanks for your comments mate...@Ronald Widha

I do tend to agree with your point of view specially after reading your post http://www.ronaldwidha.net/2010/01/26/4-reasons-why-pushing-agile-as-a-consultant-is-a-harder-job/

as you suggested, i will tackle this in another detailed post :)

Now for proxy customers, i have seen the need for this in real-world scenarios. However i do agree, ideally a Product Manager is right person to help with the problem/business domain. But then in Agile world all developers should understand business right? In my experience, in the absence of dedicated business analyst/product manager, architect can wear different hats and is best placed to help things out.

More of this in next blog post :)

stay tuned.

Rolf Eleveld said...

Hamad,

Thanks for the Notes, I will do the notes on the techies board, for now I have cross linked your notes from http://events.linkedin.com/Techies-ae-Open-Forum-Agile-Development/pub/207337 the event notice and the Linked-In Techies Group Discussion: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=57771&discussionID=12437015

Awesome!

Rolf Eleveld

Dissertation Writing said...

Nicely explained. It's indeed an art to stop new visitors with your attractive writing style. Truly impressive and nice information. Thanks for sharing.
-------------------------------------------
Dissertation Writing | Dissertation Advice

romancito2010 said...

Great post, very useful

Coches Electricos Precios
Motos Electricas Precios
Coches Hibridos Precios