Here at Debenu, we make developer products (among others) through software development. In a lot of ways, that means that Debenu and our developer community are peers as well as having the traditional vendor-client relationship. By virtue of that unusual relationship, we are in a position to learn from our clients, as are they from us. In particular, our internal processes can potentially be quite relevant to our customers (and vice versa).
We do our darndest to run an efficient, capital-A Agile workflow (specifically, we favor Scrum. So, why didn’t I just say that we “do” Agile development? Well, the term is both popular and frequently misunderstood. Some (perhaps many) companies claim to be Agile, but for one reason or another haven’t implemented key features of Agile development practices. We don’t claim to be getting it completely “right” (we’re not sure that we are), but we do like the basic principles, and have found a system that works for us. Often, a certain amount of compromise ensues as soon as the tyres hit the tarmac, so to speak, and we don’t think we’re an exception to that. Anyway, I thought it might be helpful to start writing a series of posts about how we work here at Debenu.
First up, what is Agile? In general, Agile methodologies are focused on short cycles of iterative development. Planning, design, development, integration, testing and deployment are all completed by small, cross-functional teams, and within a flat, collaborative organizational structure.
In Scrum at least, each iteration (or “sprint”) should finish with a potentially shippable increment of a product. That’s a bit of a mouthful, but essentially that means you need to finish each sprint with some working software. Early iterations should work, but they’ll be thin on the feature front. In fact, the first iteration might only have one feature, but that feature ought to function correctly.
The idea is that the final product can be built in vertical slices, a few features at a time. Between iterations, reactions should be solicited from the team and relevant stakeholders such as clients, and this feedback can then be used to drive the next round of development.
Agile methodologies are typically contrasted with conventional “Waterfall” methods, characterized by discrete, sequential development cycles. Each phase might be conducted by a different team, and there is generally no working prototype available until near the end of the release cycle.
I won’t speak about them in great detail, other than to point out that Waterfall methods seek to anticipate needs and challenges before anyone can use the software. As such, many functional problems can only be identified very late in the process. If the client sees a prototype and wants to change direction (for example, due to a miscommunication about functional needs), then the team needs to return to an earlier phase in the development cycle to fix the problem.
There are quite a few approaches to implementing Agile development practices, including Scrum, which is the one we favor here at Debenu. In future posts, I plan to describe some of them and talk about how we have structured our own development processes.
