In the past two weeks we started working on the newest version of easygenerator. We do software development through an agile approach. I knew a bit about agile software development, but I was never really a part of the process. I don’t want to elaborate about software development methodologies, but for those of you who don’t know anything about it I will try to explain in a few words (as I see it as a non-specialist). Software was often developed through a waterfall model. You write the requirements, design it, build it, test it, and deliver it. It is a sequential linear process where you finish one phase before you start on the next (hence the name waterfall).
Image from wikipedia
For me as a non expert the essence of the waterfall model is that as a principal you are involved in the very first phase, then it takes a long time and the you will see the end result. As a principal you are not involved in the development process, therefore the end result doesn’t always match your expectations. In 2001 a new method emerged. The project is split up in short phases (called sprints) and at the end of each phase you have a complete working (part of) the product.
Image from wikipedia
And how did it work for me? We started by making lists of functional wishes and made very short descriptions for them (e.g. “I want to be able as a user to go back to an old version of a page”). Based on this input the product owner created user stories that describe in more detail what the functionality should be. In some cases one requirement led to a few user stories. Because the user stories are functional descriptions you can (as a non technical person) still fully understand them. Then we had a session with the product owner where we set the priorities. The development team awarded points to each user story. The points give an estimation on how hard it is to create the desired function. These points will help you measure the process during development. If the total amount of points awarded are 200 and you estimate an average of 40 points per sprint, you know that you will probably need 5 sprints (10 weeks). If you do just 60 points in the first two sprints, you know that you are in trouble. Easy as that.
Based on this input the development team makes a selection of the use cases that they can build in the first sprint. A sprint takes 2 weeks. Every day the development team has a stand-up meting. That is literary a (very short) meeting where everybody stands and tells what he is working on at what problems they encounter. We were present at some stand-ups and where able to attend a few live when we visited the development team. It works very efficient.
To cut a long story short today we had the presentation of the results of the first sprint. The team demonstrated the new functionality to us and we where able to comment. In two weeks time they have created: the first version of workflow, the ability to create comments on courses and pages and they build undo/redo functionality. They also realized some smaller items. We accepted everything during the demo, we only missed one small detail that they accidentally didn’t build. The shown functionality sparked some discussions that led to some new ideas. We will work them out in user stories and if we want we might include them in one of the next sprints. I find it quit incredible, after two weeks we this new version available on our demo server and we can actually use it.
This afternoon we had a second meeting where we discussed the planning of the next sprint, that will start tomorrow.
I find this a great way to work. You are as a principal much more involved in the process, you can steer better. A two week planning is easier to manage and is much more realistic than a planning that spans months or even years. Based on what we have seen we can (if necessary) adjust priorities and user stories for the next sprints. And if you get it completely wrong you lose two weeks at most!
Ergo: Agile works for me.