Where can I learn about agile/extreme programming online?

Question

I have a small (5 people) team of developers working in a bunch of projects right now. How can I use some agile/extreme methodologies to keep an organized shop that always delivers projects in time ?

Answer 1

Whether or not your shop will always deliver projects in time does not depend on using one method or another. It mainly depends on the skills and attitude of your people (including yourself).

Anyway, I imagine you have had a look at http://www.extremeprogramming.org; that's a good starting point. Google for "agile method" or "extreme programming" and that will give you a lot of results.

By the way, I also recommend radical project management, which fits well with an agile approach to engineering: see here: http://my.safaribooksonline.com/0130094862 for starts.

Answer 2

Well, to start out with, agile doesn't REALLY help you deliver projects in time so much as let you give accurate estimations of when you will deliver projects--that can be a pretty big difference.

It involves accepting the fact that if someone says "The deadline is tomorrow"--it will still be ready when it's ready. Agile helps you be good at tracking when it will be here.

Learning about it without a coach can be tough. Part of the problem is that you tend to think there is a lot of stuff you don't need, but Agile only takes away process by giving you something else...

For instance, Agile takes away "Design", but that absolutely requires ruthless refactoring & extreme testing which--mostly--compensates for a lack of design.

It takes away comments in the code and documentation but ads pair programming and a continuous team (Your team should ALL know Everything about the code). Without the 100% constant pair programming, you may find yourself needing more documentation. Also pairing can be annoying as hell if you don't have someone to guide you through practices.

You may be mostly interested in the scheduling portions though. This mostly involves admitting that programmers are horrible at estimating their work and creating an ongoing "Map" as well as a "Burndown chart" to help you revise the map.

For instance, you ask a programmer to rate each task in difficulty 1-5 just in relationship to each other, then you track how long the tasks actually take and calculate a map between 1-5 and hours/days. This process is constantly revised.

I'm not trying to tell you how to do it--what I am saying is that it's not a freebie--it's actually kind of complex. You might try to hire one or two people who've already done it for starters.

I can say that if implemented well it can take a shop that isn't good at high level design and/or engineering management and help them produce a better products with less hiccups.

Answer 3

TDD

• Here is a good slideshow on why TDD is awesome and how it works, to get you hyped up for it and give you a good introduction to how it works.
• Here is a tutorial you can read through or follow to start learning TDD.
• Here is a set of practice problems that you can learn TDD through hands-on.

Pair Programming with TDD

• Here is an illustrative example of two people using TDD and pair programming to solve a problem.
• Here is another pair programming example, right from the xprogramming website.

Answer 4

It may be difficult to learn to use agile/xp methods by trying to learn about them online.

As @Bill K said, having a coach, someone who has succeeded with agile before and knows how to teach it and assess it and refine it is a big help.

Your team being on "a bunch of projects" is a challenge. I'm not necessarily saying that agile teams will fail unless they are dedicated to one project, but learning to be an agile team while being pulled in different directions will be additionally difficult.

You can try some techniques, but beware...

On the other hand, if you are committed to only improving your current methodology and not transforming to agile, you might get a lot of mileage from the Extreme Programming Rules. But keep in mind that it's easy to try a few random agile and XP techniques without understanding how they all fit together, get frustrated by how unnatural and difficult they are, get the same or worse results as you had been getting before, and decide that agile is a fraud. I think that's how most anti-agile folks came to their opinions, and I don't think it's an accurate assessment of whether or not agile methodologies can be effective.

Answer 5

I'm including some book references because I don't think you can learn the kind of things you need to online. There's a few references at the end which are online, and which might help you. Please bear with me because I think the things I'm putting here will show you why you can't just learn from online materials.

Agile doesn't help you deliver projects on time. It helps you find out when you're not going to, so that you can adapt accordingly. Agile helps you fail fast, not succeed fast. Agile success is one of the big myths which a lot of "sellers" like to push, but really, it doesn't exist, nor should it. Some projects will never return their investment, and all Agile can do is to let you know that this is the case. This is of course amazingly powerful information and well worth having, so please don't let you put this off of Agile!

The big problem with that is that shops and consultancies often tie themselves into fixed scope, fixed timescale, fixed cost projects. If you want to do that then include contingency - exactly the same as Waterfall - and use the information which Agile is giving you early to do something different in case of failure, or at least start expecting the loss.

If you're still using contracts in which supplier and client are each trying to shift the risk of delivery off onto the other person - old-style Waterfall contracts - then it may be worth looking at some more collaborative models. I've seen Time and Expenses work pretty well when the client trusts you; otherwise there are several different models in Mary Poppendieck's "Lean Software Development".

If you want to learn more about Agile from a project / programme management perspective, I really like Craig Larman and Bas Vodde's "Scaling Lean and Agile Development" and David J. Anderson's "Agile Management for Software Engineering". Most Agile books don't really go into programme management - they're quite low-level compared to the problems you'll be encountering - so you may need to look in the Lean space, which has worked really well for me alongside Agile methodologies. Also pick up some Systems Thinking, start working out where your slowest feedback loops are and how you're going to reduce them.

For the lower-level technical stuff, I like Kent Beck's "XP Explained" and BDD, most of the resources for which are online anyway. A lot of people have picked up BDD from blogs, and it now covers analysis (through Feature Injection), acceptance testing (with scenarios) and unit-testing / TDD space. Dan North's blog is one of my favourite references, and I hope that this article I wrote might be useful to you too.

Best of luck!

Answer 6

There are many good practices that are used in agile development.

Here is a great presentation on how to do some practices : http://www.autumnofagile.net/

The presentation is very long, but you can skip most of it. Just take care not to skip important parts (for example where he presents how to do TDD, or where he tells to use MVP).