QuickStart Software Development

by Martin Roddam

What is QuickStart?

Here at the FT we have been trialling a new method (at least for us!) of beginning a software development project. Essentially, the entire team (developers, testers, product owners) assemble in a room with the aim of producing a quick and dirty prototype based off a given value statement. We also invite people from other teams who have an interest in what we’re about to do: either they’re going to use the functionality we are developing or they need to provide us with something for it to work. We call this a QuickStart session.

The idea is that we learn about complexity to a good level of detail early on, allowing us to provide reasonable, evidence-based estimates to the business.

It also has many other benefits that arise from this way of working:

1. Given the time-boxed nature of the exercise (normally 2–3 days) we get the true sense of the minimum viable product that will provide value to the business. What is it we really need?
2. Risks are well understood from the start.
3. The whole team gain a full understanding of the problem we’re trying to solve.
4. We come away with some actual usable code — part of the job is already in progress.
5. We get a well-timed injection of morale for the team — it turns out that people love working this way.
6. Cut away all the process and business as usual ‘fluff’ that gets wrapped around our daily activities and you can get a lot done in a short space of time.
7. Seeing the fruits of one’s labours very early on is appreciated by all.
8. Battle weary Tech Leads and Architects get stuck into some coding.
9. Product Owners get a clear picture of what they might get at the end.

The only downside is that towards the afternoon your crowded room starts to smell like a teenager’s bedroom :-(

Can any team make use of QuickStarts?

Absolutely! But there are some prerequisites to give your QuickStart the best chance of success:

• A strong collaborative spirit.
• All required team members involved and engaged without distraction.
• All required stakeholders or product owners in the room or readily available
• All other meetings cancelled
• All business as usual tasks postponed (where possible) or handed over to another team
• Lots of coffee and a good food supply
• A good sized and well equipped/connected room
• All team members with laptops, or at least access to one for the duration

We found that working around a table with laptops rather than large desk-mounted screens improved communication by virtue of being able to see one another across the table.

What is the role of the tester in a QuickStart?

Some might argue, “We’re not aiming for production quality code at this stage, so what good is it having a tester who is only going to slow things down?”

Well, we’re not looking for production quality code, but everyone involved wants the various components developed to work together so that there is some demonstrable functionality to show at the end of it. Speaking as a tester working in a well established team I have found the experience empowering. Being involved at the project inception, all members are able to build an excellent understanding of the problem — this allows me, as a tester, to start thinking about how I might go about testing the solution, including the process of exploratory testing which allows an opportunity to think of the “what ifs?”.

An Example

The piece of work we most recently undertook involved creating a content transformer to take Wordpress article content and convert it into a format suitable for our new publishing platform. We asked questions of the Product Owner about what type of content we wanted and what we should ignore or exclude. This allowed me to start generating test data in our test Wordpress instance. I was aiming to create data that would prove taxing for the content processing rules. This was passed to developers to be used to test their own code on a local branch of the project and would later be the basis of my own exploratory testing once that code was committed.

Pairing took place between developers, between testers, and between developers and testers. This pairing improved our shared understanding and allowed for fast feedback to developers on the functional aspects of their code. Testers helped to pull all the various microservices together through end-to-end testing and helped iron out integration/implementation issues early.

Code quality was arguably higher through this process since the activity of developer/tester pairing allows for testers to highlight the smallest of issues and have them fixed while the developer is actively working in the codebase. These sorts of issues would normally be added to a backlog and end up prioritised into the distant future. An example:

[Tester]: “Oh, by the way, it’s not affecting functionality but I noticed some additional redundant line break characters in the transformed output.”

[Dev]: “Ah yes, I see it. Good spot… Fixed!”

How to finish a QuickStart

At the end of the process we demonstrate what we have achieved and get feedback from the business. We then come away with some tasks — these are usually the complexities we encountered during the last few days plus some tasks to make our code fit for Production e.g. add our usual monitoring and alerting, bolster unit tests and so on.

Sounds perfect?

Well, not quite. We do have some ongoing discussion on how to dovetail the QuickStart period with our day-to-day process. Specifically:

• How do we easily reconcile what has been completed vs what work remains in the story?
• Do we estimate the total effort required for a User Story? Or just the remaining effort?
• How does the large amount of work completed in the QuickStart affect our team velocity? Should we care?

Final Thoughts

We recently completed our fourth QuickStart. Something which started as a trial is now fully endorsed and recognised by the wider business. We’ve also noticed the practices we enjoy during the QuickStart are enduring. Most notably:

• Increased cross-team communication and collaboration
• More frequent informal chats
• Increased pairing between developers and testers
• Lightweight means of tracking small tasks (e.g. a quick grid on a whiteboard)

We’re evolving the way we work all the time.

Having the freedom to change the way we work and feeling that the business supports experimentation leads us to question more of our daily rituals, and judging by the success of the QuickStart, change can be good.