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 diverse.
Not 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.
Reference: Agile software development recommendations for users and new adopters from our JCG partner’s blog Development in progress.
Related Articles:
