The Benefits of Agile Software Development

It seems like every soft­ware pro­ject nowa­days is agile.’ Or at least it’s said to be. So why the fuss? To un­der­stand why the mar­ket grav­i­tated to­wards ag­ile, we must first un­der­stand where it came from. Before ag­ile the main pro­ject man­age­ment ap­proach was wa­ter­fall. Essentially the wa­ter­fall method­ol­ogy means roadmap­ping all your fea­tures and com­plet­ing them in se­quen­tial or­der, with a fi­nal re­lease at the end of the pro­ject. If you’re in­ter­ested in learn­ing more about the dif­fer­ences be­tween ag­ile and wa­ter­fall de­vel­op­ment then fol­low this link.

What is ag­ile de­vel­op­ment?

The con­cept of ag­ile orig­i­nally sur­faced through the ag­ile man­i­festo. The man­i­festo con­tains 12 Principles which out­line what to pri­ori­tise dur­ing a pro­ject build. What has arisen from this method­ol­ogy is a num­ber of dif­fer­ent frame­works in­clud­ing Scrum, Kanban, Kaizen and Lean. But at its core ag­ile is a mind­set. A mind­set that helps pro­jects thrive in com­plex en­vi­ron­ments. It ties in well with prod­uct/​mar­ket fit by putting the em­pha­sis on cus­tomer col­lab­o­ra­tion (one of the ag­ile prin­ci­ples).

Benefits of ag­ile

1. Mitigates the risk of bud­get blow outs

The main crit­i­cism of wa­ter­fall de­vel­op­ment was the like­li­hood of pro­jects run­ning over­time and over bud­get. When one phase of de­vel­op­ment is re­liant on the prior phase it makes it ex­tremely dif­fi­cult to de­liver an en­tire pro­ject on time. This is es­pe­cially true in the soft­ware de­vel­op­ment in­dus­try where there are so many com­plex­i­ties and un­knowns. With ag­ile we can pri­ori­tise smaller in­cre­ments of work that don’t de­pend on pre­vi­ous work be­ing com­pleted.

2. Better prod­uct/​mar­ket fit

One of the man­i­festo’s val­ues is cus­tomer col­lab­o­ra­tion over con­tract ne­go­ti­a­tion. The key is to put the cus­tomer at the cen­tre of every­thing we do. It al­lows us to fo­cus on a prob­lem state­ment and solve it for the cus­tomer base. By build­ing in in­cre­ments we can test out dif­fer­ent so­lu­tions with­out hav­ing to wait till the end of the pro­ject to see if they work.

3. Increased stake­holder col­lab­o­ra­tion

Many of the ag­ile frame­works put a process in place for fa­cil­i­tat­ing stake­holder col­lab­o­ra­tion. Scrum for ex­am­ple uses sprint plan­ning and re­view ses­sions to en­sure the prod­uct owner and the de­vel­op­ers are aligned and work­ing to­wards the same ob­jec­tives. This also pre­vents get­ting to the end of a pro­ject only to re­alise your so­lu­tion does­n’t ac­tu­ally solve the prob­lem.

4. Get to mar­ket faster

The sooner you can get to mar­ket the bet­ter. It opens up the pos­si­bil­ity of li­cens­ing the soft­ware (and start­ing to make a re­turn on in­vest­ment), gath­er­ing cus­tomer feed­back or even us­ing the first ver­sion to raise more cap­i­tal. There is a com­mon say­ing that if you’re proud of your first ver­sion then you’ve waited too long to launch.

5. More value, less time

One of the flow on ef­fects from build­ing in in­cre­ments is that we can pri­ori­tise each in­cre­ment. Let’s say at day 1 we thought our users wanted a dash­board. But af­ter build­ing out the ba­sic ap­pli­ca­tion func­tion­al­ity we tested the so­lu­tion again and re­alised that a dash­board was­n’t needed as much as an API in­te­gra­tion with Xero. Being ag­ile al­lows us to pri­ori­tise the in­te­gra­tion above the dash­board and de­liver that to users first.

Putting a frame­work to ag­ile

Being ag­ile is a great mind­set but with­out the processes in place, it re­mains just that, a mind­set. As men­tioned above, there are many frame­works that have arisen from ag­ile. We won’t ex­plain the dif­fer­ences be­tween Scrum, Kaizen, Kanban, Lean and the in­creas­ing num­ber of other frame­works in this blog. Rather, we’ll briefly men­tion the way WorkingMouse has taken the method­ol­ogy and cre­ated a process around it.

WorkingMouse’s ag­ile process

WorkingMouse fol­lows our unique Way of Working. With ex­ten­sive ex­pe­ri­ence in the soft­ware de­vel­op­ment in­dus­try it was im­por­tant to adapt based on learn­ings from past pro­jects. The clos­est main­stream frame­work to the Way of Working is Scrum.

The most im­por­tant thing to note is that the Way of Working is never com­plete. What works to­day may not work to­mor­row. Twenty five years ago the IT in­dus­try may have been sat­is­fied with the wa­ter­fall method­ol­ogy. As I write this there are grow­ing cri­tiques of ag­ile with the for­ma­tion of new method­olo­gies. The best way to il­lus­trate the evo­lu­tion of the Way of Working is through ex­am­ples of how it has evolved in the past based on pain points.

Pain point #1 Unclear re­quire­ments

One of the very first learn­ings made was the im­pact un­clear re­quire­ments has dur­ing de­vel­op­ment. This is sim­i­lar to try­ing to build a house with­out a blue­print. Next time you think about writ­ing a list of re­quire­ments and hand­ing it to a de­vel­oper to start build­ing the ap­pli­ca­tion, ques­tion the process. The Way of Working now re­quires pro­jects to go through a scop­ing phase where all stake­hold­ers align on the re­quire­ments be­fore start­ing the build.

Pain point #2 Mismatch in ex­pec­ta­tions

While Scoping does mit­i­gate this to a de­gree there are still mi­nor dif­fer­ences in re­quire­ment in­ter­pre­ta­tion that can arise. The first step is to work closely with the prod­uct owner to catch these early. Scrum de­vel­op­ment has a great sys­tem in place for this. Working in short sprints (2 weeks on av­er­age) with a plan­ning and re­view ses­sion ei­ther side helps to catch any di­ver­gence. The other tac­tic that we added to help com­bat this pain point is to set user ac­cep­tance cri­te­ria with the prod­uct owner. This is a strat­egy used in Scrum and has helped to align ex­pec­ta­tions on a gran­u­lar level.

Pain point #3 Unrealistic es­ti­ma­tions

Software es­ti­ma­tions are a no­to­ri­ously dif­fi­cult process. It’s dif­fi­cult to es­ti­mate how long some­thing will take un­til you’ve done it. That is why there is al­ways a layer of risk and un­fa­mil­iar­ity as­so­ci­ated with es­ti­mates. Early on, we did not ac­count for this. We also did­n’t ac­count for the time spent in meet­ings (project and com­pany re­lated meet­ings). This led to a lot of late nights. To com­bat the pain point we in­tro­duced an al­lo­ca­tion fac­tor and risk fac­tors to sci­en­tif­i­cally es­ti­mate on a soft­ware pro­ject.

To re­cap, ag­ile is a mind­set. Ensure you put the right sys­tems and processes in place to be able to ex­e­cute on that mind­set day to day. It can have a sig­nif­i­cant ben­e­fit on the end prod­uct that is built. Download the Way of Working if you’re look­ing for an ag­ile soft­ware de­vel­op­ment process to fol­low.


Yianni Stergou

Marketing en­thu­si­ast and FIFA ex­tra­or­di­naire

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­pe­ri­ence

Book an analy­sis call