Management Information Systems

Agile Methodology

What Is Agile?

Agile software development is based on an incremental, iterative approach. Instead of in-depth planning at the beginning of the project, Agile methodologies are open to changing requirements over time and encourages constant feedback from the end users. Cross-functional teams work on iterations of a product over a period of time, and this work is organized into a backlog that is prioritized based on business or customer value. The goal of each iteration is to produce a working product.

In Agile methodologies, leadership encourages teamwork, accountability, and face-to-face communication. Business stakeholders and developers must work together to align the product with customer needs and company goals.

Agile refers to any process that aligns with the concepts of the Agile Manifesto. In February 2001, 17 software developers met in Utah to discuss lightweight development methods. They published the Manifesto for Agile Software Development, which covered how they found “better ways of developing software by doing it and helping others do it” and included four values and 12 principles. The Agile Manifesto is a dramatic contrast to the traditional Project Manager’s Body of Knowledge (PMBOK) guide and standards.

12 Principles of Agile Methodology

The Agile Manifesto lists 12 principles to guide teams on how to execute with agility. These are the principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• 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.

Advantages of Agile

Agile evolved from different lightweight software approaches in the 1990s and is a response to some project managers’ dislike of the rigid, linear Waterfall methodology. It focuses on flexibility, continuous improvement, and speed.

Here are some of the top advantages of Agile:

• Change is embraced: With shorter planning cycles, it’s easy to accommodate and accept changes at any time during the project. There is always an opportunity to refine and reprioritize the backlog, letting teams introduce changes to the project in a matter of weeks.
• End-goal can be unknown: Agile is very beneficial for projects where the end-goal is not clearly defined. As the project progresses, the goals will come to light and development can easily adapt to these evolving requirements.
• Faster, high-quality delivery: Breaking down the project into iterations (manageable units) allows the team to focus on high-quality development, testing, and collaboration. Conducting testing during each iteration means that bugs get identified and solved more quickly. And this high-quality software can be delivered faster with consistent, successive iterations.
• Strong team interaction: Agile highlights the importance of frequent communication and face-to-face interactions. Teams work together and people are able to take responsibility and own parts of the projects.
• Customers are heard: Customers have many opportunities to see the work being delivered, share their input, and have a real impact on the end product. They can gain a sense of ownership by working so closely with the project team.
• Continuous improvement: Agile projects encourage feedback from users and team members throughout the whole project, so lessons learned are used to improve future iterations.

Disadvantages of Agile

While the level of flexibility in Agile is usually a positive, it also comes with some trade-offs. It can be hard to establish a solid delivery date, documentation can be neglected, or the final product can be very different than originally intended.

Here are some of the disadvantages of Agile:

• Planning can be less concrete: It can sometimes be hard to pin down a solid delivery date. Because Agile is based on time-boxed delivery and project managers are often reprioritizing tasks, it’s possible that some items originally scheduled for delivery may not be complete in time. And, additional sprints may be added at any time in the project, adding to the overall timeline.
• Team must be knowledgeable: Agile teams are usually small, so team members must be highly skilled in a variety of areas. They also must understand and feel comfortable with the chosen Agile methodology.
• Time commitment from developers: Agile is most successful when the development team is completely dedicated to the project. Active involvement and collaboration is required throughout the Agile process, which is more time consuming than a traditional approach. It also means that the developers need to commit to the entire duration of the project.
• Documentation can be neglected: The Agile Manifesto prefers working software over comprehensive documentation, so some team members may feel like it’s less important to focus on documentation. While comprehensive documentation on its own does not lead to project success, Agile teams should find the right balance between documentation and discussion.
• Final product can be very different: The initial Agile project might not have a definitive plan, so the final product can look much different than what was initially intended. Because Agile is so flexible, new iterations may be added based on evolving customer feedback, which can lead to a very different final deliverable.

The Agile Development Cycle

Here are the phases in the Agile development cycle. It’s important to note that these phases shouldn’t happen in succession; they are flexible and always evolving. Many of these phases happen in parallel.

• Planning: Once an idea is deemed viable and feasible, the project team comes together and works to identify features. The goal of this phase is to break down the idea into smaller pieces of work (the features) then to prioritize each feature and assign it to an iteration.
• Requirements analysis: This phase involves many meetings with managers, stakeholders, and users to identify business requirements. The team needs to gather information like who will use the product and how they will use it. These requirements must be quantifiable, relevant, and detailed.
• Design: The system and software design is prepared from the requirements identified in the previous phase. The team needs to think about what the product or solution will look like. The test team also comes up with a test strategy or plan to proceed.
• Implementation, coding or development: This phase is all about creating and testing features, and scheduling iterations for deployment (following the iterative and incremental development approach [IID]). The development phase starts with iteration 0, because there are no features being delivered. This iteration lays down the foundation for development, with tasks like finalizing contracts, preparing the environments, and funding.
• Testing: Once the code has been developed, it is tested against the requirements to make sure the product is actually solving customer needs and matching user stories. During this phase, unit testing, integration testing, system testing, and acceptance testing are done.
• Deployment: After testing, the product is delivered to customers for them to use. However, deployment isn’t the end of the project. Once customers start using the product, they may run into new problems that the project team will need to address.

Methodologies That Are Used to Implement Agile

Agile is a framework and there are a number of specific methods within the Agile movement. You can think of these as different flavors of Agile:

• Extreme Programming (XP): Also known as XP, Extreme Programming is a type of software development intended to improve quality and responsiveness to evolving customer requirements. The principles of XP include feedback, assuming simplicity, and embracing change.

• Feature-driven development (FDD): This iterative and incremental software development process blends industry best practices into one approach. There are five basic activities in FDD: develop overall model, build feature list, plan by feature, design by feature, and build by feature.

• Adaptive system development (ASD): Adaptive system development represents the idea that projects should always be in a state of continuous adaptation. ASD has a cycle of three repeating series: speculate, collaborate, and learn.

• Dynamic Systems Development Method (DSDM): This Agile project delivery framework is used for developing software and non-IT solutions. It addresses the common failures of IT projects, like going over budget, missing deadlines, and lack of user involvement. The eight principles of DSDM are: focus on the business need, deliver on time, collaborate, never compromise quality, build incrementally from firm foundations, develop iteratively, communicate continuously and clearly, and demonstrate control.

• Lean Software Development (LSD): Lean Software Development takes Lean manufacturing and Lean IT principles and applies them to software development. It can be characterized by seven principles: eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, and see the whole.

• Kanban: Kanban, meaning “visual sign” or “card” in Japanese, is a visual framework to implement Agile. It promotes small, continuous changes to your current system. Its principles include: visualize the workflow, limit work in progress, manage and enhance the flow, make policies explicit, and continuously improve.

• Crystal Clear: Crystal Clear is part of the Crystal family of methodologies. It can be used with teams of six to eight developers and it focuses on the people, not processes or artifacts. Crystal Clear requires the following: frequent delivery of usable code to users, reflective improvement, and osmotic communication preferably by being co-located.

• Scrum: Scrum is one of the most popular ways to implement Agile. It is an iterative software model that follows a set of roles, responsibilities, and meetings that never change. Sprints, usually lasting one to two weeks, allow the team to deliver software on a regular basis.

Other Practices in Agile

There are many other practices and frameworks that are related to Agile. They include:

• Agile Modeling (AM): Agile modeling is used to model and document software systems and is a supplement to other Agile methodologies like Scrum, Extreme Programming (XP), and Rational Unified Process (RUP). AM is not a complete software process on its own. It can help improve models with code, but it doesn’t include programming activities.

• Rational Unified Process (RUP): Created by the Rational Software Corporation, a division of IBM, RUP is an iterative, adaptive framework for software development. According to Rational, RUP is like an online mentor that provides guidelines, templates, and examples for program development. The key aspects of RUP include a risk-driven process, use case focused development, and architecture-centric design.

• Lean vs Agile: Lean development focuses on eliminating and reducing waste (activities that don’t add any value). Lean development takes the principles from Lean manufacturing and applies them to software development. These principles are very similar to Agile, however Lean takes it one step further. In the development phase, you select, plan, develop, test, and deploy only one feature before you repeat the process for the next feature.

• Test-Driven Development (TDD): Test-driven development relies on repetitive, short development cycles. First, a developer writes an (initially failing) automated test case for a new feature and quickly adds a test with the minimum amount of code to pass that test. Then, he refactors the new code to acceptable standards.

• Scaled Agile Framework (SAFe trademark logo): The Scaled Agile Framework is a very structured method to help large businesses get started with adopting Agile. SAFe is based on Lean and Agile principles and tackles tough issues in big organizations, like architecture, integration, funding, and roles at scale. SAFe has three levels: team, program, and portfolio.

• Rapid Application Development (RAD): RAD’s approach to software development puts more emphasis on development than planning tasks. It follows an incremental model, where each component is developed in parallel. The phases in RAD are: business modeling, data modeling, process modeling, application generation, and testing and turnover.

• Empirical Control Method: With Agile software development, you can use an Empirical Control Method, which means that you make decisions based on the realities you observe in the actual project. The empirical model of process control has three parts: visibility, inspection, and adaption.

How to Estimate Budgets in Agile

Without in-depth, upfront planning, many project managers are unsure of how to calculate the cost and budget of an Agile project.

Estimating the cost before the project even starts can always be challenging, regardless of which project methodology you use. However, in an Agile project, you can tie the amount of time the project will take with its total cost.

First, create a burndown chart and use the burndown rate to estimate how many sprints will be in your project and when the project will end. Then, calculate how much the team will cost based on their hourly rates. Multiply each person’s rate by the number of working hours per week, then multiply that by the number of weeks in a sprint. Once you estimate the initial budget for your team, you can add any other costs, like technology, travel, or equipment.

You could also break down each user story into tasks. Once you have an idea of how many hours it will take to complete each task, you can estimate the project budget.

And lastly, you could use planning poker to estimate the effort required for development goals. Planning poker is a consensus-based, gamified technique for estimating the effort of development goals. Each team member makes estimates by playing numbered cards face-down on the table, instead of saying it out loud. The cards are then revealed and the estimates discussed with the whole team.

Agile and Pair Programming

Pair programming (also known as “pairing”) is part of the Extreme Programming (XP) practices. It is when two programmers share a single workstation, which includes sharing one screen, keyboard, and mouse. The purpose of this technique is to encourage better communication, clarification of the problem, and understanding of the solution. Pairing is often used in Agile projects to quickly deliver high-quality products, but is it always required?

The answer depends on your programmers, company, and goals. For some projects and programmers, pairing might improve productivity. However, it may not always be appropriate for every project. The best thing to do is experiment and see if it works for you.

How Agile Addresses Software Requirements

Agile helps development teams focus on customers’ most important requirements as quickly as possible. With continuous feedback and frequent face-to-face interactions, the project team and stakeholders understand and prioritize the right requirements.

Agile teams use backlogs with user stories to manage requirements. Before an iteration begins, the team agrees on which requirements they should meet with the next delivery. This collaborative approach ensures that the most important features get prioritized. And, requirements are continuously updated throughout the project as new information is surfaced.

Can You Use Agile for Projects Outside of Software?

While Agile was traditionally created for software development, it can also be used in many other projects and industries.

It’s important to remember that Agile software development was born from the principles of Lean manufacturing and organizational learning. These ideas weren’t based on software to begin with. And, many practices in Agile, like stand-up meetings and visual management, are so common and can apply to any industry.

There are not many case studies of teams using Agile for things outside of software, but there are a couple. For example, Kate Sullivan, a corporate lawyer on The Lonely Planet legal team, has transformed the legal affairs service delivery with Agile. The team uses whiteboards and cards, morning stand-up meetings, prioritization, weekly iterations, and regular retrospectives.

Agile can definitely be applied to projects outside of software development, you just have to find the right method and approach for your needs. You can start with boards and cards, a work backlog, stand-up meetings, or iterations (weekly planning meetings) to see how your team responds.

How to Get Started with Agile

A simple way to get started with Agile is to incorporate daily stand-up meetings into your project. Daily stand-up meetings are easy to incorporate into any other project methodology you may already be using (even Waterfall) and don’t require any training or knowledge transfer. Meet at the same spot every day for about ten minutes and have everyone talk about what they worked on the day before, what they’ll work on today, and any roadblocks.

If you want to make the complete switch to Agile all at once, you may want to start with understanding why the team and organization want to make this change. What is and isn’t working? What are they looking to improve? Then, you could conduct an Agile assessment, getting a complete view of the people, skills, and technologies used.

Whichever route you choose, remember that Agile is flexible in its very nature. There is no wrong or right way to get started with Agile. Do what works for you and your team.

Smartsheet's newest view, Card View, gives Agile teams a more highly-visual way to work, communicate, and collaborate in Smartsheet. Card View enables you to focus attention with rich cards, give perspective with flexible views, and prioritize and adjust work more visually. Display information on cards including custom fields, images, and color coding to better focus your team’s attention. Categorize cards into lanes to organize your work more visually.

Scrum Methodology

What Is Scrum?

Scrum is a subset of Agile and one of the most popular process frameworks for implementing Agile. It is an iterative software development model used to manage complex software and product development. Fixed-length iterations, called sprints lasting one to two weeks long, allow the team to ship software on a regular cadence. At the end of each sprint, stakeholders and team members meet to plan next steps.

Scrum follows a set of roles, responsibilities, and meetings that never change. For example, Scrum calls for four ceremonies that provide structure to each sprint: sprint planning, daily stand-up, sprint demo, and sprint retrospective. During each sprint, the team will use visual artifacts like task boards or burndown charts to show progress and receive incremental feedback.

Jeff Sutherland created the Scrum process in 1993, taking the term “Scrum” from an analogy in a 1986 study by Takeuchi and Nonaka published in the Harvard Business Review. In the study, Takeuchi and Nonaka compare high-performing, cross-functional teams to the Scrum formation used by Rugby teams. The original context for this was manufacturing, but Sutherland, along with John Scumniotales and Jeff McKenna, adapted the model for software development.