As part of any project we undertake, we usually like to work in a particular style.
Now, ultimately we want to follow a process that our clients enjoy, that allows us to finish projects within a well-defined and predictable time-scale, and that allows clients to launch products earlier rather than later to give best return on investment.
So as good Agile practitioners, we have been continually modifying and improving our process as we’ve gone along, throwing out the methods that fail (erk!), and tweaking the process where it succeeds (yay!)
Sure, there’s been times in the past where we felt a lot of improvement was deserved and required, but we now believe we’re at a point where we’re happy and confident in the way we work …
Agile Development
At Singing Horse Studio we follow an Agile development methodology. Now, Agile development means many different things to many different people, so I think I should describe the core tenets of our process, and why we believe it’s so beneficial.
High-priority work first
By always focusing on the most important task first, we’re given the greatest flexibility for reducing scope whenever the tensions increase between the other aspects of the project completion triangle — i.e. scope, resourcing, and time.
For example, a client wanting to launch a product as soon as possible, can safely cut down on the features if required, being safe in the knowledge that the most important work has been completed first. This actively supports development and launch of MVP (Minimum Viable Product) as described by Eric Ries in his lean startup techniques.
Short bursts of focused work
In the development vernacular, these are called sprints.
The goal of a sprint is to deliver one or more features or components of a project, and to do so with a maximum focus on actually delivering work.
Software development really benefits from the flow state, so we try to limit distractions and context switching during a sprint. This means that task/project planning, creative thinking about how to use the product with yellow widgets, discussions about how the product will evolve in 6 to 9 months time, modifications to the agreed sprint goal etc etc are BANNED — or at least those that involve the actual software developer!
This is why we have project managers and project teams; leave the coders to focus on getting the sprint completed before you involve them on these distractions.
Anyway, assuming all goes well, at the end of a sprint there’s traditionally a demonstration of the feature/component/sprint goal to the client and project stakeholders. It’s at this point we all go for a beer. Or two.
SCRUM artefacts
One Agile methodology that Singing Horse Studio enjoys following is SCRUM. As part of the SCRUM project management process, several artefacts are created — the product backlog, the sprint backlog, and the burndown chart.
The Product Backlog: At the start of the project, the product owner prepares a list of client requirements, and then prioritises each of these by business value. We contribute to this product backlog by estimating the cost of developing those features. The requirements are formed by features visible to end-users, as well as the technical requirements to build the product.
The prioritisation is important, because this is what allows us to focus on most important features first. Of course, once the sprint is under way, anything in the product backlog can be re-prioritised if desired.
The Sprint Backlog: When the team has committed to delivering a set of top priority features from the product backlog, those items are then broken down into individual tasks required to deliver each feature. Once tasks are planned and estimated, they form the workload required to deliver the next sprint. These tasks form the sprint backlog which makes for a simple reference for both product owner and development team to understand exactly what’s expected to be delivered at the end of the sprint.
The Burndown Chart: During the course of a sprint, the actual time taken to deliver a task can be compared with the original estimate. These actuals and estimates are recorded on the burndown chart, which shows the current progress of the development team. By closely monitoring the burndown chart, each interested party can easily visualise how the project is progressing, and can quickly rectify wayward planning or implementation.
Frequent product demonstrations
Demonstrations show the piece of high-priority work that has just been completed. This demonstration can be validated against the specification whilst at the same time soliciting feedback from the client to help assure that we’re doing the work required in the manner to which we’ve committed.
By running frequent product demonstrations, we all avoid the trap of completing a project without feedback. Imagine a year long software development project, and being told on day 365 that it’s not how the product should now work! Finding out after week one is a much better way of mitigating against a truly expensive mistake, eh?
Iterations
Marc Raibert once said “Good Writing is Bad Writing That Was Rewritten”. A similar thing can be said for code.
Kinda.
Apart from the fact that we start with good code, not bad code!
You see, we make good software the first time; we make great software by being able to iterate on it. Working on the most important things first, we evolve that core code with greater enhancements, additional features and clearing out defects as we go along. All this iteration over the codebase is made possible because we make sure our code is covered by tests …
… which leads us to …
Test-driven development
So, how can we continue iterating over the code without fear of breaking previously working code (something that QA discover with regression tests)?
By insisting upon a high level of continually tested code, that’s how. And which we ensure by adopting test-driven development.
Test-driven development is a way of writing software that makes it easily testable from the start. Hey, it doesn’t have to be done that way. In fact you can try and write code to test your assumptions afterwards, but usually you’ll find that you’ve made it impossible to test because your spaghetti code has introduced inter-dependencies, and relies too much upon expensive (in terms of execution time) method calls to live databases, networks and customer data. Ouch.
Test-driven development has the double benefit of firstly insisting on having tests that ensure everything works as expected, and secondly makes the codebase that much easier to understand and digest.
Furthermore, we never encounter the same defect twice. If we discover a problem, we first write a test to warn us of the defect, and then we write the code to ensure the test passes. It will never turn in to a defect ever again, even with non-related changes.
Continuous Integration
So, how can you be confident that your latest version of the product build actually works? Surely, just because the individual unit tests pass, it doesn’t mean your product as a whole will work successfully first time, will it?
Well, we have confidence because of continuous integration.
Any time code is checked into our repository, the product is automatically re-built and integration tests are immediately run. A green light means all is ok; a red light means something broke. And if something broke, then that becomes our highest priority thing to fix, because we always want to be in a state where we can “make the product live” and have no fear in doing so.
Code is Law
How many times have you read a wiki page, documentation, or a instruction manual about how something is supposed to work, but it never quite seems to work that way in reality?
It’s far too easy for documentation that lives outside of the codebase to fall out of sync with changes in the software. And so, because of this, we always aim to derive our documentation from the code itself. Tools like Epydoc help drive this to ensure we generate useful documentation.
Anyway, hopefully this has given you a little insight into how we work. It’s a process that has evolved; it’s a process that will continue evolving, I’m sure. Remove the fail, celebrate the win, and deliver high quality software products in the process — that’s our ultimate goal.