Scrum it up, man. Scrum it up: Agile Development Procedures just make more sense.

When I first began studying Design Patterns, I realized that simply programming and trying to come up with more efficient ways to do things had already lead me to a process that was very similar to things like MVC, Singleton, and Factory Methods. Learning the rules and structures has helped my processes tremendously (mainly because it cuts out a huge amount of repetitive trial and error), but the reason they are accessible, for the most part, are because they simply make sense.

When I recently picked up Agile Software Development with SCRUM, I had the same type of experience. It just makes sense. Since we’re all family here, I’ll be vulnerable here and tell you what I thought when I began hearing the ‘buzz’ words like Extreme Programming (XP), and Agile Development.

1. They’re specific to a programming language / environment (WRONG)
2. They are terms relating to a coding style or set of coding methods (WRONG)
3. They are really only necessary / effective for larger-scale, low-level development (WRONG).

Wow, 3 strikes, and I was out… without ever having actually studied the subject. Here are the basic tenants of SCRUM.

(Which, alas, is NOT an acronym. Lame, I know. I was totally hoping it meant something like “Super Crazy Radical Underground Methodologies” or “Software Creation Relating to User Management”. Nope. It’s just some word. Basically. It actually comes from a term in Rugby. Go figure.)

1. The Product Backlog
2. The Standup meeting
3. The Daily build
4. The 30 day Sprint
5. Better products
6. Happier Developers
7. More Satisfied Clients

I won’t go into all of this, ’cause I read the book, and so can you. However, suffice it to say that the basic idea here is simply to use the most reasonable, sensible method to handling software development that is possible. I see this as a way to manage any project that takes more than a couple months to complete. Here’s how a 3 month website project might work with 5 developers.

The product backlog

The Product starts with a backlog. Seems weird, I know, but it’s less redundant this way. The principle here is that there is an ordered list based on criteria like importance, accessibility, and dependence of other items. So, if our 3 month site is a custom blog, our basic backlog might look something like this.

1. Server Setup
2. DNS / Email setup
3. User Authentication Classes w/ prototype
4. Database Design
5. Technical Scope Document
6. Functional Scope Document
7. Post Management
8. WYSIWYG Editor testing, selection, prototype, and implementation
9. File upload system
10. Tag / Keyword management
11. etc…

The Standup Meeting

Now, at the first meeting of the team of 5 who will be building this blog, there may be a db / server admin, a front-end developer, a designer, a project manager, and a php programmer. They each (hopefully) should see something on this list that they can attack immediately, and independently of the others. Thus, the #1 & 2 item for the db/server admin may be totally different from the #1 & 2 items for the project manager. They each discuss quickly what they can accomplish off of this list during the first “sprint” (a 30 day product cycle), and they assign themselves tasks to accomplish in that time frame. If you’re the “Scrum Master” (the leader of the team who runs the standup meeting), don’t worry, you’ll be able to check on each one of them for 5 - 15 more minutes the next morning. Dismissed.

The Daily build

On day two, there should be work accomplished. Amazing, I know. There should be problems that have risen. Not amazing, I know. The point here, is that the entire team has an opportunity and obligation to voice the answer to 3 questions.

1. What did you do since our last meeting (yesterday)?
2. If you didn’t accomplish what you thought you would, why not?
3. What will you have accomplished by our next meeting?

This is immediate accountability. This also removes the bullshit of sitting at a desk for a week asking people for their help on something if you’re lost, and getting nothing. This removes the guilt of feeling stuck on something. This removes the distraction of knowing you can get away with procrastination, thus hurting the rest of your team. This takes care of a lot of things. This, simple 5 - 15 minute meeting with a small group of people who share a common goal, and the necessary skills to accomplish it.

The 30 day Sprint

Every 30 days, the Sprint is over. The team addresses what the goals were. Which ones were met, and therefore can be taken off of the product backlog, which ones were not met, and therefore must be added to the next Spring, and which ones were completed, but are buggy, and therefore their bugs need to be added to the product backlog. This 30 day goal set is simply a way to keep everyone focused on rapidly approaching deadlines, with daily opportunities to assist each other in meeting the goals of that Sprint.

Better products

The fact is, if the product is rapidly developing, and lots of qualified people are developing it together, there will be holes in the application logic that show up long before QA ever touches it. The team has frequent opportunities to address bugs before they appear, add features and tools, and adjust the entire project according to their developing needs, since the next Sprint is just around the corner. If the product is allowed to evolve, the essentials will tend to come out quickly, instead of being held up by an unnecessary feature set, or even worse, a bug in an unnecessary feature.

Happier Developers

Daily accountability is not everyone’s cup of tea. I’m aware of this. It’s not mine. I have a problem with authority. There, I said it. However, I have the tendency to deliberately take on projects that I can’t do, in order to learn that skillset. Upon learning the beginning of the skill, I see the potential of that technology / procedure / technique, and I get side tracked from the end result while I explore under the guise of ‘tweaking’. OR, I get bogged down into something is simply creating a mental brick wall, and have no way out of it until the time comes when I’m supposed to be showing the client a finished product, but am instead showing them a list of grievances with the piece of crap I’ve had to share a computer with for the past 3 months.

I’d trade all of that for having a daily opportunity to speak up for some assistance on that one line of code that I simply can’t get right, or on the new-found knowledge that the platform / technology selected to perform the task is simply inadequate, and needs to be rethought. The end result for such an open, accountable, and supportive environment, is a happier developer.

More Satisfied Clients

If the product is great, and the people building the product love building it, and aren’t befuddled every time the client comes up with a new feature, then the clients are going to be happy. They know, no matter what they request, that they will see some type of result in 30 days. If they have ever worked in software / web application development before, they will be absolutely thrilled with this reality. If that’s not enough for them, the knowledge that a group of developers who are working on their product have gone from figuring out how to get as little done as possible in the time frame requested, to developing so rapidly that they daily discuss new ways to improve not only the product itself, but the means by which the product is developed… well, that’s priceless.

[MasterCard, call me. I'll happily put an ad here for you.

Conclusion: Read the book. It’s great.

Your friend and mine,
Meshach