As opposed to a conventional approach, Agile project management philosophy has been presented as an attempt to make software engineering more flexible and efficient.
Agile principles are all about being collaborative, flexible and adaptive. It is built on the premise that the world now changes regularly, and that means software teams no longer have years to bring new products to market. In that time, contender offerings or customer expectations can change, and the team risks irrelevance too. Agile depreciates this risk by helping teams cooperate together more by adapting to what the team needs to be successful. It does this by encouraging teams to regularly show off their work and gather feedback so that they can adapt to change quickly.
The Importance of “Why” – 12 Principles of Agile
Adaptability - Empirical process control and iterative delivery make projects adaptable and open to incorporating change.
Transparency - All information radiators like a Scrum board and Sprint Burndown Chart are shared, leading to an open work environment.
Continuous Feedback - Continuous feedback is provided through the Conduct Daily Standup, Demonstrate and Validate Sprint processes.
Continuous Improvement - The deliverables are improved progressively Sprint by Sprint, through the Groom Prioritized Product Backlog process.
Continuous Delivery of Value - Iterative processes enables the continuous delivery of value through the Ship Deliverables process as frequently as the customer requires.
Sustainable Pace - Scrum processes are designed such that the people involved can work at a sustainable pace that they can, in theory, continue indefinitely.
Early Delivery of High Value - The Create Prioritized Product Backlog process ensures that the highest value requirements of the customer are satisfied first.
Efficient Development Process - Time-boxing and minimizing non-essential work leads to higher efficiency levels.
Motivation - The Conduct Daily Standup and Retrospect Sprint processes lead to greater levels of motivation among employees.
Faster Problem Resolution - Collaboration and colocation of cross-functional teams lead to faster problem-solving.
Effective Deliverables - The Create Prioritized Product Backlog process and regular reviews after creating deliverables ensures effective deliverables to the customer.
Customer Centric - Emphasis on business value and having a collaborative approach to stakeholders ensures a customer-oriented framework.
High Trust Environment - Conduct Daily Standup and Retrospect Sprint processes promote transparency and collaboration, leading to a high trust work environment ensuring low friction among employees.
Collective Ownership - The Approve, Estimate, and Commit User Stories process allows team members to take ownership of the project and their work leading to better quality.
High Velocity - A collaborative framework enables highly skilled cross-functional teams to achieve their full potential and high velocity.
Innovative Environment - The Retrospect Sprint and Retrospect Project processes create an environment of introspection, learning, and adaptability leading to an innovative and creative work environment.
Who is it for?
Because of its fast iterations, Scrum is best suited for teams whose customers and stakeholders want to be actively involved by regularly seeing working products at showcase meetings. This collaboration allows the team to make changes for upcoming showcases. Key team members who should be involved when taking a Scrum approach include:
The Agile Story is supposed to be the start of a conversation. These Stories will usually identify a feature or function to be created within the product. It may be created by any member of the team, and often contributions are made by Stakeholders as well.
The raw stories will be placed in the product backlog for review and refinement by the entire team in Grooming ceremonies if the Product Owner finds the story to be worthy.
Worth consideration as part of a Story is also that the Product Owner must include a description of what is expected as Acceptance Criteria, these define minimum requirements for this piece of the product to be considered “Done”. These items are often used as the outline for testing the Story.
Slightly out of the scope of the Story is the area of “Possible Tasks”. Since tasking of the story is usually done in the Sprint Planning ceremony, most teams will hold off on any tasking efforts till then. However, it may be prudent of a team to talk about and even notate possible tasks as the Story is discussed in the “Grooming” effort since it is fresh in their minds at that point.
When a Story is being considered for inclusion in a Sprint, keep in mind that the Story must be able to be completed in a single Sprint. If not, then the Story should be split or “Decomposed” into multiple stories.
* NOTE: "This study material is collected from multiple sources to make a quick refresh course available to students."