Last semester we learned a lot about agile practices. It stressed the importance of being able to embrace change, deferring the design decisions until the last possible moment so that they can be made in light of the experience gained through spike work, talking to the on-site customer, and so on.

The idea of agile is that the cost-of-change curve is made shallower. Customers are happy because it’s never too late to tweak a feature, and developers are happy because they’re not expending lots of effort into writing up requirements specifications, designing UML diagrams, and the like.

Numerous examples were cited of high-profile, multi-million pound software systems going exponentially over budget or failing to deliver at all, as a result of following the antiquated Waterfall model. We laughed at the suggestion of using a BDUF (big design upfront) methodology in our major projects: we were now agile developers and could nimbly build incredible systems without being held up by dull and costly processes such as documentation.

However, we should be able to adapt our choice of methodology to the project at hand, not the project at hand to our choice of methodology. And, looking at my project impartially, I think it really is best suited to a more plan-driven approach.

Heresy!

I can hear your metaphorical gasp, but let’s look at the facts:

• I’m building an Online Dispute Resolution system. Other systems like this already exist. Until it comes to the maritime collision logic, my codebase won’t be breaking new ground or reinventing the wheel. There’s already a bunch of fairly straightforward features that can be formalised in advance to be taken into account in the design.
• There’s a heavy emphasis on law and following processes correctly: my system cannot be seen to be favouring one party over another. It is absolutely essential that my system does not violate any of the rules of ODR – and therefore it is essential to document these rules in the requirements specification, for traceability and accountability.
• I have a law contact (Konstantina) who I am able to meet perhaps once every two to three weeks. This is not nearly often enough to constitute as an “on-site customer”. It’s not even often enough to meet and prioritise user stories, since even when we do meet our time is limited and there are other items on the agenda to discuss.
• Finally, the process of gathering requirements, creating a design, and implementing and testing a substantial software system is still somewhat new to me. I have experience through freelance work I’ve done through my company, and through various projects at the BBC – but having a design and a plan is a comforting safety net.

The above points don’t disqualify agile practices from my project completely. I’m very keen on the agile principles of TDD, continuous integration, regular releases and merciless refactoring, and am actively applying these principles (with the exception of regular releases, which I’ve not had time to investigate at this stage in the project).

Thus, my approach is a hybrid one of Waterfall and Agile: I have a requirements specification through Cucumber features, use-case diagrams, etc, and some up front design such as the database schema; for the implementation I’m switching to a business-driven, test-driven approach that utilises the best of the agile processes (but are not mutually exclusive from the Waterfall model).

Development Methodology versus Project Management

So far I’ve been speaking about my choice of development methodology, each of which has a traditionally associated project management approach. Waterfall projects tend to use gantt charts to plan progress, whereas agile approaches tend to use sprints to plan individual iterations. As I’m using a hybrid development methodology, should I be using a hybrid project management methodology?

My project management approach so far has been somewhat ad-hoc. I’ve been using my own installation of JIRA to plan collections of features to be completed by arbitrary deadlines, and GitHub issues to document other things that need to be added but are not of an immediate concern (essentially my product backlog).

Apart from a goal to have the core ODR platform ready in time for the mid-project demonstration (after which I can concentrate solely on the maritime collision business logic module), I have no specific milestones. Then again, if “Have features X, Y and Z ready be the 5th March” is not a “proper” milestone, what is? How does translating a JIRA ticket to a sprint or a gantt chart make the milestone more “real”?

Admittedly, it’s been difficult to monitor progress using JIRA alone. Without looking carefully at my git commit history, I couldn’t be much more specific than “I started coding roughly three weeks ago, and now here’s where I’m at.” Dividing my work into sprints would let me easily say “I’m at version 0.7, and last week I added the following features.” It’s difficult to measure my velocity using my current approach as it means I have nothing to feed back into future ticket deadlines other than my own estimates.

I’d have a ticket saying “Finish feature X, Y and Z”, but the deadline would arrive and I’d only have completed feature X and half of Y. I’ve now improved my JIRA approach slightly be setting more self-contained, achievable goals: “Feature X” by one deadline, “Feature Y” by another. These are single units of work that can be encapsulated in their own branches and merged with the master.

A higher level overview of my project timeline, in the form of a gantt chart or sprint plan, could prove useful and give me an early warning if I’m going off track in terms of hitting my project milestone. I recently bought a whiteboard, so may end up using that before making a digital copy for the purposes of my final report.

Project updates

With my development methodology explained, and my project management approach at least touched upon, here’s a list of what I’ve been up to:

• Met with my supervisor and Alex last Thursday and showed them the first prototype of the system. They seemed happy and impressed with my progress.
• As a side note, it’s taking me quite a long time to add features whilst still keeping the system thoroughly tested. I had expected this to speed up once the underlying framework and utility functions had been sorted – but that’s for another blog post.
• Since last Thursday, I’ve added dispute summaries, refactored the system and added tests, and am currently on a train back to Aberystwyth (having been in London all week), halfway through creating the Lifespan Negotiation feature. I hope to have this and the Lifespan Renegotiation features finished today.
• Tomorrow I’ll work on Inter-Agent Communication within a Dispute.
• On Saturday I hope to add the “Choosing a Mediation Centre & Mediator” functionalities.
• On Sunday I hope to sort out the communication aspects of mediation (i.e. Agents A and B cannot talk to one another until Mediator proposes round-table communication, etc).
• I’m planning on automating deployment to AWS as my work for Monday, giving stakeholders access to a beta version of my ODR platform through an IP address.
• Anywhere from Monday 9th until Friday 20th March I could have my Mid-Project Demonstration. Assuming a midpoint of Monday 16th March, I should be in a good place in terms of project completion, with the core ODR platform complete. I can then concentrate on the exciting bit: the maritime collision module.