Today, I went into the office for a team review of our first stab at the agile development methodology Scrum. We didn't get nearly as much as we planned completed, for multiple reasons. However, during this whole development cycle, I've learned a few things about general development and developed my own practices based on what I've learned, so I thought I'd share with you some of the things I've learned. Many of these ideas are not new, nor are they even new to me, but I mention them mostly because they were reinforced into my mind, which means that it only has to happen a few more times before it clicks, ent?
It's a Buffet, You Can Come Back
One of the biggest problems is that we're undergoing some major changes to our codebase (read: complete re-write of most of the codebase). So when we started, we laid out all of our tasks on the board. It was quite a daunting task. We had a new database model, a new web framework, and the implementation of all existing functionality to port. This was quite the task. However, in our excitement, we did what I end up doing at a buffet on a normal basis: I forget you can come back for more, so I get more than I can eat in the first place. So my task list was humongous, and large task lists are bad for productivity.
The whole point of Scrum is to take small steps to accomplish a larger goal. Understand that you can come back. The stuff you couldn't squeeze into this cycle into another later on. Prioritize. Take the stuff from the buffet that you'd like to warm up with (like a salad, or modifying your framework for your specific needs). Build out from there. Pretty soon, you'll have built something that allows you to add new features in only a few weeks.
Boil the Ocean One Kettle at a Time . . . And Ship The Kettles!
My biggest problem was getting started. Rewriting code is difficult (at least, re-writing this code). Working with a new framework comes with a learning curve. Creating all the base libraries is time consuming and requires a lot research, research that only comes from actually developing the platform. All three of these problems, along with the unfortunate motorcycle accident of another developer, led to a slow start.
My biggest problem is that I wanted to get the libraries and models written right the first time. I think the biggest contributor to that was the plethora of books I've been reading, trying to improve my development methodology. It worked, but I also had to stop reading about it and do it. I think after I realized once again that the library would grow based on its needs. Instead of writing it one way, realizing it was wrong, and writing it another way, lathering, rinsing, and repeating, I just started with what I had, used it in some implementations, and found the problems there. This led me to change the libraries, fix the implementation, and then rinse, lather and repeat. The library code grew at an alarming rate, I found limitations in the framework that I was able to improve (hooray for open source), and created an implementation. It's definitely not the final product, but I know everything I need to know to fine tune it completely.
Keep Your Cycles Like Your Meetings : Short and Sweet
Our development cycle was a month long. That was too long. I spent a lot of time spinning my wheels, getting discouraged because I wasn't getting anywhere, watching the workload not shrink, but feeling like I had all the time in the world. After two weeks of that, I re-evaluated my process, and realized that I was literally trying to boil the ocean. I then sat down and shrunk my workload (see above), and made out a plan to finish only one set of functionality by the end of the cycle. Low and behold, two weeks of time was just enough for me to do what I needed to get done. There were snags, but it also meant that I worked more focused, set smaller goals to accomplish a the end goal, and took each set of goals day by day.
Along with that, we had daily status meetings in the morning. Almost all of our team telecommutes three days out of the week (including myself). The basic idea was that each member of the team accounted for what they did the day before, what they had planned for the day, and whether or not anything was blocking them from continuing (and what the blocker was). These meetings allowed visibility for eachother, and allowed us to coordinate our efforts. Seems that another developer had the same epiphany I had about the same time, and "with [our] powers combined" we provided a pretty decent deliverable (sorry, it wasn't Captain Planet).
