Way of Working

Overview

The Way of Working is a recog­ni­tion that the soft­ware de­vel­op­ment in­dus­try is­n’t per­fect, and it’s un­likely to ever be. There are con­stant risks that threaten to de­rail a pro­ject at any mo­ment. Rather than watch­ing the news cy­cle of over-bud­get, over-time IT pro­jects re­peat, we be­lieve that with the right tools and tac­tics we can help com­pa­nies de­liver suc­cess­ful soft­ware pro­jects.

Through our ex­pe­ri­ences and learn­ings in real-world pro­jects, we have cat­a­logued what works and what does­n’t work in the form of processes. These processes un­der­pin every­thing we do. It cre­ates a plat­form to share our ideas with our teams, cus­tomers and any­one else de­vel­op­ing soft­ware. We be­lieve this level of trans­parency and open­ness is in­te­gral to guid­ing our cus­tomers, com­peti­tors and any other or­gan­i­sa­tion along the soft­ware de­vel­op­ment jour­ney.

The Way of Working be­gan as a de­fined process around the ag­ile de­vel­op­ment frame­work, which has slowly grown into its own set of prin­ci­ples, tools and guide­lines. Where the ag­ile method­ol­ogy sets out a vi­sion, the Way of Working cre­ates a more de­tailed frame­work for de­vel­op­ment teams to fol­low. Broadly speak­ing, the Way of Working processes and prac­tices have been ap­plied to:

• Develop be­spoke web and mo­bile ap­pli­ca­tions
• Migrate legacy soft­ware
• Maintain and en­hance ex­ist­ing prod­ucts
• Develop with teams of 3-9 peo­ple
• Release pro­jects fre­quently
• Sustain and sup­port pro­jects and their cus­tomers

Every soft­ware pro­ject has four key phases: Brief, Scope, Development and Support. Projects will nav­i­gate these in dif­fer­ent ways, and it is not de­signed to be treated as a lin­ear process. The strength in this process is its abil­ity to adapt to dif­fer­ent use cases, while still main­tain­ing a re­li­able and con­sis­tent process to guide the way.

While the Way of Working has been de­signed for soft­ware de­vel­op­ment agen­cies work­ing on ex­ter­nal cus­tomer pro­jects, the same prin­ci­ples and tools can be ap­plied to in­ter­nal de­vel­op­ment pro­jects.