A review of our Agile implementation

Let’s see how the Scrum.ai team implements Agile

Check out the earlier story:

Put your points in Agility

Agile Manifesto

Let’s start from the Agile Manifesto. As we know, there are 4 points in the manifesto:

1. Individuals and interactions over processes and tools. In Scrum.ai, we try as much as we can to solve every problem together, solving blockers and move as fast and agile as we can. But indeed we know that our amount of interactions can be increased instead of relying on tools like Gitlab Issues.
2. Working software over comprehensive documentation. We have our priority right for this point. Instead of providing a comprehensive documentation, we just documented a bare minimal to suffice, and then we fill in the gaps with individual interactions in case there is anything that can’t be understood easily.
3. Customer collaboration over contract negotiation. We collaborate with our project owner in determining the scope of our project, instead of receiving a specific specification in a contract. Although, we admit that we can involve our project owner more closely in the development process, as an example to ask if our implementation is the same as what they expect it to be, then we can update the requirements from the feedback.
4. Responding to change over following a plan. Although we have planned our sprint, we did make changes here and there, like adding more task when we think it is needed to base the other user story. One example is when we need some way to seed the data, I added a task to create an automated database seeder as it has become a blocker for a few tasks.

The Scrum Board

We use a physical scrum board to track our sprint and our remaining product log. Well, it has the things I mentioned in the last story like Product Backlog Tasks, User Story, and also Definition of Done, Sprint Goal, and so on regarding the sprint.

Our Scrum Board

We also has a digital board in our GitLab repository:

Our current issue board

Conclusion

It is a bit of an irony that we, as a Scrum team developing a tool to help other team with their Scrum process, is not making full use and having flaw here and there in our Scrum process. But from these flaw, we have learnt many things that we hope can help our (and others) future Scrum processes.