Agile Fundamentals

Today many organizations are adopting Agile software development principles to improve software quality and reliability, and to reduce time to market. In this module, you will learn about Agile, and how it is different from traditional software development.

At the end of this article, you should be able to:

• Describe What Agile Is, and How it Differs from Traditional Software Development
• Identify How Agile Is Being Used World-Wide, and Sources You Can Access to Improve Your Knowledge on This Topic

Agile is an approach to software development. But before you learn how it works, you first need to look at how software applications have been traditionally developed.

Definition: A software development approach recommending that planning, development and testing before performed in short ‘sprints’ by small, self-organized teams

Suppose you want to create a new mobile app myFlights. This app will manage all flight reservations for the user for all airlines.

You cannot develop software without knowing what you want it to do. So, you will start by creating a list of application features, what it will do, and how users will use it. You will also decide when you want it ready, and from this begin to create budgets and staffing.

Or, in other words, you will commence planning your application.

In your case, you want an app with these features ready in one year. It will be available for iPhone and Android devices and will also have a web interface.

Traditional software development begins with a planning phase. This planning covers the entire project, and includes specifications, and a detailed plan on how the project will progress. In traditional development this plan is quite detailed and is used throughout the project.

This planning phase is then followed by the actual software development, and finally a phase to test the final software product. Each phase normally completes before the next phase starts. So, you would complete your planning phase before commencing development.

Planning -> Development -> Testing

Suppose you finish your development phase, but into your test phase the specifications or requirements for Android applications changes. Or Android releases a new version with features that users will quickly see as essential.

(Android requires apps to be coded differently)

Your project is in trouble, you will need to go back and redo your planning and some of your software development. Traditional software development is often called Waterfall development, it flows in one direction and is difficult to go back.

The change here for Android applications is one of many possible issues that could happen in a software development project. These changes could be related to the following areas:

• Technical — such as new tools, frameworks, or features
• Market — such as changes in user needs or usage patterns
• Business — such as budget changes

With software development projects, these issues can happen very quickly, and with little notice.

Risks in Software Development

Business
• Change in timeline, get it to market faster
• Budget changes or reductions
• Staffing changes
• Customers change their minds

Technical
• Proposed solution does not work
• New devices or environments
• Changed standards or features
• Frameworks or other software used changes

Market
• Similar software appears on the market
• New security or compliance issues
• New information changes requirements
• New tools or software could change the project

With Agile development, the same planning, development, and testing phases are performed. But rather than having one set of phases — plan, develop, test, it is broken up into many smaller sets. Each set is sometimes called a sprint.

Each sprint delivers a workable product with some of the features required. They deliver production quality software that is ready for users to begin using.

How does traditional waterfall development differ from agile development, and what new practices will you need to introduce?

• The project is split into small sprints.
• Each sprint consists of a planning, development, and testing phase.
• Each sprint produces a product that is ready for users.

Even if you are breaking the project up into sprints, there is some planning that must happen at the beginning of the project — determining overall needs and deciding what sprint will do what. However, this initial planning phase will be much shorter for Agile projects.

Here, sprints are shown as sequential, one after the other. However, this may not be the case, and some sprints may be able to be performed in parallel by different teams.

Consider how this could work with your myFlights app. You want to produce your final product in one year. In your project, you will divide it up into 22 sprints. Some of these sprints can be developed in parallel. For example, you could develop iPhone and Android features side by side.

Each sprint will add a new feature to your app. At the end of each sprint, there will be a production quality software product with that feature, and any previous features, ready for the users to use.

For example, you will have a web application that can view an existing booking and display a boarding pass in the first month of your project.

Dividing the project up into sprints makes it, well, more Agile. At the beginning of every sprint, the objective of the sprint is determined, and then actioned. So, if something changes, the objectives of each sprint could change as required. There are several other advantages to this style of programming.

• Earlier to market: Each Agile sprint produces a production quality software product ready for use. So, a version of a software product with some of the features can be released to the market earlier.
• User verification: As each sprint produces a product ready for use, users can start using it early in the project. Feedback from these users can be used to improve the product as it is developed, and make sure that it is satisfying their needs. This is important because many software products are developed without fully matching the user’s needs.
• Approach Verification: It is possible that an approach or decision made early in the project will not work. As each sprint produces a product ready for use, decisions or approaches that will not work are detected earlier in the development of the project.
• Adapt to changes: Although some planning is performed at the beginning of the project, individual sprint planning can reflect changes made in earlier completed sprints. So, the objectives of each sprint can be modified as circumstances change. In this example, if Android specifications change, you may incorporate these changes into a sprint, and delay some development to a later sprint.
• Frequent reviews: After each sprint, application development teams review the product after testing. This review can help future sprints to perform better or improve the product.

In software development projects, there can be a lot of people involved, planners, software developers, testers, and more. Because of this, there can be poor communication, or a disconnect between members of a software development team.

One of the principles of Agile is to improve communication. Agile does this by proposing small, self-organized teams. These teams do not consist only of developers or planners. Rather, they are made up of planners, developers, and testers for each sprint. For example, you may assign one planner, two software developers, and one tester to the team producing sprint number two.

The beginnings of Agile date back to 2001, when a group of 17 software developers met in Utah to discuss lightweight development methods.

At this time, many software development projects were unsuccessful. For example, they did not satisfy the user, or vastly over-ran budgets. Business users were often frustrated at the time it took to develop applications, and many projects were cancelled mid-flight.

To address these problems, the 17 developers published a document called the Manifesto for Agile Software Development. This is regarded by many as the basis of Agile software development.

Previous Software Development Problems:
• Budget over-run
• Too slow
• User’s needs changed during the project
• Did not satisfy user requirements
• Project cancelled

Agile Manifesto

This Manifesto proposed four key values to improve software development. These values did not concentrate on technical issues but were more about the approach to software development, changing the focus of software development projects.

Agile Values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

To achieve these 4 values, the Manifesto proposed 12 development principles.

It can be seen from these that Agile is not simply the breaking up of a project into small sprints. It also addresses communication, technical excellence, user needs, and more.

Environment

Customer Satisfaction: Customers are happier when they receive working software at regular intervals, rather than waiting for long periods of time between releases.

Changing Requirements: Agile aims to accommodate changing requirements throughout the development process, and even towards the end of the project.

Frequent Delivery: Deliver working software frequently, from a couple of weeks to a couple of months — the shorter the gap between releases, the better.

Technical

Working Software: Working software is the primary measure of progress.

Simplicity: Simplicity is essential, do not create more work than is necessary to get the job done.

Technical Excellence: Continuous attention to technical excellence and good design.

Teams

Working Together: Close, daily cooperation between business people and developers.

Trust: Projects are built around motivated individuals who are trusted.

Face-to-Face: Face-to-face is the best form of communication within a development team.

Sustainable Development: Development should be at a sustainable pace — a pace
that can be maintained by team members indefinitely.

Self-Organized Teams: The best results — architectures. requirements, and designs — come from self-organized teams.

Regular Review: The team regularly reflects on how to become more effective and adjusts accordingly.

So far, you have seen that Agile is an approach to software development that breaks up development into many small sprints, each producing a product that is ready for use by a user. Each sprint is performed by a small, self-organized, cross-disciplinary team.

Next, you will look at some examples showing how Agile is implemented in the real world, and some of the resources available for Agile adoption.

You saw that Agile is an approach to software development. However, it does not state how it can be achieved, rules that must be followed, or how different teams should work together. In other words, it is an idea, not a framework, methodology, or set of standards.

Rather than create new concrete procedures and rules to implement Agile, most organizations adopt an Agile framework or methodology. These provide the rules and procedures necessary without the organization having to create them from scratch. Some of the more popular of these include Scrum, Kanban, and Extreme Programming (XP).

Agile Frameworks

Agile itself is an idea, not a framework.

Scrum: Dating back to the 1990s, the scrum framework proposes three core roles, product owner, development team, and scrum master — a project manager tasked to be a buffer between development teams and anything that may distract them from their goals.

Kanban: Kanban has its origins in the late 1940s as Toyota began optimizing its engineering processes based on the same model as supermarkets used to stock their shelves. The same principles can be adopted for software development, producing an Agile operation. Kanban does not propose specific roles but is based around a Kanban board — a tool used to visualize work and optimize the flow of teams.

Extreme Programming (XP): XP was originally developed during a payroll project for Chrysler in the 1990s. It breaks down the development activities into tour activities — coding, testing, listening, and designing.

SAFe: Initially released in 2011, Scaled Agile Framework (SAFe) is a framework managed by Scaled Agile. This organization also offers resources, certification, and training associated with this framework.

DSDM: Dynamic Systems Development Method (DSDM) was introduced by the DSDM Consortium, now called the Agile Business Consortium, in the 1990s. Sometimes called AgilePM, though AgilePM is a DSDM accreditation.

Scrum

So, what do Agile frameworks provide? Now you will look at an example of a popular Agile framework, Scrum.

1. A product owner creates a prioritized list of required features. This is called a product backlog.
2. During sprint planning, items are selected from the backlog by a small team of three to nine people. This development team determines how to develop those items.
3. The development team develop the items in a timeboxed sprint — it must be completed in a set time, usually around two weeks.
4. The development team meets every day in a short meeting called a scrum or stand up. This meeting occurs at the same time every day and is also timeboxed, usually to 15 minutes.
5. During this scrum, every team member answers the following questions:
   - What did you do yesterday to contribute to the team meeting the sprint goal?
   - What do you plan to do today to contributed to the team meeting the sprint goal?
   Do you see anything that may block or prevent you or the team from meeting the sprint goal?
6. During the development, a manager called a scrum master keeps everything running in the sprint and notes any block or issues that may affect the sprint.
7. At the end Of development, a product is ready. The development team perform a sprint review — present the product to the product owner, review work that was and was not completed, and collaborate with the product owner and other stakeholders on what to do in the next sprint.
8. Finally, a short retrospective meeting — one and a half hours for a two-week sprint, reflects on the just completed sprint, and what can be improved. Then the cycle starts again.

Scrum provides recommendations on the following:

Duration of sprints: 1–4 weeks
Scrums: approximately 15 minutes
Retrospectives: 1.5 hours, and other parts of the scrum.

Agile and Agile frameworks do not replace existing project management frameworks such as PRINCE2 and PMBOK. They also do not address many of the problems covered by service delivery frameworks such as ITIL, ISO20000, ASL, or BiSL. However, there may be overlaps in each of the frameworks or standards used.

Many organizations implementing Agile are faced with the issue of using Agile frameworks alongside, or within, these other frameworks.

Agile and Lean

Lean is an approach to software development that in many ways is similar to Agile. Lean is principled on minimizing work — only doing the absolute minimum, at the latest possible time.

Lean and Agile come from different beginnings and approaches, but attempt to address the same problems and in doing so, they often provide similar proposals. However, Lean is not Agile: they are different approaches.

Eliminate Waste: Remove any action or activity that does not directly add value to the finished product.

Build Quality In: Any issues found throughout development are fixed immediately, ensuring the quality of the product.

Create Knowledge: Teams continuously learn from each other and from project strategies that have been successful.

Defer Commitment: Not all final project specifications need be defined or committed to at the beginning of the project, providing product flexibility.

Deliver Fast: Teams work to their capacity in order to produce high quality systems quickly.

Respect People: It is an advantage in terms of motivation, for project teams to be self-managed, rather than controlled.

Optimize the Whole: You need to look at the project at a high level, understanding what it brings to the business, and other areas it affects.

DevOps is another popular approach to software engineering. Building on Agile principles, DevOps aims to unify software development and software operations. It proposes the use of automation in all stages of development, integration, testing, and deployment.

DevOps and Agile in many ways complement each other, and in some cases, overlap.

Many of the tools used in traditional software development are just as useful in Agile projects. For example, software configuration management (SCM) software to manage source code and releases.

There are other products on the market that assist in planning, reporting, and communication for Agile projects. These provide features include sprint management, progress reporting, and communication between team members.

Some of the Agile management tolls are:

• IBM Relational Team Concert
• CA Agile Central
• Oracle Agile PLM
• Atlassian Jira
• ActiveCollab
• VersionOne Lifecycle

There are several Agile courses that are available. However, as Agile is an approach and not a framework or methodology, there are few Agile certifications. One exception is the PMI Agile Certified Practitioner certification from the Project Management Institute.

Most Agile certifications are tied to specific frameworks or methodologies. For example, several organizations offer Certified ScrumMaster certification training, which is administered by Scrum Alliance.

Although Agile certifications are an excellent way to learn about Agile and the specific frameworks used to implement it, they are not the only way to learn about Agile.

Many colleges, universities, and other training organizations provide Agile courses for developers, managers, and product owners.

Training is also available to assist project managers familiar with PRINCE2 and PMBOK, on how to use these project management frameworks with Agile software development.

There are also many websites, including Wikipedia, InfoQ, and Scrum Alliance, and books that provide more information about Agile and Agile frameworks.

Surveys have found that most organizations performing software development have adopted Agile to some degree. For example, a Computer Economics survey showed 55% of respondents had adopted Agile in 2016.

Agile has been adopted by high profile companies including IBM, Google, Oracle, and Amazon. However, traditional Waterfall development is still performed in many organizations.

Summary

• Agile is an idea or approach, most organizations use an existing framework
  such as Scrum to guide implementation.
• Agile often must work with other frameworks for project management, such as
  PRINCE2, and service management, such as ITIL.
• Agile is not Lean or DevOps, though there are similarities.
• Agile is very popular, and most organizations involved in software development will be considering using it to some degree.
• Most Agile accreditation is tied to individual Agile frameworks.
• There are many courses about Agile, as well as web-based resources and books.

Conclusion

I hope you’ve enjoyed it and have learned something new. I’m always open to suggestions and discussions on LinkedIn. Hit me up with direct messages.

If you’ve enjoyed my writing and want to keep me motivated, consider leaving starts on GitHub and endorsing me for relevant skills on LinkedIn.

Till the next one, happy coding!