Development of Frooly began in June 2009. Knowing a few basic and very broad objectives, three of us began planning and designing the system on scraps of paper in a cramped messy office above a hairdressers in Rotherham. Debates raged, decisions were made, code was bashed out and progress was swift; Frooly was taking shape. In these beginning stages there was no project management beyond scrawlings on a whiteboard and no development methodology in place but, like any software project at this embryonic stage, there was little need for it. Objectives were simple and obvious (“let’s get it showing something on screen”, “we need to be able to add text, upload images”), communication was simple and free-flowing, testing was a synch –commit a bug on a small system like that and it takes mere seconds for the room to erupt in remonstration – and the management team (our “project owner”) were wandering in and out, in constant discussion with the developers.

At this early stage of its life, a software development project is the very essence of Agile:
  • Individuals and interactions over processes and tools - Check
  • Working software over comprehensive documentation - Check
  • Customer collaboration over contract negotiation - Check
  • Responding to change over following a plan – Good god Check
Not that we were giving even a second’s thought to agile or any other methodology at that point, we were just getting on with the task at hand and it was working wonderfully, great software getting written incredibly quickly.

However, as the team grew to four, the software grew in complexity and the business grew in maturity; it wasn’t long before our approach began falling short.

Around three months into the project, a working prototype was in place and the management team were getting a clearer idea of the direction they wanted to go. Objectives and requirements were changing seemingly by the day, our adhoc discussions would form the basis of developments and the results of those developments were increasingly met with responses like:
“Oh, I thought it was going to work like this...”
“So, you can’t do this with it?”
and “I didn’t think it was going to be able to do that.”
This situation persisted and grew for the next few months and was increasingly frustrating for all involved. Frustrating for the management team because it felt like they weren’t being listened to and frustrating for the developers because it felt like their hard work was going unappreciated.

Our effectiveness as a development team was gradually deteriorating and with hindsight it’s easy to see why. There was no sudden moment of clarity; various attempts to improve things were put in place with varying degrees of effectiveness: project management systems, more regular meetings, and more paperwork; but in the end it was a change in the ethos, approach and processes of the whole company that was needed. The deteriorating effectiveness of the development team was just a small part of that wider change which needed to happen: Frooly needed to go from being a small project in a couple of rooms above a hairdresser’s to being a software company with a clearly-defined core product.

Agile to the Rescue

By this point, Frooly had moved to a larger managed office in Sheffield city centre, taken on two more developers and begun its first closed beta. At the same time, I was reading Mike Holcombe’s brilliant book ‘Running an Agile Software Development Project’ and the situations and problems he talks about in that book spoke directly to what was happening at Frooly. Certainly I was not new to Agile, I had been a follower before, but it was my first experience planning and implementing an Agile methodology myself.

Usually when books and articles are extolling the virtues of Agile, it is invariably from the perspective of its use in a large existing organization, unseating an older, long-established methodology such as the waterfall model and the many improvements and efficiency savings it offers over the old way of doing things. At Frooly, my challenge was not to justify an Agile process over the waterfall model or any other approach, it was to justify implementing any kind of a process at all, since we had none.

Initially, management was reticent to accept the changes I was pushing for, this was a management team that had not come from a software development background and was not used to the particular problems we were experiencing, and as a result the solutions they came up with to the problems we faced invariably lead to further problems. For example, when developments were continually overrunning their deadlines, they responded, as one would do in a non-software dev context, by applying more pressure and incentivising deadlines. This however lead to sloppy, buggy code, since the issue wasn’t with the speed at which the developers were working, it was with requirements not being clearly defined and time estimates being effectively plucked from thin air. (Ah, hindsight...)

Frooly’s management team was concerned that the processes I wanted to put in place would unnecessarily slow down development; this was not helped by the damage done to their faith in the development team by the frustrations they were experiencing in its declining effectiveness.
Looking back now, I could’ve pushed harder and affected my changes sooner but who was to say that my approach would be more effective than any other? I was far from confident that what I was proposing would in fact be the answer to our problems any more than any other solution. However, after some (if not quite enough) pushing on my part, the continuing problems and some changes in the management team itself, it was agreed to give it a go.

Our Solution

The problem Agile sets out to solve is how to hold on to the effectiveness, speed and dexterity we see in the initial stages of the project when the product becomes more complex, testing must be more thorough, when there are complex dependencies, more comprehensive requirements and more people involved in meeting them.

The pace of change was not quick, it’s still happening now and I certainly hope it will continue to happen, but once in place the improvements were vast and noticeable.
Every morning the development team gets together for a scrum (well, most mornings!) to discuss our progress and objectives, share ideas and agree the direction of the software and our methodology.

Each week or so, the management team meets to discuss the upcoming developments, review progress and decide priorities. For some time, these meetings would be long, unstructured rambling beasts that would eat up hours. To address this, clear goals for the product and the business were established and proposed developments were simplified and formalised into a Pitch document, which could be submitted by anyone, and contains a few standard questions about the feature.
Meetings were now a simple process of going through the pitches, and evaluating each one against the product and business goals. As a result, the meetings proceeded much more swiftly, more was achieved and the meetings were required less frequently.

The particular features management wants to move forward with are turned into requirement specifications, which sound long and rambling, but in fact are just a short series bullet points in the form for user stories which describe the completed development. They look like this:
  • Users can login using their Facebook account when they have never logged in before and a Frooly Account will be created for them
  • Users can return and login again using their Facebook login and gain access to their existing Frooly account
These are signed off by the development manager (me), the project manager and the person who originally pitched the feature. This solves the problem which was probably Frooly’s biggest, of each person having a different idea about what was being developed.

A developer is then tasked with taking each user story on the requirements spec and summarizing the series of tasks which must be completed to meet that requirement (e.g. create a stored procedure, alter a class, etc...) along with a time estimate for that task. All of this is done in our project management system - TargetProcess, which will add up the total number of developer hours required for each feature, which helps in the management team’s planning and addresses the issue we had with unrealistic time estimates being attributed to developments.

New developments are grouped into a release which is deployed to a staging area, subjected to a rigorous test plan before being signed off and deployed.


At the moment we’re seeing new releases going out every three weeks or so (unless there’s a particularly nasty bug to fix), and they are more timely, more bug free, they meet requirements and the needs of the business - and for all our concerns about the process slowing down development, we’re finding they’re developed, tested and released far more quickly -which is what we were aiming for, getting back to great software getting written incredibly quickly.

We’re not done yet either. For a start we’re looking at ways of making our development process more test-driven, improving how our design team’s work is organized and a bunch of other improvements to boot – I’ll post more of our experiences on this blog.

Learnings from this experience:
  • As developers, we must all be ready and able to properly spec and organize our own developments - it is as much a part of our job as tapping out the code
  • We must be aware that as a development project grows, its organizational needs will change and we must be ready to respond appropriately to that change
  • We must be constantly looking for and discussing ways to improve our development process
  • We must be staunch vocal advocates for that organisation and continuous improvement; it is unreasonable to expect non-technical managers to intuit and organize the unique processes required for good development to work - it’s all on us.
-Any ideas and suggestions as to how we can further improve are absolutely welcome!