Technically everyone knows what agile means: defining user stories, playing poker to address how much time will it take to build this and that, springs, scrums, scrum master (I have no idea who defined that or why) but again, the thing almost none knows is if is the right choice for their current team or project.
These are Five Steps to define if Agile is for your team:
1. Does your team know enough about the code base and do they have a strong sense for where things are in the code? If so, great! You have a very good advantage to follow the agile practices whichever you define. But when in doubt, make sure everyone works on small or medium parts of the current code. In other words, make your team explore all the features, areas, third party services, dependencies, tests, etc, so everyone has a general idea of where things are.
2. Is your team distributed? For example 2 in Chicago, 2 more in Mexico, 2 in CA, different timezones? Awesome. You have the ingredients of a perfect storm. But don’t freak out. Make sure you create a good work environment and specifically, build trust between co-workers. Make sure everyone knows how to do deployments, migrations, merges, solve problems together, trust each other, split work according to skills, etc. Be happy.
3. Is your team disciplined? Can you relate to things like developers that don’t respect a scheduled deployment time, team meeting times, Git standards set for your team, etc.? If so, call out those people and get everyone on the same page ASAP. Whether you have a distributed team or have everyone on site, the fact that you follow rules, written or not, will have a huge impact in your process. With no rules, none of the agile flavors will work no matter how experienced your team is.
4. Is your code base ready for agile? Yes, the code base will need to be aligned to continuous integration and TDD, but most importantly, your programming language must be one that can be correctly tested and designed in a way your team can create short user stories that impact the progress in a short amount of time.
5. Are you willing to give and receive feedback? This one is, by far, the most important question. If you or your team don’t want to talk about quality of code, what worked and what didn’t, how to improve communication, tactics etc., agile is not for you. In any of the agile flavors, you’ll absolutely have to give and receive feedback.
Every time you decide to reinforce or incorporate any of the agile tactics, make sure you think about these five points. Of course, as someone in my timeline mentioned in the context of these questions, “the best answer someone can give will be “it depends”. And many times, that is the truth. So go back to your team and talk about it, share your thoughts and make sure everyone is on the same page.
What are you guys doing? Please share your thoughts.
Interesting links: http://www.slideshare.net/alimenkou/agile-estimation-techniques
Ruby Rogues 109 RR Extreme Programming with Will Read
JoséLuis Torres @joseluis_torres