In this article we will explore whether agile development methodologies used by software development companies are truly agile, and if that agility is for the client or the software company itself. We will look at an alternative to agile methodologies, so we can compare, and explore what our clients can expect from the agile process when working with Matter of software. If you have any questions about this article, it’s content or are looking to start a custom software project please get in touch.
OK so what is agile development?
As of the writing of this article Wikipedia (remember it can change daily) defines agile development as follows:
‘Agile software development describes an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end users(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.’ – Wikipedia March 2018
Whilst this is a great definition let’s explore the components in more detail:
Approach to software development – to develop software a series of steps need to be followed to ensure the software meets the needs of the users (requirements) – whilst this varies between software development companies (and in fact countries) there are a few formally recognised approaches (we come to this in the next section).
Evolve through the collaborative effort – this is a critical difference between agile development and the traditional approaches – evolve suggests there is no pre-defined end-point (i.e. how it looks, feels or in fact operates). Collaborative effort suggests a working relationship where everybody involved in the software project focusses on the same goals – creating the software solution that best meets the needs of the user.
Self-organizing and cross-functional teams and their customer(s)/end users(s) – perhaps more subtle here is the focus on self-organising – agile suggests there is no one size fits all. The team should determine the best resources at each part of the development to collaborate – no large planning exercises just constant assessment and adjustment based on current needs.
Adaptive planning, evolutionary development, early delivery, and continual improvement – there is that reference to a high level loose plan that bends to the solution being built, the stage of delivery and the resources available. Evolutionary development focusses on starting with something basic and developing that in an organic way to meet the end user’s needs (often which develop over the course of the project with only high-level requirements/objectives being set at the project start). Early delivery is every customers’ wish, this references the need to deliver something tangible into the end users hands as quickly as possible and continual improvement is the feedback loop. This loop ensures the client can make comments based on the tangible software they have, and the software development company can react and adjust to close any gaps.
Encourages rapid and flexible response to change – whilst this will make most software company directors and customers alike break out in a sweat (change means delay and cost usually – right?) – in this case it’s an ethos to embrace change when change is raised at the correct time. Traditional approaches would have all requirements defined, a design completed and then the client would see their solution some time later. Agile allows the client to visualise and see their requirements realised in small structured stages (sprints to use the correct term), often this triggers a change in requirements some of which will add effort and some reduce effort. Ultimately the goal of agile is to reduce the overall effort – after all if the development effort is reduced by keeping a client at bay – that effort will be raised during testing (at which stage the development and test effort to change is considerably greater).
What are the alternatives?
Whilst there are practically hundreds of methodologies (a lot of large consultancies tend to develop their own proprietary processes) there are some common elements:
Continuous Integration – the bringing together of developed components on a regular basis to ensure they work together and reduce the risk of conflict.
Prototyping – the art of developing a section of a solution for the purposes of gaining acceptance of a solution by a customer or to demonstrate understanding of the software development company.
Incremental Development – here there are phased developments – where a larger development is broken into smaller chunks to be delivered to a customer.
Rapid Application Development – a process of prototyping and incremental development where a team works together to remove/reduce any upfront planning and design effort
Of course, different projects and solutions will require different methodologies – for example developing the software for a space station will require a structured and controlled process where rapid development probably won’t work as the software doesn’t work in isolation. In fact it’s true to say wherever there are more components for a software solution to work with that aren’t static (i.e. they are changing too) then there will be a need for more design/agreement before starting development.
We have spoken about agile so now let’s look at the other well-known methodology – the waterfall method. It is so called because the process moves from one stage to the next – with the solution passing each stage similar to a waterfall (note the subtlety here that water only travels down the process so there are no loops here). The typical stages are:
- Scoping (requirements gathering)
- Software design
- Testing (Integration Testing, User Acceptance Testing and System Testing to name a few stages)
Key differences between agile and waterfall is that for waterfall you need to document all requirements in detail, you need to understand the technical landscape the solution should work in (in detail specification) and you need a lot of planning and change control management as you work through the flow (as changes and issues will be reported and resolved but potentially they will not be included in the solution of this release)
What can a customer expect from the agile process?
So you have chosen a software delivery partner who proposes to use the agile process, this means you will save money and have an easier time right? Well hopefully yes, BUT the agile process requires a constant collaboration between the client and the software company. A lot of our clients who have the responsibility to run their business day to day (often resources aren’t allocated 100% to the projects created to support the software development) fear they will be overwhelmed with questions/clarifications and that ultimately the cost will increase (as time goes up typically so does cost) or they will make incorrect decisions.
Our best advice is to plan in regular time to allocate to the project, ensure up front and during the sprint reviews (regular status meetings) you ask what is expected of you in the coming period, what questions/decisions will you need to respond to etc. As most likely you won’t be the sole decision maker, ensuring you have clear lines to those colleagues who you need support from is critical and setting agreements around response times to ensure you can meet the promises that you will invariably make to your software delivery partner.
Understanding your needs, having a vision of the end solution and being flexible (willing to be challenged, positive in the process and comfortable with change) will ensure the process works for all involved parties. If you simply don’t have the time to commit regularly throughout the project, worry over change or can’t make quick decisions then raise this prior to starting any agile project – it could be that a waterfall method might suit you (and in turn it will suit the software company as you will all have clear expectations from the start).
So truly agile or mini-waterfall?
So should you ask for a truly agile, a waterfall or a mini-waterfall method – the answer is there is no one size fits all. Most software companies (ourselves included) will use a hybrid depending on the project – the methodology is there to provide a framework, ensure key deliverables are produced and reduce overall risk by using tried and tested processes – they shouldn’t be ignored. Here at Matter of software we use a hybrid – we have an agile process which uses a sub section of the waterfall method to deliver the sprints – this we have found gives us the ability to take the benefits of each whilst managing any risk introduced by using only one method.
When working with us we ask our clients to ensure they are aware of the demands on their team at different stages, we are experienced in supporting our clients with not only project demands but the change management impact of implementing the solution within your organisation. As with every successful software implementation this involves open communication, tolerance and willingness to change (be agile you might say).
How we can help?
Interested to hear how we can help you or your company to optimise that business process, win more business or simply differentiate yourself from your competitors – simply click here to send us your details and one of our team will be in touch for a confidential no obligation discussion.