Scrum journey

Exception, perception, and knowledge are things that fade away. The truth is that your memory betrays you all the time by erasing (without asking you a word !) all your experience about things that you used to know. If you are old enough to forget how awesome your childhood was, and are frustrating because you do, you’ll understand what I mean.

The problem is, experience is often very valuable, even if it is about how you felt being ignorant. For instance, as a teacher, you want to know what it’s like to know nothing about a subject, so you can deliver it to your students, in a less boring or overwhelming way. As a framework designer, if you want to strive for easy integration and small learning curve, you should at first know what small learning curve and easy integration look like for newbies.

I’m not going off topic any further. The reason I’m saying all this is because I’m learning a whole new concept that I have absolutely zero idea about: scrum mehodology. This framework is applied in my gsoc project at FOSSASIA. I don’t have all the data yet, but my first impression is that this is a hell of a subject that would deeply impact me in my work life.

Therefore I’ll use this blog as a diary to log all my experience in my scrum’s discovery journey, so when I’m skillful enough, I can look back at this and remember what it’s like to be ignorant again. I’ll also post useful links and stuffs that help me, so I hope this blog will benifits others as well.

As consequence, this blog will likely be updated in the future. I don’t know when, but it will be. Unless I (am very unlikely to) become a scrum master with no more stuff to learn.

Image broken
Image credit :


Day 1 : What the heck is scrum, and scrum questions ?

Scrum is a version of agile programming, as opposed to “waterfall” programming where all specifications are planned in the beginning and all deliverables in the end. My first impression about scrum is, it doesn’t bring anything new to the table. Smaller release cycle ? Daily team communication ? Sprint-based/task-based development ? More client interaction ? These are useful tips/guidelines for sure, but for a developer, this sounds quite trivial and just like common sense. Maybe from a manager’s point of view, it might looks more like a fresh idea. But if that’s all agile programming is about, then it might not worth the hassle.

My mentors first asked me what my scrum questions are. I was like, questions about scrum ? Yes please, I have tons of them, because I know nothing yet ! But, what scrums questions really mean is simple questions that each member of the team has to answer in each daily standup meeting. It is intended to keep the meeting short (< 15 min) and concise. The most basic line of scrum questions is these three :

  1. What did you do yesterday?
  2. What will you do today?
  3. What obstacle did you find in your way?

The meeting is intended to help team members to know about others’ work, and to (eventually) help them . Most importantly, it’s about making commitments (“I intend to complete this task today, but if I don’t, please don’t look down on me!”). That way the next day others developers will certainly know if the developper did or did not achieve what they intended, and why.

Image broken

So far so good. The way I see it, the daily standup idea has good faith in itself : it encourages just enough amount of team communication. When I was at OnePoint, where waterfall methodology is used, and no team interaction protocol is enforced, I feel like this is exactly the thing we needed.

In my next update that I don’t know when, I’ll probably talk about scrum in my one-man-land situation, that is, a single developer in the development team.

References :