How to Go From Scrum Starter to Scrum Master


If you have ever been in­volved in soft­ware de­vel­op­ment, I would guess you have al­ready heard of Scrum and why it is one of the most cost and time ef­fec­tive meth­ods of de­vel­op­ment. For those who haven’t: Scrum method­ol­ogy is an it­er­a­tive de­vel­op­ment process that pro­motes dis­ci­plined pro­ject man­age­ment and en­cour­ages teams to make fre­quent cy­cles of learn­ing.

Implementing the Scrum method­ol­ogy for your soft­ware de­vel­op­ment, at its most ba­sic level, in­volves com­plet­ing a se­ries of ‘ceremonies’ and prac­tices. But to go from a Scrum Starter to a Scrum Master, you have to be able to adapt and ad­just the ide­olo­gies be­hind these cer­e­monies to your unique team and pro­ject. That’s why we sent four of our de­vel­op­ment squad leads to be­come cer­ti­fied Scrum Masters! The re­sult was they came back with awe­some in­for­ma­tion to help the whole com­pany level up our Scrum knowl­edge.

Scrum Starter Pack

Before you can be­come a Scrum Master, you first to have to un­der­stand the ba­sics of the Scrum method­ol­ogy. One of the most im­por­tant con­cepts to know is that Scrum is a child of Agile method­ol­ogy. This means a pro­ject that is de­vel­op­ing us­ing Scrum should im­ple­ment ac­tive learn­ing cy­cles (iterations). These help the team fail fast in or­der to learn quickly.

Essentially work­ing with Scrum is like serv­ing kids a plate of spaghetti. After com­ing home from a long day at work you might de­cide to cook spaghetti for the kids. Next, you ac­tu­ally make it and serve it to the kids. The kids throw a tantrum about eat­ing it, scream­ing that it tastes hor­ri­ble. Disappointed, you think about what could have gone wrong and con­sider you may have over­done the salt. You de­cide next time to cook with less salt (or or­der take­out). This is work­ing in ag­ile it­er­a­tions.


The Scrum method­ol­ogy im­ple­ments four main cer­e­monies that cre­ate a method­ol­ogy dis­tinct from ag­ile: con­cep­tu­al­i­sa­tion, im­ple­men­ta­tion, re­view and re­flec­tion.

The first of these is plan­ning and con­cep­tu­al­is­ing the prod­uct. To achieve this you should set it­er­a­tion goals and ac­knowl­edge any po­ten­tial learn­ing spikes. It is im­por­tant dur­ing this process to be open with your prod­uct man­ager or client en­abling them to set re­al­is­tic ex­pec­ta­tions for the pro­ject.

The sec­ond cer­e­mony in a cy­cle is the im­ple­men­ta­tion. This is where you ac­tu­ally build the prod­uct. Implementation is the part that makes Scrum dis­tinct from the um­brella term - ag­ile. Although this cer­e­mony will take up ma­jor­ity of the de­vel­op­ment cy­cle, Scrum val­ues im­ple­men­ta­tion equally with its other cer­e­monies.

After you im­ple­ment and ac­quire tan­gi­ble ev­i­dence of your prod­uct, the third cer­e­mony Scrum pre­scribes is the re­view. This is where you meet with all stake­hold­ers and talk about what was achieved dur­ing de­vel­op­ment. During this cer­e­mony, all feed­back is good feed­back. It is im­por­tant that you are re­cep­tive to all cus­tomer feed­back, whether pos­i­tive or neg­a­tive. As hard as it can feel to be grate­ful when re­ceiv­ing a cri­tique of your hard work, fo­cus on keep­ing the team pos­i­tive about ob­tain­ing the learn­ings of­fered.

From here you move to the fourth cer­e­mony of Scrum, the re­flec­tion. This is where you gather in­sights as a team about what to do bet­ter next time and dis­cuss how prob­lems that were en­coun­tered dur­ing this pro­ject could be pre­vented in the fu­ture. Reflection is a vi­tal process to Scrum. It sep­a­rates the smart from the stu­pid be­cause you pre­vent the team from re­peat­ing its mis­takes. Fool me once, shame on you, fool me twice, shame on me. It is im­por­tant you aren’t plan­ning dur­ing ret­ro­spec­tive think­ing, oth­er­wise you might miss vi­tal learn­ings that will make fu­ture pro­jects more ef­fi­cient.

You can then go back to the first cer­e­mony of plan­ning and ac­tion your ear­lier learn­ings from the ret­ro­spec­tives into ac­tion. This is the over­ar­ch­ing ac­tive learn­ing cy­cle of Scrum, but ac­tive learn­ing cy­cles can be ap­plied to every part of the Scrum process.

Become a Scrum Master (Level Up)

To be­come a Scrum mas­ter you must un­der­stand that Scrum is less rigid than how it has been ex­plained so far. A Scrum Master is able to adapt the gen­eral cer­e­monies and ap­ply it to the spe­cific cir­cum­stances of each unique pro­ject they work on. More im­por­tantly they ed­u­cate the team on the un­der­ly­ing ide­olo­gies of Scrum and teach each stake­holder to value the method­ol­o­gy’s pos­i­tive im­pact on the pro­ject.

Level Up 1

For ex­am­ple, dur­ing the plan­ning cer­e­mony you may find that the stake­hold­ers are strug­gling to come to an agree­ment. As a Scrum mas­ter you might try split­ting the stake­hold­ers up to sit in­ter­change­ably at the meet­ing table, with the aim of break­ing down so­cial bar­ri­ers and en­cour­ag­ing a col­lab­o­ra­tive work­ing en­vi­ron­ment.

Level Up 2

As a Scrum Master you might also recog­nise the op­por­tu­nity to utilise the im­ple­men­ta­tion cer­e­mony for de­vel­op­ing team ma­tu­rity. This may in­volve en­cour­ag­ing each team mem­ber to run a client meet­ing or hold the daily morn­ing team hud­dle. Allowing every­one in the team to con­tribute will en­cour­age col­lab­o­ra­tion and also help in­di­vid­u­als feel val­ued as part of the team.

Level Up 3

Another idea you might have as a Scrum Master is to en­sure that dur­ing your re­view with a client your team never feels like neg­a­tive feed­back is un­der­min­ing their ef­forts. You may there­fore choose to also dis­cuss the risks and is­sues that have been over­come, rather than only men­tion­ing what you have been un­able to achieve in the time­frame of the sprint. Highlighting these achieve­ments is not only im­por­tant for clients to un­der­stand what has been achieved with their money, but it also helps your soft­ware de­vel­op­ment team feel as though their ef­forts are be­ing ac­knowl­edged.

Level Up 4

During a ret­ro­spec­tive cer­e­mony a Scrum Master might see that the ideas be­ing gen­er­ated by the team are far-fetched and end­less. Scrum and ag­ile method­olo­gies need to spend more time build­ing and fail­ing rather than dis­cussing hy­po­thet­i­cals. To speed up the process a Scrum Master might use a com­bi­na­tion of di­ver­gent and con­ver­gent think­ing. This is where you en­cour­age the team to think di­ver­gently, each throw­ing around a few ideas and so­lu­tions. These ideas can range from fa­mil­iar so­lu­tions to un­usual al­ter­na­tives. As a Scrum Master you are likely to set a time limit on this process. You can then have the team con­verge their thoughts by con­sol­i­dat­ing the ideas and com­ing up with an ap­pro­pri­ate so­lu­tion for the next it­er­a­tion.

The range of ideas a Scrum Master can have are end­less be­cause the num­ber of unique pro­ject and stake­holder com­bi­na­tions are end­less. The im­por­tant thing to keep in mind to dif­fer­en­ti­ate your­self from a Scrum Starter is that just as a pro­ject it­er­ates us­ing learn­ing cy­cles, so will the way you im­ple­ment Scrum cer­e­monies. If you’re in­ter­ested in de­vel­op­ing with a cer­ti­fied Scrum Master team, con­tact us.

Discover Software


Eban Escott

Big pic­ture thinker and Star Wars fa­natic

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

Your vi­sion,

our ex­per­tise