Agile — The Truth
i learn this the hard way.
First of all, agile is a renowned software development methodology. It had already create a lot of beautiful, useful, and very cool product. Big technology company such as IBM, social media unicorns, Microsoft etc. but there are also several catch in implementing this methodology. I will mention several problems that we encounter during PPL.
Less predictable
the aim of using agile so that developers can easily divide each of the task, working on a cross functional team so that the product can deliver each sprint. But sometimes there are a lot of x factors that are unpredictable so that it ruins the whole sprint and it halts the software development process. by that, it also happened in our project.
Our encounter for this problem is that we did define the tech stack we wanted, the product owner also agreed on it. but suddenly they insist us to change it into what he desired in the last minute. So the first 2 sprint was worthless. So this translates that to a wasted time. Because Agile is based on the idea that teams won’t know what their end result (or even a few cycles of delivery down the line) will look like from day one, it’s challenging to predict efforts like cost, time and resources required at the beginning of a project (and this challenge increment as projects get bigger and more complex).
Solution
Make a clear documentation on the requirement, and really say what the obstacles for the developers to the product owner that you will be encountering. so that there will be no sudden changes that affect all of the sprint that have already delivered (no major changes to the sprints).
Late responses
having this as the title, some of our project really depends on the product owner’s task. So to proceed they have to do what they “promised” first. So as this goes, we cannot finished our given task, so most likely the product cannot be delivered in one sprint. In our group, it happens a lot. So looking at this real life example we know that sometimes even though we have assigned and did our task there can also a bottle necking happen in the project.
Solution
there should be a dedicated person to keep contact to the PO. We should also sets deadlines so that it wont affect the sprint cycle to the PO if they promised something for the development.
Task Difficulty Measurement
Given several user story, we break it down into several tiny task so that each team personnel can work on it. Sometimes a task can be hard so that we have to break it down again into separate tasks. But then, it come to the realisation that one of the team members isn’t skilled enough to complete their task. But, he/she didn’t say anything until sprint review.
The story above happened, and it halts the developments process because some of the PBI assigned to the person is not finished. Agile itself have this method to give a weight to each PBI. And Agile with sprint also facilitate the developers with standup meeting to discuss their current work. By not utilising this method to the fullest, it will damage the delivery of the product such that it can cancel the whole product’s development cycle if not fixed immediately.
Solution
Know yourself. take the task that you can do, and also be honest in every sprint review, tell your fellow teammates your difficulty, ask for help and reflect on yourself.
Conclusion
all of the points above are what we experienced in PPL. there could probably a lot of benefits we can take from this three examples. Looking back, i’am really glad and happy that we deliver the final product and it also satisfy us as developers and the Product owner. although we have been through ups and downs, but i’am really happy for the process.
