An Intro To Agile Development

Introduction

As I continue to learn software development after boot camp I try to prioritize what I should learn in order to improve my skills. I keep a running list of requirements that come up frequently in job postings and I’m learning them one at a time. One thing that seems to pop up in job listing requirements regardless of it’s tech stack is Agile Development experience. Lets look at the oxford definition for the word agile to perhaps get some clues as to what this means:

agile adjective
1. able to move quickly and easily
2. able to think quickly and in an intelligent way
3. used to describe a way of managing projects in which work is divided into a series of short tasks, with regular breaks to review the work and adapt the plans
4. used to describe a way of working in which the time and place of work, and the roles that people carry out, can all be changed according to need, and the focus is on the goals to be achieved, rather than the exact methods used

Out of each of these #4 is the closest to what we are about to delve into. Agile is a methodology that allows for very effective and efficient software development. There are different frameworks that implement the Agile methodology in different ways. Some of these include: Scrum (probably the most dominant one which we will cover later), Kanban, Lean, XP, and Crystal. Before we dive into the history of agile and what it is lets first touch on its predecessor the Waterfall methodology so we can better understand certain problems agile seeks to address.

Before Agile: The Waterfall Methodology

A very popular software development methodology that is still in use today is the Waterfall Methodology. In this methodology the development process happens sequentially in that each phase completely wraps up before the next one starts. Due to this most people call the Waterfall methodology an incubation model because development grows from start to finish resulting in working code. The phases of the Waterfall methodology are as follows:

1. requirements gathering — project requirements are gathered and understood upfront, these detail each phase of the project
2. software design — software developers design data models, layouts, integration points etc into a written document.
3. implementation — once design is complete the code is written to implement it
4. verification — once the code is written but before it is released, testing is done to insure it meets requirements
5. maintenance — once the software is deployed a team is assigned to fix bugs that arise and take care of updates/new versions.

The perceived (and most times realized) downside to this is that due to an app being made of multiple segments (front-end, back-end, something that handles email, something that handles payments etc) having to complete all of these steps in something of a bubble before interacting with the rest of the app can cause things to break. The reason being is that other parts of this app are changing as well and not really communicating with each other until all of these processes are completed. Thus multiple points of failure are now open, and whose really to say who should role what change back where? This brings us to one of the many things the creators of agile sought to answer.

What is Agile Development?

The history of agile development is very thoroughly documented and always goes something like a Tolkien book: In 2001 at a ski resort in Utah…a group of 17 merry programmers met to discuss the state of software development. What they managed to conceive is actually quite brilliant. They compared common features in existing software development frameworks (such as SCRUM and a few of the others mentioned) that they liked and worked to create the agile manifesto. This manifesto initially laid out the 4 Step Practices of Agile:

1. Individuals and interactions over processes and tools — By placing value in people over the tools used to create a product you are allowing for continuous communication that might address needs as they arise. You are allowing for a more fluid or ‘agile’ response to needs. This is in contrast to valuing process or tools over people which restricts communication to rigid structured formats and times.
2. Working software over comprehensive documentation — the development is given more importance over documentation. This is not to say that documentation does not exist and isn’t important in Agile development. It means that documentation is succinct and to the point in that it won’t bog down development. If pertaining specifically to Users Stories the documentation should be relatively clean and exact.
3. Customer collaboration over rigid contracts — agile is very feedback dependent. A contract usually involves the customer negotiating a plan with the product owner in which the details of delivery are defined and are thus rigid. By only allowing the customer access to what is happening with the product at the start or at scheduled intervals you are distancing them from the process in which it is developed and this does not allow for fluid changing requirements.
4. Responding to change rather than following a plan — agile reacts to feedback over contracts. With the shortness of each iteration agile allows for change more easily.

This was followed by the 12 Principles Of Agile:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software — The ability to constantly ship code allows for customers to continuously receive working software at regular intervals rather than waiting between releases to give feedback.
2. Welcome changing requirements, even late in
   development. Agile processes harness change for
   the customer’s competitive advantage — The short iterative cycle avoids delays when a requirement changes
3. Deliver working software frequently, from a
   couple of weeks to a couple of months, with a
   preference to the shorter timescale — by executing User Stories frequently (in SCRUM a Sprint).
4. Business people and developers must work
   together daily throughout the project — By keeping an open line of communication with business leaders and the technical team, better decisions will be reached.
5. Build projects around motivated individuals.
   Give them the environment and support they need,
   and trust them to get the job done — motivated teams produce better/more work.
6. The most efficient and effective method of
   conveying information to and within a development
   team is face-to-face conversation — communication is more efficient when development teams are together and have a higher communication rate.
7. Working software is the primary measure of progress — Progress can be measured by working software.
8. Agile processes promote sustainable development.
   The sponsors, developers, and users should be able
   to maintain a constant pace indefinitely — by keeping User Stories simple they can be executed quickly and often.
9. Continuous attention to technical excellence
   and good design enhances agility — By scheduling features in the correct order and using simple definitions for each of them you ensure that a team can maintain a pace and sustain change.
10. Simplicity — the art of maximizing the amount
    of work not done — is essential — develop just enough to complete the current objective.
11. The best architectures, requirements, and designs
    emerge from self-organizing teams — encourage motivated team members to take ownership of what they make and communicate regularly with other team members. This includes sharing ideas and road blocks.
12. At regular intervals, the team reflects on how
    to become more effective, then tunes and adjusts
    its behavior accordingly — This can pertain to encouraging self improvement, advancing skills, and reviewing processes.

These all seem like noble goals to have and provide some rough guidelines but how does agile look in practice? Lets go over that in the next section with a software development framework that is very popular SCRUM.

The Scrum Framework

The acronym SCRUM stands for Systematic Customer Resolution Unraveling Meeting. It has been around since the mid 80s and two of its proponents who applied its framework to software development Jeff Sutherland and Ken Schwaber were among the original signatures of the agile manifesto. SCRUM seeks to break down large projects into smaller ones called Product Backlog Items (which are generally referred to as User Stories because of Agile) that can be executed through a quick process involving planning, building, testing, and reviewing phases called a sprint. Most sprints are designed with a time frame of 2 weeks but can be longer depending on the organization. Before we go into the moving pieces of SCRUM lets define a few key roles within it:

• Product Owner — is what would traditionally be called a ‘manager’. They are the person with the ideas and do not necessarily have to be a technical person. All accountability lies on them
• Scrum Master — is what could be called the ‘team leader’ and in a hierarchical sense sits right below the Product Owner. They run the meetings and are in charge of the day to day tasks the team faces.
• Team — the group of people composed of software developers, testers, etc that are assigned to a sprint.

Now that we have some of the roles down lets get into the moving parts! SCRUM is composed of the following:

• Product Backlog — The product owner and the scrum master will define the product backlog items to be iterated over (plan build test review) by breaking down goals into individual product backlog items. The scrum master will prioritize the order in which these product backlog items will be executed
• Sprint Planning — During the sprint planning the product owner will describe how they would like the application to look like. This is usually done in a 15 minute daily planning session called a daily scrum. During the daily scrum the team also discusses where they are and if any roadblocks are impeding their progress.
• Sprint Backlog — This is the result of the prioritized and organized product backlog items that the scrum master has built using the product backlog. These are executed one at a time by teams.
• Scrum Team — consists of the product owner, scrum master, and team.
• Sprint Review — A sprint review occurs at the end of a sprint and is where the team reviews/verifies the sum of all the increments.
• Increment — Is a concrete stepping stone towards the over all goal. Each increment is verified and is usable prior to releasing. It is important to note that an increment can be released to stakeholders prior to the end of a sprint.
• Sprint Retrospective — Is done after the sprint is completed in order to plan ways to increase quality and effectiveness. The scrum team inspects how the last sprint went in regards to people, communication, processes and tools.

Conclusion

Through the emphasis of consistent delivery, communication, and breaking things down into smaller projects, agile and scrum create an environment that can easily adapt to change. By allowing development cycles to happen in short bursts that can respond to each other, this process can grow organically without rigid constraints. There is much that goes into the practice of both agile and scrum but hopefully this has provided a good ‘starting insight’ as to what these terms mean.