Core Agile Scrum - Best Practice - Part I

Based on some experiences practice with Agile/Scrum and get ideas from some books. This short note to explain the principles of Agile/Scrum:

What is Agile?

• Agile isn’t the newly-appeared trend anymore. After 20 years of introduction and its proven results, the agile method is here to stay.
• Must understand and master the principles behind agile practices before applying the practices.
• Agile is unique for each company. Each company owns its own agile process that can help to achieve agile areas based on the definition of areas that are created by each company.
• Agile method ties directly to the key objectives of most companies: increasing revenue/market(based on valuable products, trust customers, and loyalty customers ) share while lowering costs.

What is Scrum?

• Scrum is mainly a framework, the team still needs to identify the practices and methodology to use within the framework.
• If all the requirements are not available from the beginning, the agile-applied project is still feasible. That is that the requirements can convert to acceptance.
• It requires close collaboration between team members. The whole agile team will get better over time. Agile is not effective if team members don’t know how to work as a team and they have never worked together before unless the team is for a certain period of time. As needed, consider productivity reduction in the short term.
• The Scrum framework needs to be accompanied by agile practices to support a complete development lifecycle.
• Face-to-face communication and common understanding are important in Scrum. That can get out of email/chatting hell.
• Regarding the definition of a team, a project team may be constructed of team members from a shared resource pool. If such team members view themselves as resources on loan, and not as team members dedicated to the project, the result can be functional silos (zombies).
• For about the first four sprints, the deadline is not so strict or all User Stories might not be clear. Rooms for improvement are identified during Sprint Retrospective.
• When sprint planning, it is not necessary to assign tasks to specific members but to do estimation that includes technical, nonfunctional, and testing tasks.
• Estimation is done for user stories/features only.
• Each scum event needs to have a time-box and goals.
• Need to have the definition of ready and definition of done, definition of blocker, definition of a bug.
• When estimation is difficult to make, a spike task is created with a time-box(2h, 4h, 8h) which depends on the length of sprint, (2h for one-week sprint, 4h for two-week sprint: 4h, 8h for four-week sprint).
• Resources need to fix as possible when changing resources to need re-define references.
• Team size should be about 5-7 members and the team is vertically structured. A vertical structure team spans the architecture and is aligned with skillsets or disciplines.
• It is required to have more team buy-in and involvement. Then, The team is enthusiastic to suggest the feature to the product over time.
• The retrospective discussion must be required. If the project team has new members, they should understand all retrospective notes. this is important more than they can understand the requirements this meant helping new members can easier to work together more and never recur mistakes before.
• The goals of a sprint aren’t changed during the sprint.