We’ve just reached the end of our eighth sprint on the project I’ve been working on. On Monday we’ll be doing our end of sprint demonstrations to customers as well as internally to the rest of the company and I have to say I’m feeling quite good about it. It’s a lovely day today feel like I need to chill (or as Rob suggested – maybe I need to get a life 😉 ) anyway I’ve been sitting here reflecting on this month and there’s a few things I want to talk about.
I’m fairly new to the SCRUM methodology, in fact this is the first project I’ve worked on that formally uses it. Our development group here at Talis has adopted the SCRUM process across all of our current projects with what I feel has been a great deal of success.
For me personally the transition from traditional waterfall approaches to agile methodologies has been a revelation in many ways. Before joining Talis I’d spent a number of years developing software based on traditional waterfall methodologies. What was frustrating with these traditional approaches was that you’d spend months capturing and documenting requirements, you’d then spend a while analysing these requirements and then designing your software product, before implementing it and then testing it. Any changes to the requirements invariably meant going through a process of change impact analysis and then going through the whole process again (for the changed requirements), which naturally increases the cost to the customer.
A side effect of which, from the perspective of the customer, was that changing requirements during the project was a bad idea, because of the extra costs it would incur. A consequence of this is that customers would often take delivery of systems which after a couple of years of development, don’t actually satisfy the requirements that they now have. These same customers would then have to take out a maintenance contract with the vendor to get the systems updated to satisfy their new requirements.
From a developers point of view, I often found this to be very demoralising, you knew you you were building something the customer didn’t really want, but the software house you work for wants to do that because they have a signed off requirements document and contract that guarantee’s them more money if the customer changes their mind. I often found that when we reached the end of a project, the delivery of that software to the customer was a very and nervous and stressful time. The customer at this point has not necessarily had any visibility of the product so there’s usually a couple of months when your organisation is trying to get them to accept the product – which invariably led to arguments over the interpretation of requirements – and sometimes scary looking meetings between lawyers from both sides.
There was always something very wrong with it.
Since joining Talis, and transitioning to agile methodologies I can finally see why it was so wrong, and why agile, and in this case SCRUM, work so well.
For one thing, I’m not nervous about the end of sprint demonstrations. 🙂 The customers have been involved all along, they’ve been using the system, constantly providing feedback, constantly letting us know what were doing well, and what we need to improve on.
Our sprints have been four weeks long, which means at the beginning of the sprint we agree which stories we are going to implement based on what the customers have asked us for, these can be new stories that have been identified, or stories from the backlog. The customers have an idea, from previous sprints, what our velocity is – in other words they, and we, know how much work we can get done in a sprint so when we pick the stories for the sprint we ensure we don’t exceed that limit. This keeps things realistic. Any story that doesn’t get scheduled in for the sprint because it was deemed less of a priority than the stories that are selected gets added to a backlog.
This iterative cycle is great! For one thing customer’s are encouraged to change their minds, to change their requirements, because they then have to prioritise whether that change is more important than the other items on the backlog. They are empowered to choose what means the most to them, and that’s what we give them ! The customer doesn’t feel like the enemy, but an integral part of the team, and for me that’s vital.
As a developer it feels great to know that your customers like your product … and why shouldn’t they, they’ve been involved every step of the way, they’ve been using it every step of the way.
I’ve only been here at Talis for ten months, and in that time I’ve had to constantly re-examine and re-evaluate not only what I think it means to be a good software developer but pretty much every facet of the process of building services and products for customers. For me it’s been an amazing journey of discovery and I’m pretty certain it’s going to continue to be for a very long time.
The really wonderful thing though is that in our development group I’m surrounded by a team of people who believe passionately that it’s the journey and how we deal with it that defines us, and not the destination. So we are constantly looking for ways to improve, that in itself can be inspiring.
So yeah … I feel good!
Our development group is always looking for talented developers who share our ethos and could fit into the culture we have here. If you’d like to be a part of this journey then get in touch with us. Some of us, including myself, will be at XTECH 2007 next month, so if your attending the conference come and have a chat with us.
