Back to the Future using Agile and Test-Driven Development

//Back to the Future using Agile and Test-Driven Development

Back to the Future using Agile and Test-Driven Development

Do you know these guys? Maybe not, here’s a hint: they were some of the first people launched into Space. These men were part of the Mercury project launched in the 1950s by the then President John F. Kennedy. Some made it into the Gemini project that put the first men on the Moon. Little is known today about how those massive programmes were at the forefront of what is known as “Agile”.

At the onset of the Mercury project, senior officials at NASA (and IBM) thought that they needed to implement a different approach for the development of such a complex project. They were convinced that using a traditional “Waterfall” approach would be a terrible idea. A project of that size and complexity, a programme of that magnitude and importance left no room for failure. So they opted for what they called an iterative and incremental development approach where regular feedback would be embedded in their daily work, making absolutely sure they were heading in the right direction at every step. They implemented regular checkpoints, twice a day. Furthermore, they implemented a “test-first” methodology, where the development of each major module would not start until they had honed down Acceptance Criteria and Test Definition. Only then, each component was built according to these definitions.

Later in the history of software engineering, when complex programmes were written for major multi-million dollar projects, some very smart folks had the same idea: don’t bother producing a single line of code if you haven’t put the necessary efforts in understanding how that line will be tested. They called it Test-Driven Development (also known as TDD). They also implemented an approach where close feedback loops were embedded at each step of the process, helping teams flag issues early, and to continually check they were heading in the right direction, to continuously report on progress (pair-programming, daily stand-ups, etc).

TDD is not new, it’s been around for decades, and is one of the foundations of Extreme Programming, a set of software development practices that is widely acknowledged to be part of Agile methodologies.

Yet, TDD is a tradition that’s seldom enforced in today’s Agile projects.

What we often hear these days from organisations is: “We work in Agile, we use Scrum”, “we work in Sprints and do proper Sprint Planning sessions”, “we do daily stand-ups, and have sprint retrospectives”, but after taking a closer look we see Product managers / Product Owners writing User Stories in isolation, handing over to developers who work in isolation, while testers write tests in isolation (when development has already started). Many times those “Scrum” teams aren’t even co-located. They do their daily checkpoints on Skype, log off and go back to working in isolation.

Ask about whether they use TDD and you’ll often get a blank.

The result? Misunderstandings, defects, delays, meetings, more delays, and frustration. We see these teams fall back in the Waterfall way of people working in silos, handing things over, all convinced that they understood the requirements from the onset, wishfully thinking everything would nicely click together like Lego during rounds of testing.

As a result, Agile looks like it fails to deliver.

By agreeing on Acceptance and Test Definition before any development starts, Product Owners, Business Analysts, Testers and Developers, all validate that:

  • requirements have been well understood in all possible aspects by all team members
  • the end product is aligned with all the possible scenarios and use cases set by the Test Definitions

Whether you’re building an e-Commerce platform, a new CRM system, or a new mobile app, write your requirements and specifications along with complete and comprehensive Acceptance Criteria, write Test Scenarios that ensure every case is covered. Spend extra time ensuring you’ve got those things down to a tee, have your developers and testers collaborate on acceptance first and make it part of your “Definition of Ready”. Only then have your developers produce code and validate each feature they build against those tests. Even better if those tests are automated and not run manually so developers’ code can be validated promptly, something we will talk about in an upcoming article.

Be truly Agile and enforce a test-first approach to ensure your teams build the right thing, the right way, from the onset.

For more information on TDD, this resource is a good start.

By Jonathan Lhrar

By | 2017-09-01T08:46:48+00:00 November 9th, 2016|Categories: Blog|Tags: , , |0 Comments

Leave A Comment