Agile — A Programmer’s Perspective
Motivation
Recently I have accomplished a three months training of Agile Software Development. Throughout the training, I realised I had some misunderstandings about Agile as a programmer who just want to deliver beautiful intellectual masterpieces.
Therefore, in this article, I will try to clarify some parts of Agile that are relevant and meaningful to programmers (or any role Agile framework would categorised as team member). Hope this will let more people “Being Agile instead” of “Doing Agile”, which is used to describe the activity of doing window dressing without applying the core values.
BTW, I am designing a board game named “Playing Agile” (more or less like Werewolf), if you are interested, feel free to contact me.
Scrum Master is a Scrum Servant
As you may already know, the word “Master” in the title is not the same as in “master-servants” (actually “Scrum Servant” would be a better name to describe the role), it means they have mastered the Scrum framework.
They are there to serve the team. Since one of their task is to keep you and the team not over-committed or under-committed, you should communicate with him/her to make sure he/she got the right estimation for your capacity. And you should also defend your capacity.
If you think the process is too bureaucratic / inefficient, or you just don’t like it. Then raise the issue to the Scrum master, remember they are servant leader.
PO decide what, You decide how
The boundary should be clear. You are the one who decide how to implement user stories and features, whereas PO (Product owner), as voice of customer, decide the features a product should have.
While you should not let PO do the thing you are trained to, you should also trust the professional skills of your PO.
Prioritising
While PO is responsible for prioritising user stories in the backlog to select the most valuable deliverables and establish work for the next Sprint, and you are the person who should prioritise work in each Sprint.
Here are some tips:
- Do high-risky task first. A Task is considered as high-risky, if a) you don’t have prior experience, b) the task is too complex. People also call this “fail fast”.
- Pick low-hanging fruit first. This helps to keep the morale.
Scoping and Estimation
It is your job to provide estimations for each user story and measure the scope of the corresponding work. The following factors should be considered when estimating:
- Complexity (How hard?)
- Size (How big?)
- Level of Effort (How many human resources & how much time did the team spend to complete for similar task?)
- Certainty (Is there any unknown problems?)
You should not let PO, customers or other stakeholders to define that for you because the work will be done by you.
You may want to apply the estimation method widely used in the military field to give three estimations: optimistic, most likely and pessimistic time.
Conclusion
A mentor in the training said he love the job as Scrum Master because he think this could make people achieve better work-life balance. I also believe in that. Being Agile can improve the working atmosphere, make everyone’s work happier, and ultimately make everyone’s life happier.
Thank you for reading and stay safe :)
