I was on a big music festival in Jakarta last weekend. After enjoying the performance of Phoenix, me & the crowd moved away from the stage. There I saw lots of trashes around. How come people decided to just dispose it irresponsibly? The trash cans weren’t hard to find. The only possibility is that they made a conscious decision to do so. They just didn’t care.
So they can afford a quite expensive tickets but don’t possess the moral consciousness to throw trash on its place? How ridiculous. What a pity. Such a shame for the young generation who can actually be categorized as middle-high class (because they or probably their parents can afford the expensive tickets). I wonder whether they’ve ever received any education.
When I started my very first full-time job 2 years ago, my boss told me that in order to be successful, I gotta be so damn good early in my career. He didn’t elaborate more about it. But now, after working with a lot of different individuals, being exposed to a lot of projects, and having to solve various problems, I finally got a grasp on how to be considered “so damn good”.
I think there 3 important things to assess when you’re working with someone:
Early in your career, you obviously won’t have the experience & expertise to do the job. However, it can be compensated if you have high intelligence (which means you learn fast and excel quickly) and good work ethics (which means you will be giving your all to do the work). Once a new onboard has these traits, I’ll definitely bring him into the light and help him blossom.
But some people are smarter than others. And the geniuses are usually the jerks. So if you’re not a genius, you can still stand out if you have a super good work ethics; and that’s what I keep telling my sister. You gotta be more hungry than the others, so that you’ll be unique and they’ll remember you.
As you’re exposed to a lot more projects and people, you start to understand things and people more, and then you build some kind of self-dictionary and you call it experience. Some people are lucky enough to progress faster than the other. As a result, they got more experience in shorter time. But there is also another element called age maturity, and when mixed into your experience it can become something irreplaceable. Later you’ll be thankful if you meet a boss or mentor who are a lot older than you are and whose experience are still closely relevant with today’s situation. Such boss or mentor often know what to do and can make the correct decision. They’re the people whom with you can pickup some useful lessons and inspirations.
At least that’s what I think after 2 years+ of running a full-time job. The starter will always be yourself, your eagerness, and your hard-work. But how far and how fast you can go will often depend on who you’re working with and who’s leading the way.
“It makes a difference, doesn’t it, whether we fence ourselves in, or whether we are fenced out by the barriers of others.”
If you’re using scrum framework in your software project, you would probably be familiar with the term “velocity”. It’s the measure of how much stuff can be done by the team in one sprint. It’s the total “points” claimed by the team at the end of the sprint after delivering production-ready stories. Some believe that this is a way to measure team’s performance.
Velocity usually varies from team to team due to the different style in estimating story points. In Midtrans, most of the teams use Fibonacci numbers to estimate the complexity of the story. Bear in mind that what we estimate is the complexity, not the time required to get the stories done. So, how the points weight can be significantly different depending on the team and the project.
For engineering/dev team, story-points system is a common practice. For Scrum Master, Project Manager, and Product Owner, this system is very helpful for planning and making promises to stakeholders. An experienced teams are usually able to estimate story complexity accurately, and maintain a stable velocity throughout sprints. So you can make release plan that can fulfill the needs of your customers without having to take its toll by pushing your team to work overtime for weeks.
However, when it comes to team who use kanban or work by tickets, sometimes story points & velocity are not needed or just don’t make sense. For example for merchant support team. They need to respond to & close tickets quickly, and sometimes it’s highly dependent to other teams. Not much can also be planned; there are mostly ad-hoc works. So in this case, story points system are irrelevant. Instead, they’re comparing incoming vs closed tickets to measure performance; and this is the right metrics to look at for their case.
What about data science project? After a year of managing a data science team, I think it’s hard to apply story-point system for an analytics or data science project. When it comes to building a mathematical model or analyzing data, there are too many possibilities. The data may not be ready for some reasons. You may need to do a long data cleaning works. Or maybe, you are not able to build a robust & accurate model even after months of iteration; because the problem is simply cannot be answered by the data you have. So this is the challenge that prevented me from using story-point system and measuring their velocity.
But most of the time, after the “science” part, there will be the “engineering” part. It’s the time to build the app to implement the model or visualize the result of their analysis. This time, the project becomes similar to software projects. So we should be using story-point system here. It may also make sense to start recording their velocity from this stage.
Thus, in my opinion, whether story-point & velocity will be useful will highly depend on the project. It’s nice to have some quantitative measure of performance to help you plan ahead & analyze the progress of the project based on data. However, we shouldn’t be blindly pursuing high velocity, because the most important thing to deliver is the business values, not the stories. In other words, when you’re delivering lots of stories and recording high velocities from sprint to sprint but the stories don’t actually provide business value, then all your work means nothing. So be agile and be sharp!
Three days ago a friend of mine passed away. He was my junior in college. We weren’t that close in particular, and there were times when we don’t share same opinions. But there were several memorable occasions in which we crossed path; and I think everyone in our college program knows about his achievements.
I remember when our teams competed on a national competition. I was proud of him and his team when they got the 2nd place. It was not easy for a second-year college student to beat 60 other teams to get into the final of that competition. Moreover, it wasn’t his first achievements. He was also a runner-up at an ASEAN-level competition before. He must have learned a lot outside class; and it’s something that other students should be looking up to.
So we’ve just lost a high achiever; someone that could actually make a difference in this country where only a small percentage of the population go to college, and only a tiny portion of the graduates are actually “educated”. It’s really a big loss for all of us.
Goodbye Taro. You will be remembered. Our prayers go with you.
Pada bulan Mei-Juni tahun ini saya berkesempatan untuk melakukan perjalanan ke beberapa negara Eropa. Saya mengajukan permintaan visa sekitar 2 bulan sebelum perjalanan tanpa melalui bantuan Agen, dan ternyata tidak terlalu sulit. Berikut adalah kisah saya dalam mempersiapkan sampai akhirnya mendapatkan visa tersebut.
1. Memlilih Kedubes untuk mendapatkan Visa
Saya memilih untuk apply visa schengen ke kedubes Perancis karena saya akan spend waktu paling lama di negara tersebut (8/14 hari saya habiskan di Perancis). Selain itu point of entry saya juga di negara tersebut.
2. Pendaftaran dan Persiapan Berkas
Sebenarnya dengan googling kita bisa mendapatkan banyak info dan panduan membuat visa schengen. Tapi agar lebih yakin saya sempat mencoba mengontak Kedubes Prancis via telepon, dan akhirnya saya diarahkan untuk mengontak TLS sebagai pihak resmi yang ditunjuk oleh kedubes untuk pendaftaran visa prancis.
Visa yang saya butuhkan adalah visa short stay. Informasi yang tersedia di website https://fr.tlscontact.com/id/jkt/index.php?l=id terbilang cukup lengkap. Step by step serta checklist berkas-berkas yang dibutuhkan dapat dibaca melalui website tersebut. Pendaftaran dan appointment dilakukan secara online.
Sebisa mungkin penuhi list berkas yang ada di checklist yang diberikan. Beberapa dokumen yang wajib disiapkan adalah:
– 2 Pas Foto sesuai format yang ditentukan (kalau belum punya, datang saja ke tempat foto & bilang kebutuhannya untuk apply visa apa, biasanya mas/mba nya udah tau)
– Formulir pendaftaran yang telah diisi (apabila melakukan pendaftaran secara online, formulir ini akan terisi otomatis sesuai data yang kita input di website, jadi tinggal kita download dan print saja)
– paspor lama (saya tidak submit paspor lama karena memang tidak dikembalikan oleh pihak imigrasi saat saya melakukan perpanjangan paspor)
– Kartu Keluarga (tidak saya translate)
– Travel Insurance (biar gak repot saya beli asuransi AXA secara online seharga 36.55 USD. Sangat hassle-free)
– tiket pesawat PP
– tiket transaportasi lainnya (apabila akan pindah2 negara/kota selama di Eropa)
– bukti booking hotel/akomodasi (apabila masih tentatif, booking pilihan yang free cancellation saja di agoda atau booking.com. Pastikan kita dapat menunjukkan dimana akan tinggal untuk setiap malamnya)
– bank statement dengan saldo yang cukup untuk membiayai kita selama berada di Eropa (beberapa sumber mengatakan bahwa sebaiknya kita punya saldo minimal 50 juta yang sudah mengendap selama 3 bulan)
– surat rekomendasi dari kantor (menyatakan bahwa kita adalah employee di perusahaan tersebut dan cuti kita selama tanggal perjalanan sudah di approve)
– Slip gaji 3 bulan terakhir
Begitu selesai mengisi data yang diminta secara online, kita bisa memilih hari dan jam untuk datang ke kantor TLS di Menara Anugrah (Mega Kuningan) untuk men-submit berkas kita dan biometric (sidik jari & foto), serta melakukan pembayaran pendaftaran visa.
3. Appointment Day
Saya datang agak kepagian (jam 7 pagi) dan kantornya masih tutup. Mereka baru buka jam 7.30. Jadilah saya menunggu dulu di depan pintu kantor TLS bersama beberapa orang lain. Begitu kantornya buka, pengunjung diminta meletakkan HP nya di loker dan kemudian dipersilahkan duduk. Belum lama menunggu saya sudah dipanggil ke salah satu loket dan seluruh berkas saya diperiksa. Ohya sebaiknya untuk semua dokumen, selain fotokopian, kita bawa juga saja berkas aslinya untuk berjaga-jaga. Segala dokumen yang sepertinya akan berguna juga saya submit saja walaupun tidak diwajibkan.
Dari semua checklist, hanya ada satu dokumen saya yang tidak lengkap, yaitu paspor lama. Saya jelaskan bahwa memang saya tidak pegang paspor lama karena tidak pernah dikembalikan oleh kantor imigrasi. Tapi pendaftaran saya tetap harus diklasifikasikan sebagai tidak lengkap. Yasudahlah.
Selesai verifikasi berkas, saya diarahkan untuk melakukan pembayaran visa dan pendaftaran biometric. Kalau tidak salah total biayanya adalah sekitar 1.2 juta rupiah. Saya tidak bertanya apakah bisa membayar dengan kartu kredit/debit karena waktu itu saya sudah mempersiapkan untuk bayar dengan cash.
Overall waktu yang saya habiskan di untuk keperluan visa di hari tersebut adalah sekitar satu jam. Pada pukul 8.30 saya sudah bisa cabut ke kantor.
4. Menunggu hasil
Tidak sampai 2 minggu setelah kedatangan saya ke TLS, saya mendapatkan email bahwa paspor saya sudah bisa diambil. Keesokan harinya saya pun langsung mampir ke kantor TLS. Sebenarnya saya sempat agak khawatir karena status dokumen saya tidak lengkap (karena paspor lama tidak saya submit). Tapi ternyata hasilnya baik-baik saja dan saya tetap bisa dapat Visa Schengen 😀
5. Kesimpulan & Kesan
Awalnya pengajuan visa ini memang terasa cukup membingungkan dan membuat panik, apalagi setelah membaca kisah orang lain yang sempat ditolak. Tapi apabila kita mau meluangkan waktu untuk mengumpulkan informasi, sebenarnya prosesnya tidak terlalu sulit. Asalkan tujuan perjalanan kita jelas dan kita bisa provide semua syarat yang diminta, seharusnya tidak akan ada masalah.
I was having my very first hackathon around two weeks ago. I have never participated in a hackathon before because I thought it was just for geek coders and therefore someone like me (who is not so much into coding) would have nothing to do on hackathon. But I was a bit intrigued to join Midtrans Hackathon last April because I was bored and I miss being in a competition.
I joined the team as a late-comer. I didn’t know why but the people on my team has one thing in common: we all went to the same college. I have worked with all of them before on different projects. The geek side of us insisted that we should be looking to create something awesome, although I knew the chance of winning was very thin if we decide to build such product as it has no value towards solving the company’s biggest problems. Nevertheless, we decided to build something complex and difficult anyway because, you know, we only want to do something challenging.
Our planning phase went just so-so. We hadn’t even decided what product to be built until a week before the hackathon. To be honest, we didn’t specifically define our backlog until the D-day. But when the hackathon started, I realized that I was working with not only motivated but also smart, fast-learner, and self-manage individuals.
This reminds me of my case competition memories with Baskarry Team. Ardian and Gunawan were one of the best people I have ever worked with, and I always had the confidence that, if being put in a team, the three of us can win any competitions. Everyone worked equally hard. Supervision and instructions were not needed. Each of us knew what to do, and when we had problems, we communicated early, and of course we close issues fast. This was also the case with my hackathon team. We couldn’t stop telling each other how we enjoy the teamwork, and how we admire each other’s ability. One word to describe them: awesome.
We might not win the hackathon, but we had successfully built a fully working prototype of such complex product. I think it was one of the most enjoyable moments I had this year. Great teamwork really brings satisfaction. Once again, the “gather the right people on the bus first, decide the direction second” is still the right thing to do.
In IT companies, especially in startup environment, everything is so fast-paced that people often make decisions based on assumptions without looking at the data first. This sometimes happen too when managing a project and setting up expectation to stakeholders. The project manager might promise a feature to be delivered at a certain date based on his own assumption.
In agile & scrum, we believe that it’s best to ask the team to estimate when they will be able to get a feature/story done. However, based on my experience, the team usually only consider the time they need to develop the feature without taking into accounts other required tasks such as testing, review, and deployment. In the end, the actual time consumed can be twice longer than the developers’ estimation. Therefore it’s safer to add some “buffer time” (such as multiplying your developers’ estimation by two or using the sprint’s duration) when promising delivery date to your stakeholders.
However, if you want to be more precise, you should rely on data. At Midtrans, we constantly track and analyze dev teams’ performance through Jira Dashboard. We track critical metrics such as the number of stories done by each developer, how many tech debts we have, average time in status (to-do, in progress, review), average age of issues until it gets resolved, etc. This helps a lot to understand how fast the team, as well as one particular developer, can get things done. If we show it to the team, they can even get more understanding of how they performed in the past so they can consider it when making subsequent story estimations.
For more advanced analysis, I usually look at Control Chart report (also in Jira). This chart shows the average cycle time of the project & its stories. As written on its description, this chart is useful to identify whether we can use our historical data to predict future performance. If the standard deviation is too high (reflected by wide light-blue area), that means the team’s performance is very erratic. Thus, for this case instead of looking at how your team perform in past stories with similar complexity, you’d better use your team’s estimation of the new story and add it with buffer time to estimate the delivery date.
But when the standard deviations’ area is narrow, you can rely on the past performance to make future decisions. As can be seen from the chart above, since early March, with the narrowing light blue area, the predictability has significantly improved. By early April, the rolling average of the stories (from the time the development started until it’s production-ready) was 5.7 days with only 2.2 days of standard deviation; much better then the previous months’ predictability.
What does this mean? It means that for a story with similar complexity, the rational estimation from the team should be around 5.7 days (including code review, PO acceptance test, etc.) until it becomes production-ready. Then, you should add at least 2.2 days into the estimation as buffer time. In addition, if there’s some sort of change request procedure that needs to be approved before the deployment can take place, you also need to count the number of days into your delivery date estimation. For example, if this procedure takes 2 days, then you can only deploy on the third day after the feature becomes ready-to-deploy. Consequently, the number of days until the the feature is live is now 5.7 days + 2.2 days + 2 days = ~10 days; which means you can safely deploy on the 11th day since the development starts. That’s the number you can promise to your stakeholders.
In some cases you may also want to know when a feature can be delivered after it’s added to sprint backlog. You can do this by refining the Control Chart Report to show the cycle time since the stories were added to the backlog. In my case it results in two extra days, making it 12 days to turn story from a sprint backlog item into a production-ready item. Same logic applies if the story isn’t going to be added into your current or nearest sprint. You just need to add your sprint duration and multiply it by the number of sprints ahead of that story’s sprint, and there’s your data-driven estimation.
What if you aren’t using Jira? Well, you can replicate the chart using excel. Just make sure you collect all the data accurately. It’s gonna take manual efforts but it will help you a lot in making informed decisions when managing projects.