Like many development organizations we have had our share of conversations about methodologies. An R&D organization’s objective is always to produce the very best quality products on time and on budget, and as an organization, the Changepoint development team has traditionally performed very well and met these objectives. However, there’s always room for improvement and a couple of years back we began to revisit our development process to see if there were greater efficiencies we could eke out.
Up until our Changepoint 2009 SP1 release, the Changepoint product was developed using a traditional Waterfall methodology. Waterfall uses a linear approach to the construction of software. Requirements are determined, designs are created, then implemented and finally tested. It worked well for us. The approach was predictable and our teams were comfortable with it. We met our objectives of producing good solid product on time and on budget. But it wasn’t perfect. Because of Waterfall’s sequential nature, we lacked the flexibility to adapt a software project once it was underway. Mid-stream changes tended to get bogged down in change controls. We wanted to inject more flexibility into our development process to adjust to changing market conditions and to absorb more customer feedback where we could.
So a couple of years ago we began looking more seriously at the Agile development methodology. Unlike the Waterfall method, Agile teams work in “development sprints” intended to offer a software development team maximum flexibility and maneuverability. We felt that a move in this direction might benefit our teams and our product – allowing us to factor in more customer feedback and adapt Changepoint to meet changing market demands. Our first agile project kicked off with the Changepoint project worksheet back in March 2009.
Now Changepoint is developed in four-week sprints, punctuated by daily SCRUMS (including the development team and product owners) to deal with questions as they arise. At the end of a sprint, the completed work is reviewed, the next sprint is planned based on the requirements backlog, and project work is prioritized accordingly. And one of the nicest things for all of us (including customers) is the product work completed to date can be taken out to focus groups where feedback is captured.
Agile has many benefits – most importantly, we get the product out the door faster. There are fewer surprises for the product managers, as they are involved in every development decision, and all related trade-offs. It tends to produce a better product that is more finely tuned to the needs of customers. Customers get to participate in the development process through their feedback.
Some might wonder how difficult it is to implement a methodology change within a development organization. In our case the change was not particularly difficult at all. One of the reasons for that is that we actually use Changepoint as our development management system. I’m a big believer in a software vendor “drinking their own champagne” and feel that by using our own product, our software team develops more empathy for our customers. So Changepoint has become our “one source of truth” you might say within the Changepoint development team. We plan out our project there, assign tasks, log requests, and report from the system. And changing over to a new methodology is a fairly simple exercise of amending our workflows to adapt to the new way of working.
Are you leveraging agile in your projects? We’d love to hear about your experience.