SOFTWARE DEVELOPMENT

What is Agile Software Development: How to Start with a Problem

This ar­ti­cle is for any­one con­sid­er­ing or prepar­ing to be­gin a soft­ware de­vel­op­ment pro­ject. It in­tends to show you how to start with a prob­lem-dri­ven ap­proach against a planned or tra­di­tion­ally lin­ear plan. The con­text of this will be shared through our learn­ings and ex­per­i­men­ta­tion over nu­mer­ous soft­ware pro­jects.

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

Agile soft­ware de­vel­op­ment is a method of build­ing soft­ware that fo­cuses on de­liv­er­ing value of­ten and early. It has gained pop­u­lar­ity over the past 15 years and for many com­pa­nies and soft­ware pro­jects, has be­come their de­fault method­ol­ogy. The key ben­e­fit of ag­ile is that it en­ables you to test and val­i­date the soft­ware early - en­sur­ing that feed­back is fed back into the later stages of the soft­ware build. Contrast this to the wa­ter­fall method­ol­ogy where soft­ware is only used and tested once it’s finished.’

As a Web and Mobile app de­vel­op­ment com­pany WorkingMouse uses our Way of Working as a func­tional guide on how to de­liver Agile pro­jects. At the start of 2019, we ob­served a pat­tern of lower cus­tomer sat­is­fac­tion at the be­gin­ning of our scope process (this is where we com­pre­hen­sively de­sign and doc­u­ment the ap­pli­ca­tion to be built).

To ad­dress this we de­cided to ex­per­i­ment in im­prov­ing our Brief process. This im­me­di­ately pre­cedes the scope and ad­dresses the so­lu­tion at a high level. The out­come from this has been a change to our Discovery Workshop process which we call starting with a prob­lem.’

Old Approach

To fully com­pre­hend the value de­liv­ered in chang­ing the process it is im­por­tant to firstly un­der­stand the old Brief process. The old process in­volved cap­tur­ing what we de­fine as a list of Epics’. These are large vol­umes of work that could then be bro­ken down and pri­ori­tised into smaller User Stories’ dur­ing scop­ing. This es­sen­tially amounted to an un­val­i­dated wish list based purely upon a sin­gle prod­uct owner vi­sion. We found scop­ing from this was tak­ing us too far into a pro­ject and its as­sumed so­lu­tion.

The is­sues that came from the old ap­proach were:

  • Several pro­jects fail­ing to truly cap­ture cus­tomers needs and pro­vide a vi­able so­lu­tion to their end-users.

  • Differing ex­pec­ta­tions be­tween epics at the Brief stage and epics at the Scope stage.

  • Scoping and build­ing unas­sumed and un­val­i­dated work.

  • Larger scope which ul­ti­mately takes longer, lead­ing to larger es­ti­ma­tions, pro­jects and de­liv­er­ables.

  • Scoping teams felt they were flesh­ing out a wish list into a prod­uct in­stead of con­sult­ing to solve real prob­lems.

To re-align ex­pec­ta­tions and re­move as­sumed work, we pro­posed and com­pleted an ex­per­i­ment to change the brief process.

New Approach

Taking in­spi­ra­tion from suc­cess­ful meth­ods (see in­spi­ra­tion be­low) we piv­oted the brief­ing stage to fo­cus on the cus­tomers prob­lem, then their so­lu­tion.

What this means is that in­stead of sit­ting down and for­mu­lat­ing a list of Epics’ the team works with the cus­tomer to de­fine a prob­lem state­ment that when solved, achieves their busi­ness goal.

For ex­am­ple, this could mean:

Problem state­ment: My users need a way to bet­ter track their job progress within my soft­ware”

Goal: Increase pro­duc­tiv­ity, team hap­pi­ness and man­age­r­ial track­ing”

Moving to this method­ol­ogy we cre­ate a frame of mind for the scop­ing stage where every­one in­volved is for­mu­lat­ing dif­fer­ent ap­proaches to solve the prob­lem. Rather than spend­ing most of their time turn­ing those wish-list’ items into un­val­i­dated so­lu­tions.

The Process

The Discovery Workshop is used to learn and un­der­stand: what the cus­tomers busi­ness goals are, what their goal is for en­gag­ing with the cus­tomer, what their cri­te­ria for suc­cess will be and what prob­lem/​s they are hop­ing to solve with this pro­ject.

  1. The team will map out what the rel­e­vant user jour­ney is and what steps the busi­ness takes to com­plete the de­sired out­come so every­one has an un­der­stand­ing of the cur­rent process.

  2. We list all of the prob­lems/​op­por­tu­ni­ties we have to solve us­ing soft­ware.

  3. Team mem­bers help the cus­tomer fo­cus in on the most press­ing prob­lem that they can solve early on to val­i­date.

  4. We ask why. This en­ables us to re­move any ab­strac­tion or as­sump­tions through their do­main ex­pe­ri­ence that cus­tomers may have placed into the state­ment.

  5. After this, we rapidly it­er­ate the prob­lem state­ment again un­til it sat­is­fies all rel­e­vant stake­hold­ers and the busi­ness process.

  6. Finally, we quan­tify the prob­lems busi­ness case by set­ting a goal where we can mea­sure value.

If the cus­tomer is com­ing with a ready so­lu­tion or a back­log of sto­ries then the team should still fo­cus in on find­ing the first prob­lem and ex­plain how the scop­ing team will pro­ceed with iden­ti­fy­ing a so­lu­tion from that. It is also im­por­tant not to get bogged down in any so­lu­tion gen­er­at­ing this early on. Ideas can be recorded to be tested but it is not about form­ing a so­lu­tion…yet.

The ob­jec­tive of a brief is to make sure the client and WorkingMouse can fa­cil­i­tate a good work­ing re­la­tion­ship and build trust (which is the foun­da­tion of any ag­ile pro­ject). WorkingMouse is look­ing to en­sure that the cus­tomer un­der­stands how we work and what steps/​stages we un­der­take within our Way of Working.

The whole idea of ag­ile soft­ware de­vel­op­ment is to not rush to a fi­nal so­lu­tion. Over the years this has be­come the norm dur­ing the build­ing phase. However there are still plenty of ex­am­ples of pro­jects that have rushed to start build­ing. By firstly start­ing with a prob­lem and us­ing that to dis­cover a so­lu­tion we can cre­ate a frame­work for the de­sign phase of an ag­ile pro­ject.

Inspiration

We do not pro­fess to be the mas­ters of de­sign think­ing. We learn from and adapt learn­ing to our process. Therefore it is im­por­tant to high­light rel­e­vant re­source we took in­spi­ra­tion from for this.

The Design think­ing play­book’: mind­ful dig­i­tal trans­for­ma­tion of teams, prod­ucts and ser­vices, busi­nesses and ecosys­tems/ by Michael Lewrick, Patrick Link and Larry Liefer, pub­lished by (2018).

Sprint how to solve big prob­lems and test new ideas in just five days’ by Jake Knapp, pub­lished by Google Ventures.

Outcomes

Through this process, we found that our cus­tomers are more open to change. Scoping is short­ened with smaller de­liv­er­ables, smaller es­ti­ma­tions at the end of the scope and bet­ter soft­ware for the end-users. We hope you can use this ap­proach for your soft­ware pro­jects. Alternatively, con­tact us to see how we can use the process to help you build soft­ware.

ABOUT THE AUTHOR

David Burkett

Growth en­thu­si­ast and res­i­dent pom

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

The Advantages of Agile Project Management

09 September 2020

What’s the Best Agile Project Management Method For You: Scrum vs Kanban

11 September 2020

The Trinity of Product Success

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion