Agile
We have been using Agile in our project for months now. We have a Scrum Master, a Scrum board, a daily standup. We even have a retrospective and a backlog grooming.
Agile is meant to empower all of us to do great at work, give us a sense of accomplishment. But Agile made life miserable. Scrum Calls was becoming a mean of questioning everyone of what has been done, what has not been done. The Retrospective was more of blame game, blaming each other OR other teams our own incompetency of completing the tasks.
But why is Agile so great? Why have projects following Agile become successful? Why knowing Agile puts you a step ahead of others?
Probably because Agile is not what we all think it is.
Agile is much different and much more helpful if used correctly.
Becoming Agile is a never ending journey that everyone needs to take. Be it a Product Owner, A Scrum Master or a Developer.
Product Owner - He represent the Users. He/She is responsible to bring the groomed stories for the developers. BAs usually help the PO (Product Owner). Every squad must have a PO and PO must give user stories. He must give the MVP - Minimum Viable Product.
Multiple squads form a fleet. All POs have a Chief PO, the person responsible for the entire product.
The Scrum Master plays the role of the facilitator. He/She is not there to question, but to help
The squad members (Dev and QA) actually pick up stories and give estimates. No one commits on their behalf.
Estimates and Story points are two different things we tend to mix up. Or maybe we have been programmed that way. But Time Estimates != Story Points, though no one stops you from doing it.
Story Points represent the complexity of the Story. They are given using relative sizing using fibonacci series(1,2,3,5,8...). Here you pick up a story and give an estimate for it. Then depending on this story, you provide your story points for other stories in the backlog. Some might be more complex and some simpler.
One very important thing about Agile for developers/QA is, you never pick up a story unless it is ready to be picked. Details of the story should be discussed in the backlog grooming, which should never be missed or attended while multi-tasking. Asking the right question comes with practice. Keep nothing to imagination and assumptions. Team will become mature after 4-5 sprints. The team needs patience. Also, pick up stories in the sprint according to your bandwidth. You can always go back and pick up a properly groomed story from the backlog in the middle of the sprint.
BAs and POs play a very important role in creating the backlog. Before the Backlog grooming session, there must be enough properly prioritized draft User Stories to be discussed. As the agile squad matures, the BAs and POs will understand the pattern of the questions and bring more refined stories to the table. As I said, patience is the key. Acceptance criteria must be fully defined. Adding new acceptance criteria is fine, we are Agile afterall. But, nothing from a story should change after the squad has picked up. Limiting the scope, adding to the scope should be discussed with the squad. Any such adhoc requests should be picked up in the retrospective and should be addressed to try to avoid in future.
Another important thing to remember is that, your total efforts put in a sprint have to cover your unit testcases, acceptance test cases, the QA efforts and the PO efforts to give you a signoff and for the squad to be read with a potential shippable product. Have a definition of DONE well defined in your Sprint 0.
Some important ceremonies
Agile is meant to empower all of us to do great at work, give us a sense of accomplishment. But Agile made life miserable. Scrum Calls was becoming a mean of questioning everyone of what has been done, what has not been done. The Retrospective was more of blame game, blaming each other OR other teams our own incompetency of completing the tasks.
But why is Agile so great? Why have projects following Agile become successful? Why knowing Agile puts you a step ahead of others?
Probably because Agile is not what we all think it is.
Agile is much different and much more helpful if used correctly.
Becoming Agile is a never ending journey that everyone needs to take. Be it a Product Owner, A Scrum Master or a Developer.
Product Owner - He represent the Users. He/She is responsible to bring the groomed stories for the developers. BAs usually help the PO (Product Owner). Every squad must have a PO and PO must give user stories. He must give the MVP - Minimum Viable Product.
Multiple squads form a fleet. All POs have a Chief PO, the person responsible for the entire product.
The Scrum Master plays the role of the facilitator. He/She is not there to question, but to help
The squad members (Dev and QA) actually pick up stories and give estimates. No one commits on their behalf.
Estimates and Story points are two different things we tend to mix up. Or maybe we have been programmed that way. But Time Estimates != Story Points, though no one stops you from doing it.
Story Points represent the complexity of the Story. They are given using relative sizing using fibonacci series(1,2,3,5,8...). Here you pick up a story and give an estimate for it. Then depending on this story, you provide your story points for other stories in the backlog. Some might be more complex and some simpler.
One very important thing about Agile for developers/QA is, you never pick up a story unless it is ready to be picked. Details of the story should be discussed in the backlog grooming, which should never be missed or attended while multi-tasking. Asking the right question comes with practice. Keep nothing to imagination and assumptions. Team will become mature after 4-5 sprints. The team needs patience. Also, pick up stories in the sprint according to your bandwidth. You can always go back and pick up a properly groomed story from the backlog in the middle of the sprint.
BAs and POs play a very important role in creating the backlog. Before the Backlog grooming session, there must be enough properly prioritized draft User Stories to be discussed. As the agile squad matures, the BAs and POs will understand the pattern of the questions and bring more refined stories to the table. As I said, patience is the key. Acceptance criteria must be fully defined. Adding new acceptance criteria is fine, we are Agile afterall. But, nothing from a story should change after the squad has picked up. Limiting the scope, adding to the scope should be discussed with the squad. Any such adhoc requests should be picked up in the retrospective and should be addressed to try to avoid in future.
Another important thing to remember is that, your total efforts put in a sprint have to cover your unit testcases, acceptance test cases, the QA efforts and the PO efforts to give you a signoff and for the squad to be read with a potential shippable product. Have a definition of DONE well defined in your Sprint 0.
Some important ceremonies
- Backlog grooming - every Monday
- Sprint start - Wednesday, have a sprint cycle depending on the complexity of your work, dont overcommit and underdeliver
- Retrospective - Positive and towards improving our sprint. No hatred
- Daily standups - The scrum master has a daily 15 mins standup to know what each member did yesterday, what he/she plans to do today and how they are moving towards achieving the goal for the sprint
- Demo - A place to showcase all the hard work the squad put in. Call in stakeholders for demos where we are presenting something substantial. Also, helps you get instant feedback instead of you waiting for months before you get your first feedback (As in waterfall model). You need not wait for the demo though, remember your PO is available and approachable. So get your feedback sooner.
Not only the technical people, but the users are also moving towards being Agile. Agile is a life style we can adapt in our daily chores. Getting early feedback can help avoid fights and having a healthy relationship with your spouse :P
Agile really helps as you keep getting constant feedback. But, waterfall has it own advantages. Kanban + Agile is where most of us fit in well.
Always remember, becoming Agile is a journey and nobody is 100% Agile. Keep doing your retrospective and be on the path of becoming more Agile
Interesting video: https://www.youtube.com/watch?v=OqmdLcyES_Q
Main motivation for this post is the session I attended.
Note: I have exaggerated roles at the beginning of the post! {Obviously to add some drama}
Comments