Agile. The right approach for your project

By John, Eastpoint Software on 30 January 2019

At Eastpoint, we use agile as our approach to software development projects. Here I take a look at why we feel it’s right for our client’s projects.  

What is agile? 

Agile came out of the need to find a better way to create software. The Agile Manifesto defines a set of priorities or strategies as guiding principles for how to develop working software to meet needs. This was rather than follow more established routes to create software such as waterfall – which often fell short.  

The waterfall process takes a project through a set of distinct phases, each completed in their entirety before moving to the next. Design, for example, might happen after requirements capture, but before development. The entire design is finalised before a single line of code is written. 

At a high level, waterfall is a “predict and control” approach whereby the general assumption is we know precisely what we will need to build and can predict precisely how we will build it. That allows us to then go about building it uninterrupted. 

Agile takes the “sense and respond” approach (scrum calls this Inspect and Adapt). Acknowledging that as a project develops, we learn more about the customer needs, the technical challenges, and the capabilities of the software we are building. We quickly learn and adapt to working in a way that suits your preferred style, and regularly review and tweak to maximise our collective productivity. 

It recognises the variability of plans and embraces the need for flexibility in change. 

Further, detailed planning is deferred to a point later in a project – the point at which most will be known about the requirements and their context. 

The four tenets of The Agile Manifesto are: 

  • Individuals and interactions over processes and tools 

  • Working software over comprehensive documentation 

  • Customer collaboration over contract negotiation 

  • Responding to change over following a plan 

Are we just mitigating for ineffective knowledge/research and poor planning? 

On the face of it, this can all sound like development teams trying to get out of firm commitments to deliver X in return for Y. Surely we can plan to enough detail, and add enough contingency to know how much this will cost…? 

Anyone who has even written a big plan, knows that there is a lot of detail that cannot be accounted for.  

“plans are worthless, but planning is everything” 

A waterfall project is the equivalent of sending an unmanned rocket to the moon - when you know precisely where you want to get to, all the obstacles that you’ll need to overcome, and when you really don’t have the luxury of making changes to your plan on route. We can program the path, fuel the engines, and set it on its way, hands off the steering wheel. Eyes closed if you wish. 

The reality of fast paced software development is closer to the experience of driving a car. With each corner and junction you reach, you either have a clear path ahead, or a double decker bus to circumnavigate. If you have devised a detailed plan beforehand, and stick to that religiously, the double-decker wins. How far would you make it driving your car in town with your eyes closed (hint: please don't try)? 

Agile gives you the ability to adapt to what you find, be that changing business requirements, unexpected technical complexities, or new technologies becoming available to aid the project. 

This does not dismiss the importance of planning. But it respects the reality that plans, however good, do change. Responding to that change is critical to creating successful software products. 

The really tough bit: The commercial agreements 

The biggest challenge with agile as a service (e.g. when your company hires us to work on your awesome product idea) is that a step into agile is often considered a step into great uncertainty.  

I’ve heard many variants of “you want us to agree to spend x thousand pounds, with no guarantee of what we get in return”. And that’s understandable. If you buy a car, or a house, or an iPhone, you get all sorts of assurances about what you’ll get for your money.  

So why isn’t this the case when we buy hand crafted software products?  

The truth is, you can get those types of assurances. But it’s generally either expensive to achieve, or not true. To know precisely what will be built, how it will be built, when it will be built by, and how much it will cost, requires a comprehensive understanding and contractual documentation of many, many things. We must comprehensively understand every user, every scenario, every device, every network connection, and every operating environment and so on in advance. We not only need to know about that now, we also need to predict what they will be like in the future: when the product launches, and for the lifetime of the product. 

Plus, we need to be 100% right about everything we have predicted. 

Sometimes predict and control is important. If the customer has a comprehensive specification and needs to know precisely what they will get (and probably how much it will cost too, I’m thinking safety critical control systems here like the auto-pilot on a 747), then in that case you probably need a watertight contract about what will be built to a high degree of precision. But just coming to that agreement is an expensive endeavor. 

Suffice to say, we’re not working on control systems for 747s. We’re working in deep collaboration with ambitious companies, with whom we can engage closely with (along with their end users) to build world-class, rapid-growth web and mobile products. We excel when working based on a relationship of alignment, transparency, quality, expertise and relentless execution. 

I wholeheartedly believe that deep and open collaboration creates the best possible software. It enables you to respond to the challenges and changes that you uncover, as opposed to investing in comprehensive plans when we all know those plans will change.  

Agile is the right way for all the businesses we are fortunate enough to work with.