Since my role has changed over the past few months away from being a pure developer to a lead of an agile (scrum) group here, I’ve started blogging some about my experiences over at The Accidental ScrumMaster:
Let me start off by saying this – I have been a developer for just about all of my professional career (with some syadmin and networking tossed in to spice things up). I’ve helped to lead other developers in projects where we were focused on just the software and didn’t have to worry too much about outside forces. At my current job, this has changed. Over the last few months, due to some changes in staffing (read that as “people moved on”) holes were left in the team for certain roles. Before those people transitioned out of their jobs, they started to approach me with some of the responsibilities they had and showed me the ropes.
Suddenly I wasn’t just another developer anymore – I was the person managing our Jira project, I was the one doing the code merges and releases and I was the one tracking the progress of the project on a day to day basis.
I hope what I post there can be beneficial to other developers out there who find themselves with extra the responsibilities of making agile happen in their jobs.
As I’ve been reading through “The Art of Agile Development” (from O’Reilly, by James Shore & Shane Warden) there’s been a whole load of great suggestions for development practices and not all of them are restricted to an “Agile Only kind of world. One of the major ones that’s stuck in my head (and is repeated quite a bit in the book) is the idea of being “done done” in your development.
The average PHP developer seems to say they’re “done” when the code works from their simple testing, usually just entering values to ensure that things work correctly. I hate to break it to them, but this shouldn’t be considered done. Getting the code working correctly is only the tip of the iceberg – there’s so much more to do to get everything ready to deploy. Besides the code being complete, “done done” also means:
- Having documentation, both in the code and about the code. If future generations of developers were to come around and need to update your code, good documentation is a must. One line comments aren’t going to cut it…at the very least use something like the formatting for phpDocumentor to provide some automated docs
- Making those unit tests pass every time is essential. (You do unit test, don’t you?) Writing tests for all the bits and pieces of your application may be a pain, but it can save you in the long run. Imagine being able to fire off a test suite and being confident that those changes you just made haven’t broken anything.
- The code has to work in the build for your project. Some projects are small enough to where they don’t really need a build, but if your project is much more than a simple site with a database backend, you could benefit from a build. Developers should be able to do local builds to check their work prior to a commit and push.
- I must fulfill what the customer wants in the update or new feature. Sometimes, it just happens – you get to writing your code and you think about “this one cool feature” or “that other fun thing” that PHP makes so easy. You wonder why the customer didn’t want that in the first place. Be very careful with thinking like this, it could lead to some pretty random stuff in the end. In the end, the customer needs to be happy with what you give them – be sure it’s what they asked for (user acceptance testing).
Being “done done” means that, if you handed over your code to the testers or even the end customer, you’d be confident that it works and is ready to be integrated. Sure, it’s about the code being tested and correct, but its also about making it behave as a part of the larger whole. Your code (code ownership is a whole new can of worms) shouldn’t be viewed as “this part that does this” but more of a piece to the larger puzzle of you/your team’s application.
 What’s a build? A build lets you automate several things you might currently do by hand to get your code ready for production. This can include things like: building out databases, minifying code, running unit tests and checking syntax on all files to be pushed.
Along with some of the fun new things I’ve been working on it regards to development and deployment, I’ve also been reading up on the agile development methods. I’m only getting started and I can already tell you – it’s not like anything you’re used to (well, unless you’ve already “gone agile”, of course).
Despite all of the hype right now around Scrum, I figured I’d get my feet wet with the agile concepts with Extreme Programming first. I’m assuming that most of the principles will be similar with varying implementations between the two. My “manual” of choice to get started with has been O’Reilly’s “The Art of Agile Programming” (James Shore, Shane Warden) and it’s been an eye opener.
See, I’ve come from a place where, I imagine, most developers out there are coming from and probably still will be in the future. You spend months gathering requirements, you estimate the times, you set the deadlines – all very structured and, depending on who you’re doing the work for, potentially wasteful. We’ve all experienced the frustration of changes to requirements set at the beginning of the project. Things tend to explode when someone changes “one small thing” and the entire development track is suddenly ripped into pieces and put at the complete mercy of what the customer wants.
In short, it sucks.
From what I’ve gathered so far, the whole concept behind agile programming is to prevent things like this. It makes it simpler to move around in the project and change things that might need changing. Work is done in sprints instead of one long development process and the client/business representative selects the things that will be headed into the next development session. Requirements are more fluid and testers don’t have to wait until everything’s done to find where things break.
I’m definitely still in the learning process, but so far, this agile process doesn’t seem half bad. I just wish it didn’t require such a large change in the processes of the surrounding company. I might be tempted to suggest it around my office…