CLOUD MIGRATION

The Jump to Using Agile for Application Development

Agile de­vel­op­ment has quickly be­come the favoured method of pro­ject de­vel­op­ment in the work­place. It has re­placed the old ‘wa­ter­fall’ or se­quen­tial method­olo­gies for de­vel­op­ing ap­pli­ca­tions be­cause it of­fers teams the abil­ity to adapt and re­spond to un­pre­dictabil­ity. This qual­ity has al­lowed it to now be­come one of the most ef­fec­tive processes for both ap­pli­ca­tion de­vel­op­ment and cloud mi­gra­tion. However, the el­e­ments of Agile need to be fully un­der­stood, tested and adapted within your busi­ness to achieve the best out­come from the soft­ware de­vel­op­ment process.

What Is Agile?

The ag­ile process in­volves de­vel­op­ing in in­cre­men­tal, it­er­a­tive work ca­dences known as sprints. These work by ab­bre­vi­at­ing life cy­cles of ap­pli­ca­tion de­vel­op­ment into smaller cy­cles and tasks. Each cy­cle in­cludes own processes of de­sign­ing, build­ing and test­ing. At the end of each cy­cle which is usu­ally around 2 weeks - the di­rec­tion and progress of the ap­pli­ca­tion is as­sessed. The as­sess­ment should be com­pleted with a high level of stake­holder en­gage­ment to gain the most in­formed feed­back which will help achieve the best fu­ture it­er­a­tions and fi­nal prod­uct.

Image

There is how­ever a ma­jor dif­fer­ence be­tween this method­ol­ogy and the old wa­ter­fall process. Waterfall is based on the as­sump­tion that you can de­scribe the end prod­uct to your team at the start of de­vel­op­ment and build a com­plete prod­uct from this brief. Agile works on us­ing analy­sis of feed­back to help you adapt to nec­es­sary changes and avoid the prod­uct be­com­ing ir­rel­e­vant by the time it is com­pleted. This dis­tin­guish­ing fea­ture is im­por­tant be­cause ini­tial plans can of­ten be­come ir­rel­e­vant due to a high risk of ei­ther the ar­chi­tec­ture or re­quire­ments chang­ing be­fore the ap­pli­ca­tion has been com­pleted. Both the wa­ter­fall and se­quen­tial method­olo­gies would not al­low you to then make the nec­es­sary al­ter­ations un­til the pro­ject is com­pleted, wast­ing valu­able time and money. The point of Agile de­vel­op­ment how­ever, is to make as­sess­ments in­cre­men­tally dur­ing de­vel­op­ment so you can adapt to any of these busi­ness changes as you build.

The Benefits Of Being Agile

The use of this ap­proach will hope­fully re­sult in a re­duc­tion to both de­vel­op­ment costs, and the time spent mar­ket­ing, which is ben­e­fi­cial both to the soft­ware de­vel­oper and the pur­chaser. These are re­duced by the it­er­a­tions over­lap­ping the work on de­vel­op­ing the soft­ware with gath­er­ing the re­quire­ments; there­fore po­ten­tially elim­i­nat­ing the con­cept known as ‘analy­sis paral­y­sis.′

Additionally, the lim­ited work cy­cle gives stake­hold­ers an op­por­tu­nity to build the right prod­uct. Through pro­vid­ing the op­por­tu­nity to re­plan - as op­posed to com­mit­ting to mar­ket a piece of soft­ware that has­n’t even been writ­ten yet - ag­ile em­pow­ers teams to op­ti­mise value through­out de­vel­op­ment, and there­fore hope­fully stay ahead of the mar­ket. This is be­cause up­dat­ing a pro­duc­t’s mar­ket rel­e­vance en­sures it is pur­pose­ful when the time ar­rives to re­lease it to con­sumers. In turn, main­tain­ing the pro­duc­t’s rel­e­vance and qual­ity will en­sure the best re­turns on your in­vest­ment.

How To Be Agile

After work­ing with a form of Agile for over 10 years I’ve learnt a few lessons re­gard­ing its im­ple­men­ta­tion. Primarily I’ve dis­cov­ered that while the Agile method­ol­ogy has be­come in­te­gral to our de­vel­op­ment process at WorkingMouse, el­e­ments of it have to be adapted. Here are 5 lit­tle pieces of ad­vice I would of­fer to any­one us­ing or ready to use this method­ol­ogy.

1. Customise Agile

No com­pany ever uses pure Agile; in­stead this is a method­ol­ogy that should be cus­tomised to fit the needs of the busi­ness. When you re­search Agile you’re likely to re­turn with a pre­scribed work­flow de­scribed in lots of spe­cific de­tail. However, it would be ridicu­lous to fol­low this process ex­actly. Businesses are unique and will vary in terms of the peo­ple, work en­vi­ron­ment and goals. Therefore it would be un­re­al­is­tic to ex­pect there to be a generic method­ol­ogy to fit every busi­ness. That’s not to say that you should im­me­di­ately scrap the parts of Agile that you want to avoid, but you should be cus­tomis­ing the process based on ag­ile un­der­stand­ing and ex­per­i­men­ta­tion.

2. Variable Over Fixed

Though there will be many ar­gu­ments for ei­ther side, I can safely say I pre­fer to use vari­able length sprints as op­posed to fixed length. This does mean mov­ing away from the most com­mon Agile ap­proach - Scrum - but it also re­sults in a num­ber of ad­van­tages. The en­tire pur­pose of Agile is to al­low for vari­a­tion and un­pre­dictabil­ity. Variable sprint lengths and the Kanban method­ol­ogy al­low you to ad­just your goals for any un­ex­pected oc­cur­rences. For this rea­son it may be more ap­pro­pri­ate to con­sider mov­ing away from Scrum.

3. Longer Sprints

Generally, Scrum rec­om­mends 2 week sprints for the Agile method­ol­ogy. However, in my ex­pe­ri­ence this is far too short of a time. 2 weeks lim­its the time avail­able to ob­tain valu­able feed­back and utilise it to im­prove for the next sprint. Furthermore, de­vel­op­ers given only 2 weeks to meet a tar­get will of­ten be­come stressed or at the very least fa­tigued. This in turn neg­a­tively af­fects the qual­ity of the code they will pro­duce. While it is im­por­tant to work in sprints, the time pe­riod for these should be de­ter­mined in a dis­cus­sion with your de­vel­op­ers so that it is set at a re­al­is­tic and achiev­able goal.

4. Agile Compliments Lean

Combining these two method­olo­gies is be­com­ing more com­mon. One com­pany has even sug­gested that its cus­tomers get to mar­ket 50% faster and are 25% more pro­duc­tive when they em­ploy a hy­brid of Lean and Agile de­vel­op­ment meth­ods.

Working with Agile I have come to re­alise it is com­pli­mented by im­ple­ment­ing lean ide­olo­gies. Even though the eval­u­a­tion process at the end of the sprint is quite dif­fer­ent, they still work to­gether in the in­no­va­tion process. Generally, Agile is at its most ef­fec­tive for small groups of de­vel­op­ers, but el­e­ments of lean are be­com­ing valu­able in adapt­ing it to suit big­ger pro­jects. In a lean sys­tem the work is bro­ken into a set of value streams where the out­put of one value stream leads to oth­ers. A larger pro­ject can there­fore ap­ply Agile by cre­at­ing value streams to or­gan­ise de­vel­op­ment teams in se­quen­tial and par­al­lel streams of work so that at the end of each it­er­a­tion, you get a new ver­sion of the prod­uct.

5. Innovate the Process with Software Bots

Now, with the in­tro­duc­tion of soft­ware bots in the in­dus­try we are able to gen­er­ate on av­er­age around 90% of the tar­get code. The last 10% is still hand­crafted by a soft­ware en­gi­neer. The re­sult of this is a sig­nif­i­cant re­duc­tion in time spent on de­vel­op­ment and test­ing. This in­crease in pro­duc­tiv­ity can then shorten the time spent on each it­er­a­tion and trans­fer to a real cost sav­ing for busi­nesses.

Agile method­ol­ogy is con­stantly be­ing de­vel­oped through in­no­va­tion. WorkingMouse has im­proved its util­i­sa­tion of Agile through im­ple­ment­ing soft­ware bots dur­ing the de­vel­op­ment process. In the past, each it­er­a­tion in the Agile method­ol­ogy ran cy­cles of the same processes. These cy­cles split soft­ware en­gi­neer­ing into three re­peated ac­tiv­i­ties: busi­ness analy­sis, de­vel­op­ment and test­ing.

How Agile Compliments Cloud Migration

If your busi­ness is op­er­at­ing on legacy soft­ware, it is likely at some stage you will de­cide it is time to be mov­ing to the cloud. However, if you don’t break the pro­ject down into it­er­a­tions or sprints, you will be sorely dis­ap­pointed. Don’t go for an en­tire sys­tem rewrite in one go. More to the point, you won’t be able to rewrite your sys­tem in one go! If you are cur­rently run­ning users on your legacy sys­tem then a suc­cess­ful changeover to the cloud will need to be grad­ual and in­volve feed­back to mea­sure its ef­fec­tive­ness. Doing so will help you avoid nu­mer­ous chal­lenges as­so­ci­ated with the mi­gra­tion process such as the cul­tural chal­lenge and the tech­ni­cal chal­lenge. To learn more about soft­ware mi­gra­tion chal­lenges head here.

Overall, ag­ile de­vel­op­ment is be­com­ing an in­te­gral part of suc­cess­ful soft­ware de­vel­op­ment. This is be­cause through col­lab­o­rat­ing with con­sumers you know that your busi­ness is de­vel­op­ing the most rel­e­vant prod­uct for your mar­ket. If you can cus­tomise this method­ol­ogy to help your busi­ness in­no­vate, you can po­ten­tially save your busi­ness both time and money while max­imis­ing prof­its.

ABOUT THE AUTHOR

Eban Escott

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