The ability to create and respond to change in order to succeed in an uncertain and turbulent environment. Agile methodologies focus on rapid and frequent deliverables of partial solutions that can be evaluated and used to determine next steps. Successful agile teams can produce higher-quality software better meeting user needs quicker and at a lower cost.
According to Agile Alliance:
"Agile Software Development is an umbrella term for a set of methods and practices based on the values and principles expressed in the Agile Manifesto."
Agile Software for Scrum Teams
Need an agile software solution for product backlog management? Visual Paradigm supports a powerful agile toolset that covers user story mapping, affinity estimation, sprint management, etc. It's powerful but yet easy-to-use, intuitive and, most important, AGILE.
Free Download
Manifesto for Agile Software Development
The motivated individuals with similar point of view in around 2000, brought out a set of ideas and values that are known as the Agile Manifesto. There are four important aspects that make up the Agile Manifesto as listed below:
Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Please note items on the left have greater value on them than items on the right; It should be read as left is important "over" right and should not to be replaced with "instead".
Principles of the Agile Manifesto:
The core Agile Manifesto values are captured in twelve principles:
- To satisfy customer through early and continuous delivery of valuable software is the highest priority.
- Changes of requirements is always welcomed, even late in development. Agile processes harness change for the customer's competitive advantage.
- Maintain a frequent rate of delivering working software, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business stakeholder and developers must work together daily throughout the project.
- Conduct projects around motivated individuals. Give them the environment, resources and other support they need, and trust them to get the job done.
- The most efficient and effective way of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of the progress of project.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity - the art of maximizing the amount of work not done - is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The different Agile methodologies provide prescriptive practices to put these values and principles into action and can be visualized by a interesting mindmap.
The History of Agile
Although the roots of Agile may go back to the 50's Test Driven Development with Project Mercury, things really began to pickup in the early 90's with James Martin's RAD (Rapid Application Development). Then things picked up in the mid-90's with the advent of RUP (Rational Unified Process) and Scrum, followed by XP (Extreme Programming) in the late 90's. but the real watershed moment for the Agile movement was the publication of The Manifesto for Agile Software Development in 2001 by a group of 17 software developers, who met to discuss the collection of lightweight development methods, which is now referred to as Agile methods.
- 1974 - An adaptive software development process documented
- 1991 - "Rapid Application Development" published
- 1995 - DSDM Framework published
- 1995 - SCRUM presented at OOPSLA
- 1996 - XP Practices developed on C3 project
- 1997 - FDD processes designed by Jeff De Luca
- 1999 - FDD described in "Java Modeling in Color with UML"
- 1999 - "Extreme Programming Explained" published
- 1999 - "Adaptive Software Development" published
- 2001 - Crystal Light methodologies described in Cutter IT Journal,
- 2001 - Agile Manifesto written
- 2003 - "Lean Software Development: An Agile Toolkit for Software Development Managers" published
Agile vs Traditional Development
Typically in plan driven model, scope is fixed and the cost and schedule are variables. Many large scale software projects were and continued to be implemented this way. In many instances, when a particular scope is desired within a giving time-frame (fixing the schedule), plan driven projects add resources. But as we know simply adding resources to a project doesn't always bring about the desired goals.
As a matter of fact, if resources are added late on a software project, it actually has an adverse effect. This was indeed observed by Fred Brooks in his book The Mythical Man Month, also known as Brooks' Law: "adding manpower to a late software project makes it later".
With Agile software development, the triangle gets inverted - where cost and schedules are fixed and the scope is variable.
Traditional Waterfall
- Scope is fixed, cost and schedules are variables
- Systems are fully specifiable, predictable, and can be built through extensive planning.
Agile
- Cost and Schedules are fixed, scope is variable
- Adaptive software can be developed by small teams using the principles of continuous design improvement and testing based on rapid feedback and change.
Scrum: An Agile Development Framework
Scrum is one of the most popular frameworks for implementing agile. So popular, in fact, that many people think scrum and agile are the same thing. Actually they're not. Both Agile and Scrum are terms used in project management. The Agile methodology employs incremental and iterative work beats that are also called sprints. Scrum, on the other hand is the type of agile approach that is used in software development. In other words, many frameworks can be used to implement agile, such as Kanban for example, but scrum has a unique flavor because of the commitment to short iterations of work.
Vision
It's important to understand why we are doing what we are doing, who it is for, and the overall market opportunity. Agile software development projects start with a series of Discovery Sessions and research to understand a client's goals, challenges, business climate, and customers and users. These sessions include key members of the project team including the client, project manager, designer, developer, and product owner to ensure a shared understanding across the entire team.
The Product Backlog
Product backlog is the master list of things that we want to build into the product. During Vision step, the team works together to create a high level Product Backlog, a wish list of all the features that would be useful to the client and their users. The product owner works with the client to prioritize these features, determining the order in which the features are elaborated, developed, tested, and delivered. By allowing the client to determine priority, the team stays focused on delivering the highest value features before moving on to lower value features.
Iteration Backlog
After ensuring the team understands the client's vision and has created a high level backlog of features, the team delivers features through a series of time-boxed iterations called Sprints. These are fixed durations of 1-4 weeks (depending on project size and duration), each delivering a subset of the overall product backlog.
Continuing the Cycle
Additional Sprints are conducted as needed to deliver additional features and incorporate feedback from previous iterations, reviews, and user beta testing. Each successive Sprint is both Iterative, providing improvements to work completed in previous sprints; and Incremental, adding new features to the system.
How does Scrum Framework Work?
Scrum is an agile framework most commonly used for product development, especially software development. Scrum is a project management framework that is applicable to many different type of projects with tough deadlines, complex requirements and a degree of uniqueness. In Scrum, projects move forward via a series of iterations called sprints. Each sprint is typically two to four weeks long. A typical scrum process can be summarized as follows:
- Ideal team size is 5 to 9 people
- Team has everything it needs to deliver an increment of working product
- Very clear role and responsibility delineation: Scrum Master, Product Owner, Team
- Product Owner brings the what
- Team decides the how
- WIP is limited by the velocity of the team
- Scrum Master's job is to get rid of the stuff slowing the team down
- The idea is to deliver in short sprints...
- ...use empirical process control, inspect and adapt
- Totally designed to be a lightweight framework for delivering products in the face of uncertainty
A Generic Agile Development Cycle
- Product backlog - A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. A typical Scrum backlog comprises the following different types of items:
- Features
- Bugs
- Technical Work
- Knowledge Acquisition
- Sprint Planning - In scrum methodology each work iteration is called a Sprint.
- Every Scrum begins with the sprint planning meeting.
- In which the Product Owner and the team(s) discuss which stories will be moved from the Product Backlog into the sprint backlog.
- It is the responsibility of the Product Owner to determine what work the team will do.
- Once the team commits to the work, the Product Owner cannot add more work or micromanage.
- The Product Owner can cancel a Sprint, which shouldn't happen often, and would usually occur due to a sudden change in business needs.
- Burndown
- "A burn down chart is a graphical representation of work left to do versus time.."
- The daily analysis of task remaining and time remaining to complete the sprint and assess whether we are on time or behind the schedule.
- Daily Scrum - Every day each scrum team members report to scrum master and each other
- what they did the previous day
- what they will do today and
- What are the road blockers?"
- Sprint Review - Sprint review meet is held at the end of each sprint and a demonstration of developed work will be done to stakeholders
- The meeting itself should be strictly time boxed to no more than an hour per week of Sprint.
- A two-week Sprint would have a two-hour review and a one-week sprint a one-hour review.
- Sprint Retrospective - At the end of the sprint whole team gathers to reflect how things went and what they'd like to change. This meeting is called the Sprint Retrospective meeting.
- What worked well?
- What didn't work well?
- Actions to improve
Scrum Roles
A scrum team has a slightly different composition than a traditional waterfall project, with three specific roles: product owner, scrum master, and the development team described as follows:
Scrum Development Team
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team's overall efficiency and effectiveness. Development Teams have the following characteristics:
- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
- Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;
- Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
- Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
Product Owner
The product owner is a role on a product development team responsible for managing the product backlog in order to achieve the desired outcome that a product development team seeks to accomplish. Key activities to accomplish this include:
- Clearly identify and describe product backlog items in order to build a shared understanding of the problem and solution with the product development team
- Make decisions regarding the priority of product backlog items in order to deliver maximum outcome with minimum output
- Determine whether a product backlog item was satisfactorily delivered
- Ensure transparency into the upcoming work of the product development team.
Scrum Master
A scrum master is a member of a software development team that is practicing scrum which is the best known and most widely used Agile software development framework. The scrum master's key role include:
- Works with the organization to make Scrum possible
- Ensures Scrum is understood and enacted
- Creates an environment conducive to team self-organization
- Shields the team from external interference and distractions to keep it in group flow (a.k.a. the zone)
- Promotes improved engineering practices
- Has no management authority over the team
- Helps resolve impediments
- Has a leadership role
Note That:
Because of scrum teams are cross-functional, the development team includes testers, designers, and ops engineers in addition to developers, or some of developers could play multiple roles.
Scrum Meetings
All Scrum Meetings are facilitated by the Scrum Master, who has no decision-making authority at these meetings.
Sprint Planning Meeting
The Sprint Planning Meeting is the first meeting to kick off the sprint. The meeting is time boxed to 8 hours usually on a Monday morning, which involves a Scrum Master, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint, these can be in the form of user activities, epics, user stories, or just a list of requirements. Here is a rough outline of a Sprint Planning Meeting:
- Communicate the scope of work that is intended to be done during that sprint
- Select product backlog items that can be completed in one sprint
- Prepare a sprint backlog that includes the work needed to complete the selected product backlog items
- The recommended duration is four hours for a two-week sprint (pro-rata for other sprint durations)
- During the first half, the whole scrum team (development team, scrum master, and product owner) selects the product backlog items they believe could be completed in that sprint
- During the second half, the development team identify the detailed work (tasks) required to complete those product backlog items; resulting in a confirmed sprint backlog
- As the detailed work is elaborated, some product backlog items may be split or put back into the product backlog if the team no longer believes they can complete the required work in a single sprint
- Once the development team has prepared their sprint backlog, they forecast (usually by voting) which tasks will be delivered within the sprint.
Sprint Review Meeting
At the end of the Sprint, the Scrum Team holds a Sprint Review Meeting to demonstrate a working product increment to everyone who is interested, particularly outside stakeholders. The meeting should feature a live demonstration, not a report. The Sprint Review includes the following elements:
- Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
- The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done";
- The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
- The Development Team demonstrates the work that it has "Done" and answers questions about the Increment;
- The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date (if needed);
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
- Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
- Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated release of the product.
- The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.
Sprint Retrospective Meeting
The Sprint Retrospective meeting is held at the end of every Sprints, usually following the Sprint Review meeting. Where the purpose of the Sprint Review Meeting is to review what the team built during the Sprint and What to do next, the purpose of the Sprint Retrospective meeting is to review ho the team worked during the previous Sprint and to make improvement to its processes and practices. The Sprint Retrospective meetings typically involve:
- Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
- The recommended duration is one-and-a-half hours for a two-week sprint (pro-rata for other sprint durations)
- This event is facilitated by the scrum master
Summary
Agile method came into existence after the need for a light way to do software development in order to accommodate changing requirements environment. It is a particular approach to project management that is utilized in software development. This method assists teams in responding to the unpredictability of constructing software. Agile Method describes a set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to
change.
Ready for Agile?
Want an agile tool that can manage your scrum projects well? Visual Paradigm features a user story mapping tool, Affinity Estimation tool, sprint management tool, and task management.
Try it Free
