Now 15 years old it is indisputable that The Agile Manifesto has revolutionised software development. From the simple list of principles in the Manifesto a vibrant methodology with a number of derivatives have emerged. Gradually even the most dusty compliance and legal teams have realised that Agile delivers better on cost, quality and time for everything but the most simple of software projects. The manifesto summary is short enough to list here:
For all that Agile ushered in a new era of agility and adaptability there is a fair accusation that it does not promote much more than a focus on process and communication. Teams must follow the Agile ceremonies of daily stand-ups, weekly show-and-tells and weekly retrospectives.
It offers an excellent foundation for managing the mechanics of grinding out software but this strength is also its greatest weakness. Once tickets are defined and fed into an agile sausage machine they are in the process of being done. But how do we know we are solving the right problem? How do we know there is demand for a feature? How do we continuously improve on what we already have? Agile does not pretend to offer answers to these questions but for many organisations they believe that by following Agile they have solved these problems.
Hey we’re using Agile so we are more nimble and innovative. Right?
I have observed on many Agile project that features that have little or no value to users are programmed into sprints. Promoting a collaborative environment can prevent this to some extent but with a very strong stakeholder or product owner they can still railroad features through.
This is not a criticism of Agile but more an expression that Agile offers little in terms of ensuring you are solving the right problem or at least that you have some confidence that there is demand and relevance to what you are doing.
The Agile Manifesto offers nothing in terms of how to govern projects and typically in large organisations compliance, legal and security teams will slap a large amount of process around Agile. Whilst this might be ivy choking a tree trunk Agile can and does survive this.
A bigger problem is the level of understanding in board rooms around digital. Digital has in many cases become the business but in traditional businesses the board rooms are populated by Executives who think that having a FaceTime with their grandchildren is living on the edge. Agile is just one of the buzzwords that gives executives the feeling that we are doing this right. Some organisations have recognised this defect through the appointment of Chief Digital Officers but still Agile retains a silver bullet status even though it is just a means of delivering software.
You might say that Agile was an effective optimisation by those responsible for delivering software to be able to deliver it in a more efficient and sane way. It is hard to argue that net effect of Agile has been anything but positive. Agile is strong on the mechanics of delivery but weak on anything to do with a customer. Even more progressive philosophies like Lean focus on efficiency and eliminating waste. Lean offers much in terms of how to improve a process but the foundations of the philosophy is based on manufacturing not customers.
If we were looking at the business of creating software as a whole I would suggest that we have fixed a serious defect in terms of how software is delivered. We continue to improve on how to optimise that process. But we have a new defect of where the customer sits in this process.
Whilst as technologists we might shrug our shoulders at offline businesses the fundamentals of delivering excellent digital products and services are no different from creating excellent businesses in an offline context. Without a deep understanding of the motivations of customers, the state of the market and the drivers for customer satisfaction we have little chance of attempting to solve the right problem. Businesses that just focus their digital delivery on Agile and Lean principles risk making the same mistakes that Waterfall projects did fifteen years ago.
As someone who has benefited from the sanity that The Agile Manifesto has brought to my career I am extremely grateful to the visionaries that wrote it. But as my career and software development has progressed I have increasingly come to see it as a developer focussed manifesto that supports the mechanics of delivering software. We continue to iterate on improving the processes and methodology but most if not all of these are introspective rather than reaching out to customers.
Agile has largely solved how we deliver software. But I feel we still have a lot of work to do on making the software we make customer focussed. We’ve worked hard on how we deliver a ticket but not so much on why we are delivering a ticket.
Have an update or suggestion for this article? You can edit it here and send me a pull request.
Build your own Vim statusline
Statuslines in Vim are not hard to create. Making your own means one less dependency in your life.
Custom Vim Bindings in tmux 2.4
tmux 2.4 made a significant change to key bindings. Here is how to support custom keybindings for versions before and after tmux 2.4
Using template files in Vim
Vim templates or skeletons, allow you to specify a template to be used for new files with a certain extension.