Thinking iteratively (Scrum series 2)

Most of us think linearly, that is step by step, from start to finish. Think about making something physical, like a wooden table. Your mind quickly starts creating steps leading to that goal. Something like this feels familiar?

  1. Buy lots of raw wood.
  2. Buy sandpaper.
  3. Buy varnish.
  4. Make four legs.
  5. Make table top.
  6. Apply sandpaper.
  7. Join it all up.
  8. Apply varnish.

Sorry, I’m no expert in the art of table making but most of you would have a similar list of actions. This is linear, meaning that the table cannot be used at all unless all the steps are complete. If you don’t have a dining table at all in your house, then you’ll probably have to sit somewhere else to eat for a couple of days (depending on how good you are at making a wooden table).

Now think about writing software, say a website to help out your friend sell hats for cats online. Automatically you’ll start thinking:

  1. Design frontend.
  2. Develop backend.
  3. Implement frontend.
  4. Integrate payment systems.
  5. Integrate email notification service.
  6. Test.
  7. Deploy.
  8. Handover.

There’s probably a lot of intermediary steps but this is the gist of it all. Again, if you look through carefully, your friend does not get her website unless all of the steps are complete.

Iterative development only means that instead of doing everything in linear sequential steps, you are doing it in cycles. Delivery is key here meaning that you should aim to deliver at least once by the end of each cycle but mature teams are able to deliver the product more than twice each cycle. Thinking in line with the Scrum methodology, each cycle (or sprint) can be one week or up to one month. In our case, if we choose that one cycle is one week, here’s what it might look like:

  1. Cycle 1:
    1. Design basic frontend.
    2. Implement mock backend.
    3. Implement basic frontend.
    4. Integrate mock payment system.
    5. Integrate mock email notification service.
    6. Deploy and deliver.
  2. Cycle 2:
    1. Improve frontend design.
    2. Implement basic backend functionality still mocking rest.
    3. Implement improved frontend design.
    4. Integrate mock payment system.
    5. Integrate mock email notification service.
    6. Deploy and deliver.
  3. Cycle 3:
    1. Implement more backend functionality.
    2. Revisit frontend designs.
    3. Implement frontend design changes.
    4. Integrate basic payment system.
    5. Integrate mock email notification service.
    6. Deploy and deliver.
  4. Cycle 4:
    1. Implement more backend functionality.
    2. Revisit frontend designs.
    3. Implement frontend design changes.
    4. Integrate basic email notification service.
    5. Deploy and deliver.
  5. Cycle 5:
    1. Implement more backend functionality.
    2. Integrate advanced payment system.
    3. Deploy and deliver.
  6. Cycle 6:
    1. Implement more backend functionality.
    2. Revisit frontend designs.
    3. Implement frontend design changes.
    4. Integrate advanced email notification service.
    5. Deploy and deliver.

Here, you are deploying and delivering the product to your friend every week so that she can inspect the whole flow. This also allows you to receive feedback regarding the entire product every week which is not possible in the linear way of doing things (as your product is not ready for your friend to look at until the end). Also you don’t have to come up with all the cycles at once. You basically have to have the current cycle plus at least next two cycles within your sights.

Mocking things is very important in this flow as it helps your friend to “feel” how the website will look at the end. The mocks allow her to go through the checkout flow as if it was actually there. It might seem like a waste of time as you are developing something that you know will get replaced at the end anyway, it still has tremendous value as there is nothing worse than the client changing her mind and wanting to go in a completely different direction towards the end of the project. The mocks allow the client to focus as they get to see the product as it is being developed while also giving you continuous feedback.

While this was a simple example, it gets quite a bit complicated when new projects are undertaken in large scale organisations as there can be lack of clarity before a project is started. I’ll do another post on the Scrum Framework for this sometime in near future but this post provides a base that can help you understand Scrum as it is also about iterative software development.

Again, if you observe the technological advancements that humans has achieved so far, you’ll notice the iterative approach at large scale. We didn’t aspire to build shiny cars from day one. We first started with the wheel, advanced to wheel barrow, horse cart, trains and then finally a built car.

Hope you enjoyed this article. I’ll appreciate it very much if you could leave your thoughts in the comments below.

Manthan Dave
I like awesome things. Currently transforming the world bit by bit. I'm a Software Engineer. (All views my own)

Leave a Comment

Your email address will not be published. Required fields are marked *

%d bloggers like this: