How to implement Agile development into a working team?

Question

We have a working team of 3 PHP developers, 1 scripter (Javascript) and 1 architect. None of us have actual experiences with Agile development from any of our previous teams. My question is how to effectively implement Agile development into our team? What should we do first? What are prerequisities? Should we implement all at once or bit by bit? Which principles should we implement sooner and which later?

Another issue is that we currently miss one additional member and we simply cannot do our work in time. Should we push ourselves and work for example 30 minutes more every day or simply go by Agile not-more-than-8-hours-a-day rule? What are your experiences with "fighting with management" in such cases? They feel like we don't need additional member, but I simply refuse to work weekends or off-times anymore.

Answer 1

There is a lot of literature on how to introduce agile to a team at agilealliance.com. My advice is to go slow and pick one or two practices to add. Start, perhaps, with small iterations and TDD. Work up from there. In my experience, you'll be more productive and may not have to fight to get extra resources. Note that while you are learning, however, you will probably be less productive for a time -- actually more productive, but some of the time/energy will be going into learning instead of coding, so less code will be coming out. This should be short-lived.

I think it's important to have some management buy-in before you start, because there may be some initial drop in productivity. You'll have to have enough buy-in to get you past the initial learning phase if you want to avoid having to work overtime. There's a really good book, Fearless Change, that describes the process of advocating for change within your organization.

You might also be interested in the answers to http://stackoverflow.com/questions/53318/effective-ways-to-introduce-agile-into-the-workplace

Answer 2

"Agile" and "working long hours" are orthogonal concepts. Working on an Agile team doesn't mean you start at 9 and end at 5 no matter what. Addressing a culture of over-worked and under-resourced teams is a different challenge from introducing Agile, and in such an environment you may have a hard time effecting change.

I'd start by examining why you're overworked. Is it because you have critical deadlines that can't shift, and your team (management included) isn't good at planning, so you end up with mad dashes at the end? Or is it because management just doesn't respect the work that you do?

If your team isn't good at planning then Agile may have some value. Agile can help you identify that you're behind schedule earlier, so that you have more time to react. It can also help you stay on task: in my experience, it's easy for developers to be inefficient or unproductive at the start of long release cycles because there's no sense of urgency. Short iterations, like a week or two, keep the sense of urgency in its sweet spot: there's enough pressure to keep you from slacking off, but not so much that it's negative.

If management just doesn't respect the tech team, then going Agile will be tough. Scrum, for instance, requires that the Product Owner and Technical Team mutually respect each other enough to follow some simple rules. If your management is likely to just say "we don't care, work longer anyway" then they aren't likely to abide by the spirit of an Agile team. That doesn't mean you can't go Agile... just don't expect management to buy into it.

As for HOW to go Agile? There are tons of SO questions about that, and they will apply to you once you fix your culture issues.