How to eat a Big Pink Elephant (delivering working software) bit by bit using SCRUM.

How to eat a Big Pink Elephant (delivering working software) bit by bit using SCRUM.

How to eat a Big Pink Elephant bit by bit using SCRUM.

Of course this article also pertains to vegetarians: P

There are two methods of eating this elephant of (delivering working software) (of course you have to kill it first)

  1. Either you have to have mouth of same size (and stomach too).
  2. Or you have to cut that in pieces and eat (more practical).

Usually most product managers (including me) tried it many time,  creating a long list of requirements (which itself will take lot of time) and giving it to our dear developers  to build, they start building it, till such time QA guy pretends to work(:P) and creates test cases for those  requirements and product is release in Beta.

Everybody including our Office boy is eager to see our product launch but you soon realizes by the time product is complete it is either obsolete or is of low quality.

That’s where SCURM or similar iterative and incremental agile software development methods can help you out (however I do not want to persuade you to be non-veg to eat this elephant).

Here is the simplified version of how can you eat this elephant.

First of all you have to hunt this, in other words collect requirements – Very first thing we all assume that elephants are tasty and we have to hunt them (remember there are other tasty animals too)

Wait!! What does this have to do with Requirements?

How to eat a Big Pink Elephant bit by bit using SCRUM.

Because most of the time we ourselves (including our customers) do not know what we or customers want, so what about NOT hunting elephant but trying out first by hunting smaller tasty animals. Selection of which smaller tasty animals (Small requirements) to hunt can based on a quick and dirty survey among friends, prospective target audience, stakeholder and your own judgements.

In SCRUM, that’s what Product Owner (along with other stake holders) needs to define, he/she is responsible for making sure that he selects most valuable features from the list of available options.

So for this week (Sprint of 1 or 2 weeks) of Breakfast, Lunch and dinner, Product Owner have decided to catch some rabbits (list of tasks)

We create plan (Sprint Planning) to hunt the rabbits (tasks), Once Sprint Goal is defined, we start catching them one by one as a team (remember Rabbits are fast to run). Working as a team we catch enough rabbits for the week and in weekends we celebrate our success along with discussing if this was a good hunt (Sprint Review) and note down some corrective and preventive actions (Sprint Retrospective) without burning any bridges.

The biggest benefit of catching the rabbits in this way is that we can change our plan in next week based on the feedback of our customers and stakeholders.

Second we can get quick feedback of people (stakeholders or customers) who have put money to send us out to hunt and by looking at the working software they can even help to fine tune the road map for our better future.

Conclusion: In order to be effective at launching big products you have to divide the plan with weekly plans of sprint, in other words you don’t kill elephant but catch rabbits and still be happy delivering responsive successful software.

 

 

You may also like...

Leave a Reply

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