In a recent article on TechCrunch about Agile Methodologies, the Comment Wall quickly became a flame war with such pithy commentary as "Agile is a load of ****." I've posted a couple times on what I like about Agile and what I don't like. A lot of people in the comments section complained that Agile was just management jargon. But a lot of people said Agile was the bee's knees because up-front planning sets you up for failure if some unforeseen disaster strikes, like say the U.S. Economy's horrendousness. I find myself in the middle. I love Agile's short iterations and its focus on scope. But too often Agile is held aloft as a panacea that teams can use to immediately begin producing perfect code in half the time; that just hasn't been our experience.

We here at the Community group are in the process of writing dozens of tickets for the next 3 month period. We're covering all of the exciting new products and features we're planning on launching in that time period. And even though it's a little bit of a slog to get through them, at the end we're going to have an amazing backlog and our iterations are going to be worlds more efficient and gratifying. Plus, we're getting experience writing useful user stories.

User stories are one of the key aspects of Agile Methodologies. The goal of User Stories is to describe functionality of your application and its value for users or product owners. Since we work with RSpec and Cucumber, our user stories are all of the format:

As a ______

I want to ______

So that ______

This helps us capture who the feature is for, what they want to do, and why it's important for this feature to be implemented. Working with these stories will allow us to not only prioritize all of our tickets for our upcoming iterations, but it will constantly remind us why we wrote the stories in the first place.

Watch out over the coming months for awesome new stuff from the Community group!

The following are some of my favorite parts about the software development methodology known as Agile:

1. Short iterations. By organizing tickets into one- or two-week sprints, you avoid having to cram tons of work in at the end. You're application is constantly progressing. One of our new team agreements is to have a working demo with Selenium coverage at the end of each iteration. With short iterations that goal is infinitely more realistic.

2. User Stories and Prioritizing.  Clearly defining functionalities of your application makes it easier to write the code. It also makes it easier to discuss the relative importance of features. This helps decide which tickets make an iteration and which tickets remain in the backlog. And when you get the sense that you're working on the stuff that is the most important to the application, that makes the work more satisfying.

3. Testing and Behavior-Driven Development. You write a test for a user story. You watch it fail. You write some code to implement that feature. You watch it pass. You repeat. It is without a doubt the most gratifying way I've found to write code yet. You're cranking through tickets. You're bit by bit producing an awesome application. And you constantly see the tests pass so you know the code is safe.

These aspects of Agile make it really fun. It's much easier to be productive and much more satisfying seeing yourself (hopefully) completing your goal every iteration. Iterations are realistic, yet aggressive. In addition, using Behavior-Driven Development you get a little ego boost every time your code makes tests pass. Life's little victories.

Completely unrelated, but check this out:

g-speak overview 1828121108 from john underkoffler on Vimeo.

We here at the community group have committed to the software development methodology known as Agile. Agile makes working in small groups better by, among other things, shortening the development cycle, encouraging knowledge transfer, and offering programming paradigms to make coding more efficient and enjoyable. But Agile is still new to many of us, and we're still experiencing some growing pains.

Pair programming is tough. The idea is simple: two coders working on one machine will produce code in less time that is more bug-free. The reality so far has been that time spent coding hasn't improved much and bug-freeness is arguably worse. Granted, there has been some knowledge transfer (though not nearly enough) as a result of pairing, but all told the process hasn't been nearly as effective as advertised. That being said, we're not doing pair programming correctly - it's impossible to with our group. We have people working on non-project related work. We have people who can't screen share for one reason or another. We have too much work to pair all the time. When we do pair, the non-coding programmer often has their own laptop with them, doing other work (we all have too much); they aren't always actively participating and keeping an eye out for inefficiencies and buggy code. But I also believe we the coders aren't solely culpable.

The scientific evidence backing pair programming is shoddy at best. Also, the learning curve is steep, and the potential gains are not necessarily worth it. Personally, pair programming still feels weird to me. Often I find myself just watching someone code. Usually it's with Cody who happens to be an excellent, dare I say expert, coder. So while I've definitely learned a lot pairing with him, I've only really caught typos watching him code. I haven't seen any glaring bugs in his code, nor any glaring examples of inefficient code. And I don't want to speak for him, but I think for the most part the experience for him has been similar while watching me code. So is it worth it to lose the code we could be producing separately in order to have us sitting together watching each other code? I'm not sold that it is.

Behavior Driven Development with RSpec is a programming paradigm our group has made a priority. In a nutshell it involves writing specs first, defining how your program should behave, making sure they initially fail, and then writing the code to make them pass. Henry and I used RSpec and BDD when building Envoy and it was really, really fun! We produced an extremely lightweight, yet powerful, application with 100% test coverage. And as is mentioned by BDD supporters everywhere, the psychological boost you get from seeing your tests pass as you're coding (using autotest) is not inconsequential. Every time that autotest goes green your pride gets a little boost. But BDD is also not without its problems; namely, doing it. Our group is having an awful time getting itself to write tests for its new code, partially stemming from our existing projects having very little test coverage (which I assume makes us subconsciously ask, "Why start now?"). And RSpec is fairly difficult to learn. There are the Peepcode screencasts. And there is an upcoming book - we really need this David! So hopefully as we get moving on to new projects our test coverage will consistently be at or near 100%, and we'll all become comfortable with Behavior Driven Development as a programming style.

In addition to these two coding factors, Agile as a group and project management style is a little too touchy-feely for me We have weekly meetings where we thank people and reflect. I could see the guy in this video liking it a lot (and I pick this video because this is my favorite Gilberto Gil song and I'm mildly obsessed with Brazil). It often feels excessive and over-the-top. Maybe if we had longer iterations - 2 weeks (1 month?) instead of a week - retrospectives wouldn't feel like such a drag. And perhaps as we move onto bigger and much, much better things that feeling will subside.

But Agile has some good parts. I have no qualms about User Stories, which are an extremely effective way of organizing project features. Due to my overwhelming competitive side, I of course like the point system aspect of Agile. Although with that there is the danger of becoming a workaholic. I like it when Ed, our boss, gets involved with projects as a pseudo-product owner. I think it brings an interesting perspective on the work we're doing. So while overall I have a sincere fondness for most of Agile as a programming methodology, some of it is either detrimental or superfluous to our group's ability to produce good code efficiently and many of the parts that aren't are a pain to adopt as part of our group's official programming and management style.

• High self expectations
• Set realistic dates and hit them
• Balanced workload across team
• Commitment to quality
• Think of the big picture
• No black holes/documentation/wiki
• Complete knowledge transfer/team
• Everyone speaks/shares everyday

Scrum is the glue that holds our agile iterative development process together. You can get a more official and in-depth definition on the Scrum process from wikipedia or any number of places around the web.

We've found it to be one of the most helpful processes that helps keep our small group working together on a large project on task through improved communication and high transparency.

Here is how we run our daily scrum:

Since we our team is made up of people from different locations, we all call into a conference number at the same time every morning. Once we get everyone on we do a quick round table which involves each participant giving their status update.

Each team member answers three questions:

1) What did you do yesterday?

2) What are you planning to work on today?

3) Do you have any road blocks (any issues that are impeding your progress)?

And that's pretty much it!

A Scrum with 4-6 people participating shouldn't take much longer than 10-15 minutes. Sometimes it can go a bit longer or shorter depending on if any road blocks are brought up, and if there are larger issues that come up that warrant more discussion, we table them and schedule a separate meeting to discuss in depth.

So, keep a set time, round table the three questions, and get back to writing code!

I recently sat in on part of ABC's two-day Digital Media Developer Summit.

Lex Sisney, CEO of ELC, which we teamed up with with for development and training, spoke about Agile and Iterative development, open source and how they could fit into ABC's developer stack.

Lex touched on three trends:

1) Success of agile/iterative project management
2) Emergence of developer friendly programming languages (specifically Ruby)
3) Commoditization of hosting (Amazon Web Services)

I spoke about how the ESPN Community Group utilizes these three trends for our development process. Oh, ESPN and ABC are part of Disney, which is why I got the invite in the first place.

We got a great reception from the various developers and managers there, which was great. These folks use the same proprietary technology and project management methods we used to use and I got the impression there is a lot of excitement for trying new technologies, methods and hosting solutions.

One of the best questions was what are the fringe benefits we've enjoyed from using all open source methods and technologies. As a manager and developer, I have noticed several:

1) Greater number of applicants for positions
2) Developers acquire skills more quickly
3) Developers acquire a much broader range of skills
4) Developers are more eager to improve their knowledge and skills (because they are acquiring marketable assets)
5) We have become part of a much larger community. Both in terms of taking and giving, we are active in the community through code sharing, Google Groups and much more.

Another great question regarded the combination of Test Driven Development, Agile Development and Ruby on Rails and if they can be separated.

I think Lex answered this best by saying TDD and Agile are methods and RoR is a great tool to use with these methods.

But it is interesting because Agile and TDD almost go hand-in-hand with Rails because the stack is so conducive to those methods that developers would almost have to fight against the methods NOT to use them with Rails.

Any language or stack (especially MVC stacks) can utilize TDD and Agile as processes, but both were baked in with Rails.

I can't think of any reason why that's bad, but I'd be interested to hear arguments on negatives to that.

The last big theme that I tried to stress is that we are not forcing or trying to force any one to adopt our methods or technologies, but merely present that, even in a large company with established methods and technologies, change still can happen, and languages, methods and hosting can be chosen to fit a particular application or product.

For example, I said that moving from Java to Ruby to do the heavy SAX-based parsing of statistical data feeds probably wouldn't be the best idea, but Ruby may be a much better solution for building a new social network.

So I am very glad Lex and got to share knowledge with developers from another part of the community. I hope the company as a whole embraces different solutions, so we can move beyond boundaries created by a particular technology and join a very smart and open community.