This post suggests a very basic implementation of a scrum/agile methodology which prep the team during the course of project execution.
Before diving deep let's know basic terminology of the agile methodology which we commonly use during the process.
The team is capable of handling multiple genres of work like Full stack developer is one of the best examples.
- Daily Standup
Time which is taken out from our daily schedule to update the status of the work and next pipeline task and any impediments blocking the progress of the work. make sure we keep the daily standup short as 10-15 mins depending on the team size.
Definition of done: We define the quality and amount of features that should be working as mention in the requirement. DOD varies across the team for a developer its working code which is integrated and unit tested, and for QA it is a bug-free code well tested in which is implemented as the unit requirement and for project stakeholder checklist of completion of user stories and so on. so dod has to be determined by the respective team.
The defined set of user stories which defines the degree of completeness is marked as epic and project could have multiple epics which will help in the planning process and implementation.
- Extreme Programming
The process parallelizing and automating a certain task which helps in frequent releases of the project in efficient ways, like pair programming, peer programming, continuous integration.
An attribute of a product which consists of several unit requirements is called a feature.
A blocker results in stopping of an activity is called as an impediment.
The collection of a fixed interval of time in which the team works on tasks aiming the project completion
- Planning Poker
A person who is capable of calling shots..! who is good enough to asses the plan and modify if needed and also asses team with the technical solution in a project.
- Product and Scrum Backlog
The features yet to be completed are called as Backlog respective of product or iteration.
Time provided to add additional changes encountered, clean up the design or the implementation details.
- Release Plan
Defined plan to showcase demonstratable features upon certain epics.
The Framework defined to implement an Agile methodology to achieve iterative and incremental development fashion
- Scrum Team
The team member who is well acquainted with Scrum framework.
A form of impediment where the solution or the answers to certain user stories need to resolve an immediate priority.
- User Story
A simple requirement document which is written in plain English that could easily be understood by the end user, without much or minimum guidance
Unit requirement derived from user story assigned to the single member of a scrum team member.
And now we shall get to know about basic Manifesto of agile copied from agilealliance.org
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
So now we can dive into planing part on adapting the Scrum
Course of Planning:
So we do know short iteration and multiple epics will get more customer collaboration and demonstrable software, so before planning phase, we should allocate an able planning poker (Architect or Technical Manager) and Scrum Master (sometimes client or point of contact are treated as scrum master),
- Keep the user stories ready before planing.
- Do not treat user stories as requirement, formulate unit level requirement based on user stories
- Estimate to unit level requirement but not to user stories
- Do not finalize the number of sprints and epic beforehand.
- Try to resolve the spikes which impact on formulating the unit requirement before estimating
- Plan with presence of Scrum master and planning poker and Scrum team
- Avoid assumption on spikes as much as possible.
Define DOD before execution:
Each team has to formulate their own definition of Done and share across the teams,in most of the cases teams are dependent on the others team so the DOD will help other team to assess the quality and able to suggest few key or required checklist to DOD for smoother execution.
- Prioritize the unit level requirement
- Group them as feature
- Fill the Sprint with unit level requirement and plan the epic based on features
- Plan the release cycles based on epics
- Formulate Task based on unit level requirement
- Assign the task to each member and assess we have enough resources own feature and to parallelize to certain extent and achieve required deadlines feel free to add more members to cross functional teams rather negotiating or enforcing the deadline.
- Plan for sprint hardening
- Always have buffer when allocating the task to individual
- Avoid having buffer during estimation. buffer could vary according to individual experience and nature of work
- Go according to preplanned sprint
- Evaluate the changes and assess the change could be incorporated during sprint hardening or replan to fill the backlog immediately.
- Do not pile up the backlog due to spikes.
- Review the progress in single stand up meeting and select to proper tool to monitor the progress rather having multiple meetings to track progress which provides more time for implementation
- Do not deviate much from plan,if the requirement emphasis on deviating do replan for the changes
- Effectively use sprint hardening to refactor and responding to minor changes
- Always retrospect the sprint by introspecting the cause and deriving a solution.
- Always have proper and resolution for the defective task burndown
- Do not change the task responsibility unless absolute necessity which will help to determine individual contribution and helps to assess the quality of the team and its members
- Parallelize on independent tasks, enforce DoD on dependent tasks.
- Avoid discussing Impediments on breakout allocate different meeting with individual or a team for resolution