Agile Zone is brought to you in partnership with:

I'm a software developer. I'm passionate, I like what I'm doing and I try to do it better every day. I like open technologies because that's where I'm coming from. Currently working as a freelancer on J2EE applications. Particularly interested in Scala, Liftweb and Functional Programming. Andrew has posted 14 posts at DZone. You can read more from them at their website. View Full User Profile

Agile software development recommendations for users and new adopters

  • submit to reddit
Let me begin by saying that I am an agile believer and as a team player I enjoy this methodology much more than the traditional waterfall methods.

Agile is like a fashion these days. Its one of the buzz words, it's "cool"...and I think it actually is.
With popularity also comes rumors, myths and misunderstandings that often cause problems in agile projects and blames attributed to the process itself.

There are many teams claiming to use agile without even knowing the manifesto.

Yes, it is not be the answer to all software development problems, one size doesn't fit all, but before you adopt it in your project or blame it for not working please read this and if you have some feedback feel free to leave a comment!

If you are considering agile take into account
  1. Project size.
    It's easy to apply agile in a new project, relatively small ( tens $K), with traditional client-server architecture and clearly defined users/customers but ..
    what about a re-write of an existing big project (hundreds or millions $) with distributed software and multiple stakeholders? Is hard to deal with that in agile methodologies...check this article for more info.
  2. Customer or product owner must be agile
    If all your customer really wants is a product with a fixed number of features in a fixed time frame, then you are probably going to fail. You are anyway even if you don't use agile. But I guess the point is agile is not going to help.
    In agile you have to continuously redefine the requirements, re-elaborate them, re-prioritize them. Your customer must know and accept that.
  3. Your organization must be agile
    No point going for an iteration based model if your company still requires all work to be signed-off in an upfront specification. To get the right value you need to be able to adapt ongoing work as it progresses.
  4. Your team might not be ready
    Yes, that's right the team might not be mature enough to be self-managing  and it is one of the points in the agile manifesto. You need to realize if you are going to start agile and lead accordingly. (Very good article here)
    You might have to hold on and train / lead your team ( and yourself ) for some more time.
    Agile approaches require a mentality shift. Simple things like saying something is "DONE" means is  production ready. It doesn't mean the code is done and now somebody else will have to make sure it works. Your team needs to be mature enough to own and  understand what they are committing to.
  5. Agile does NOT mean you are going to develop your software faster.
    That must be clear to all project managers.
    It increases business value and ROI because using agile the team focus on features that are prioritized by business value and incrementally deliver working software at regular interval.
    Less features => faster
    If you just consider the total time, agile is going to take longer due to continuous code refactor
  6. Don't do it just for the sake of it
    Embrace agile only if you believe in it. Not because people say it works.
    Or even worse just to tell your customers you are an 'agile' company.
    There are lots of successful company that never used it. 

If you are already using agile then
  1. Make sure you have a clear and commonly accepted definition of DONE.
    The whole team needs to understand the process. Make sure they are aware, understand and accept that. Your sprint artifacts must be production ready.
    Also remember that if your sprint outcome is not actually being deployed to production (for whatever reason) you are bending contract. Just take it into account that "production" bugs might be lurking in your code.
  2. Watch the technical debt
    Very often the technical debt tends to build up over the sprints due to. You need to closely monitor it and allocated time during your sprints to skim it off.
  3. Don't let team members act as product owner
    The product owner is the most important player. Is the one telling you want to do but most of all what to do first. The right prioritization of user stories will determine the success or failure of the project and only the owner should do it.
    Sometimes if you have a large team, you might be tempted to have someone in your team (most likely the BA) wear the product owner's hat.
    That can lead to a lot of problems and misunderstandings. One of the key points of the agile manifesto is "Customer collaboration over contract negotiation". 
  4. Your team is likely to be diverseNot every team member can take every story. Someone says agile is not junior developer friendly. Well its a bit more than that. You might have different people specialized in different disciplines and that will create a lot of contention / dependencies that you need to deal with.
  5. Spend appropriate time on your automation and continuous integration
    Part of the agile process is to continuously build and integrate the software. Developers are meant to run tests all day long.
    If your build takes 30 mins, your application server needs another 5 and so on then your productivity is really going to suffer. Spend some time to break off the application in smaller more maintainable pieces.
    Don't drag along cause together with the productivity the team is going to run into the bad habit of not running or skipping the procedure.
  6. Go for the "simplest possible" but don't forget the design principles
    The idea here is to get feedback as soon as possible. So if your application is going to going to generate graphs, there is nothing wrong in having an excel based first version to be sure you understand what the customer wants.
    What you need to be careful is that software architecture and design principles are not left out!
  7. Don't forget non-functional requirements
    User stories only talk about required function. The critical “how well” attributes are totally absent. Your stakeholders will expect them anyhow and that is when you are going to get in trouble.
    All the things like performance, scalability are really making the difference these days.  Check why chrome is becoming more and more popular

Thanks for reading this, your feedback is welcome!From
Published at DZone with permission of its author, Andrew Salvadore.




John David replied on Thu, 2012/01/26 - 3:21am

Hi Andrea, great post. Covers the ethos of agile development well. A few points resonate with me:
1) Size matters! Not just project size but team size as well, I like the two pizza rule -
2) Your team might not be ready. It's not just a matter of sending a team lead on a Scrum course. Your developers must be schooled in the art of unit testing and refactoring and have a good grounding in design patterns and practices. Also your project must be amenable to agile development - monolithic applications that are so coupled they do not facilitate unit testing are not good candidates for agile development.
3) Where does architecture fit into agile - often architecture concerns are overlooked in the quest to get something working fast. So how do you do just enough architecture without creating problems down the road because you have not considered certain aspects of the overall architecture?

Java Eclipse

Comment viewing options
