Agile makes me think of the agile attribute used in role playing or when discussing comic book characters (e.g. Spider-Man). Agile in Software Engineering, and business, terms is very similar in that it is a mindset that helps deliver small incremental changes quickly. Like Spider-Man using several small quick jumps / web swings to get from A to B to C to D, rather than Hulk using one large jump to go from A all the way to D.
In February 2001 the Manifesto for Agile Software Development was created at the Snowbird resort (Utah, USA). This was not the start of Agile, but was a big momentum moment for Agile. The manifesto said:
Manifesto for Agile Software Development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Although the items on the right (in italics) are important, the manifesto writers gave more value to the items on the left (in bold). The manifesto and authors can be viewed at https://agilemanifesto.org/ .
Agile: Faster and Better?
So how does a mindset make something faster and better? Using the Spider-Man / Hulk example. So Spidey and Hulk are chilling out when the “Avengers Assemble” call comes in.
Spidey jumps into action and starts swinging towards the action. His agility (and spider-sense) help him quickly avoid an energy attack on route to location B.
Hulk uses his brain (let’s assume it’s one of the times Banner’s brain has control of Hulk’s body) and figures out how much energy to use to jump from A to D. He launches himself into the air on the correct trajectory towards D when, POW, an energy blast knocks him from the air back towards A. He was unable to dodge the attack as was already in motion.
As Spidey starts to leave location B he spots an several foes engaging in combat. As he’s already at B he can quickly engage.
Hulk has launched himself again from location A, he can see the action at location B but is unable to assist as he’s heading over (high above) it towards D.
The heroes’ comm card chirp, the foes have left location D and are at location C. Spidey can pivot quickly to the location once finished at B. Hulk is still mid-air wondering if next time he should just use smaller jumps.
Hulk lands at location D, he’s very angry now. He prepares to leap again, someone is about to get smashed. Spider-man is nearly at location C. The comm card chirps again, “Avengers Disassemble”. Hulk didn’t get to smash anyone, spent more time planning and jumping then stopping foes and didn’t even get to the final location. He prepares for another jump and heads back to location A. Spider-Man missed the final battle but on his way back to location A, he passes through location B and rescues a cat from a tree.
Agile is about quick movements to deliver the Minimal Viable Product (MVP). That MVP may not have all the bells and whistles (features) but it does the job, and then a new feature can be added as the next small step. Then another small step, another feature. And so on. If the project is cancelled or the product no longer needed then it can still mean a MVP may be available and the engineers may have achieved something in producing the MVP.
In the example this is represented by Spidey not having to get all the way back from Location D, unlike Hulk whose planning got him to Location D. Hulk’s planning and jump may get him all the way to Location D, but Location D is no longer the final destination then Hulk as spent time and effort to product nothing but an angry Hulk.
Spidey dodged an energy blast, got to stop some foes and rescue a cat. This represents responding to change. Spidey was using small quick movements so could respond quickly. Hulk was using one large planned out movement so got blasted (planning for unknown variables in a project is hard) and then missed any chance of smashing as could not quickly change course once on route.
All of the above is a fictional example but I’m sure most people that have been involved with a project or development have seen issues around unexpected events derailing work, change requirements happening at the last moment or even the decision to scrap a project / development as the customer now wants something else.
Is Agile Cheaper?
Imagine a small company approaches you, then want a web store. They have been a “bricks and mortar” shop for years with thousands of shoppers. They want the web store to be secure, have several sections, promote objects, sign in with social media accounts, email updates on stock, track what customers view / buy and make suggestions.
One approach to this is: time with the client outlining the requirements and what is / is not included. Spending money to purchase infrastructure (physical or cloud) to support a web frontend and a database backend. Spending time getting the design just right with the client. Creating the social media accounts, configuring the APIs and connecting everything together. Spending time with the client to outline each alert metric and where it should go, then building those metrics into the system. More time and effort creating algorithms to track customers and make suggestions, using fictional data or data from a competitor. After several weeks the product is ready, the client has spent a small fortune, you’ve spent a lot of time / effort and the site launches.
The Agile approach would see you and the customer discuss what the MVP is, and then fire up some pay-as-you-go cloud infrastructure to create just a basic web store front end / database backend. Does the client like the design, probably not – let’s change it with their feedback. Do they like V2, no. Let’s change it again. Once they like it, let’s add some security and launch. Does it have all the features they wanted, no. Does it allow customers to shop online, yes. What does the client think the next feature they want is? Add it, and so on.
On the initial launch it quickly becomes apparent that the client’s customer base is very niche and doesn’t really shop online. The client is also struggling managing social media accounts and refining algorithms to make customer suggestions. So the client wants to scale back.
With the original approach these drawbacks appear after everything has been built and deployed – so thats time and money spent on items not really needed, and time/money lost waiting for them to be implemented before the site could be launched.
The agile approach launches an MVP and then adds features – so it launches quickly and if a feature becomes unneeded then it’s not impacted on the launch cost.
Side-Note: I’ve mention Spider-Man, Hulk and The Avengers in this blog. Just a side-note to say, all of those belong to Marvel (https://www.marvel.com/).
GeekTechStuff 