There are numerous philosophies that guide how businesses approach big projects or ongoing improvements. Agile Methodology is one of many.
The way they were doing things wasn’t working, so they implemented a process improvement methodology and it stuck. One big example you hear a lot is Toyota’s use of Lean Manufacturing to maintain efficiency while reducing waste.
But, more and more, companies (especially in tech) are going to Agile to improve how they manage projects and deliver product. So, what exactly is Agile?
What is the Agile Methodology?
Agile Methodology is an incremental iterative approach to managing projects and developing products (like websites and software). It is a non-linear and flexible approach allowing for changes in the scope mid-project with the goal of continuous improvement during those changes.
The History of Agile Development
This style of software development and project management informally started in the mid-nineties as organizations tired of traditional methodologies started building their own systems. Using the best of the old systems and with new ideas built around collaboration and transparency, early forms of Agile were developed independently.
With all these variants of this yet unnamed methodology floating around, a group of 17 people came together at a ski resort in Utah to nail down the most basic values of this new development methodology. As with all the developers of Agile-like systems before this ski trip, these 17 people all had slightly different ideas of what Agile should be.
In the end, they came up with the name Agile as well as the 12 principles that make up its foundation to this day. The principles focus on how to best support and involve the customer, how to consistently develop evolving products, and how to maintain strong collaboration between team members and with customers.
Following their trip, they posted the manifesto online and let people start to sign it to show support for the idea. Since then, organizations have been integrating Agile into their processes or consulting those that want to.
The Agile Manifesto
Authored in 2001, the Agile Manifesto was created in order to create a standard foundation of values for Agile. Previously, the ideas that led to what we now call Agile were disparate incarnations of various groups that were trying to improve on older methodologies.
With this manifesto, those wanting a change had a basic framework for a new system. While there are different applications of agile, the origins come this Agile Manifesto.
The 12 core principles of the Agile process are:
- Our highest priority is to satisfy the customer through the 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 a preference to the shorter timescale.
- Product Owners, Developers, and Project Managers 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 a 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.
Waterfall vs Agile
There are a number of methodologies used for the development of software. Each has its own diehard fans. Two of the most popular methodologies are Waterfall and Agile. Simply, the difference comes down to doing a project all at once or incrementally.
Waterfall is the original software development methodology relying on a linear project approach with distinct development stages. Each stage of the process must be completed to move on to the next. This makes for a clear timeline of events with easily measurable deliverables along the way.
The end result is exactly what was defined by the client at the beginning of the process. Having a clearly defined scope allows the client to know precisely what they will be getting by the end of the project. This all at once approach appeals to clients that know exactly what they want.
But, it does not allow for any changes throughout the process if the client changes their mind about specific features. The project is defined, works its way through a black box, and comes out the other side without a care for any changing needs that crop up along the way.
With Waterfall, there is such distance between what clients imagine they want and define at the beginning and what they end up with. There is always the possibility that they will be dissatisfied with the final work product. At this stage, changes to the product will be more difficult to implement and come with more expense.
Agile is a response to the Waterfall methodology and, in many ways, its opposite. Created based on satisfying the customer and delivering products continuously, Agile’s main concern is adaptability to inevitable changes with high customer visibility throughout.
While Waterfall doesn’t rely heavily on interaction between team members and the client throughout development, Agile insists upon cross-functional teams working together throughout development with regular client meetings. This brings customers into the project as a part of the team, working to help create their ideal product.
Structured in regular sprints (twice monthly, for instance), Agile projects have consistent deliverables throughout their lifecycle, resulting in a final product that the customer is satisfied with.
This means that the end product will likely not look like what the customer initially planned, but will be what they decided they needed along the way. This incremental approach appeals to clients that have some idea what they want but are open to the evolution of that idea.
Advantages & Disadvantages of Agile
While we love Agile, it is important to recognize both its pros and its cons. For us, the advantages far outweigh the disadvantages. The best relationships we have with clients are those where all parties are aware of and excited for the Agile way we manage projects and build websites.
- Continuous improvement
- Change is welcome and expected
- Faster deliveries
- Increased team accountability
- High project visibility
- The team must be highly skilled in a variety of areas
- The end product can be very different from initial planning
- Documentation goes stale quickly due to rapid updates
Scrum vs Kanban
Within Agile, there are different ways to visualize and structure the workflow. Essentially, they are sub-methodologies of Agile. Two of the more popular sub-methodologies are Scrum and Kanban. We prefer to blend these methods together, using what we see is the best parts from each with the goal of sticking to the Agile Manifesto.
What do they bring to the table? Let’s break it down real quick.
Scrum is a sub-component of the Agile Development method that is used commonly for as a guide for approaching Agile Development. It is based around the idea of breaking work into Sprints so that the developers can deliver on a regular cadence. The Scrum process focuses not only on breaking work out into fixed length iterations but also on setting roles, responsibilities, and meetings that never change.
- Increased team accountability
- High project visibility
- Increased Quality
- The wrong PM or Scrum master can be a detriment to the success of a project
- Risk of scope creep
- Poorly defined tasks can lead to inaccuracies
Kanban is typically implemented into Agile projects but can also be a stand-alone system. Its main purpose is to visualize the state of items within a project onto boards split by columns. Each column contains cards to represent things such as Tasks, Components, User Stories, etc. It can also be used to quantify how much to develop, when to executed, and what is currently being developed.
- Easy to understand through visualization
- Increase delivery efficiencies
- Increased delivery flow
- Board can quickly get over complicated, defeating the purpose of Kanban
- Lack of date-driven work
- Once a board is outdated, it can throw off the course of the project
How coolblueweb Uses Agile
Now that we’ve covered Agile at its core, here’s how we at coolblueweb have implemented it.
An MVP (minimum viable product) focuses on the essentials for a site with the goal to launch to market as quickly as possible and then iterate post-launch while following the principles.
The faster a site can get to market with its products, the sooner businesses and customers are going to realize the benefits. It is important to be aggressive when evaluating priorities since there will be time to iterate, improve, and add more after launch.
Here is how Agile works within a client’s project workflow:
- When we begin work on a project or on a new feature, we will have a discovery period where we work with a client to establish business requirements.
- Coming out of discovery, we will have a component diagram that visually represents all of the technical components needed to complete the project or feature, and how they connect to each other. This document acts as a functional blueprint and will be used to create component-based tasks that make up a backlog list in Teamwork.
- The tasks in the backlog will be evaluated, including the hours estimated for completion, and will be prioritized based on importance for launching the MVP. Backlog tasks are moved into a sprint based on priority.
- Sprints run the 1st – 15th of the month and the 16th – end of the month. Each sprint kicks off with a Demo/Planning meeting. During this meeting, we demo the tasks completed during the last sprint and work together to make sure we have the right tasks planned for the upcoming sprint and review budget and timeline.
- Tasks can be completed at any time during a sprint once development is complete. Development is released to the demo site (or pushed to production) at the end of every sprint.
- Tasks that are incomplete at the end of each sprint will be taken into account in planning for the following sprint.
- Any feedback clients have on tasks (called User Acceptance Testing or UAT) completed in a sprint will become new tasks in the backlog and prioritized accordingly.
- When adding new ideas or enhancements to the project, there will be decisions to make as to whether these will be added to the budget and timeline of the project, or if they are to be evaluated post-launch. If needed to be done prior to launch, the budget and timeline can change. Clients can either add to these or move other features to be completed post-launch and stay close to the original timeline and budget.
- If we are working towards a delivery date or specific estimate, during each sprint demo/planning meeting we will compare the current scope, estimated budget and timeline to the original. This allows project owners to understand the impact of newly discovered tasks and change requests.
Who Uses The Agile Methodology?
Lots of companies use the Agile methodology, be it software/web development outfits or logistics companies. Like the Lean methodology, Agile is a philosophy of process improvement. It has moved from software development to a variety of industries.
Here are a handful of big companies using Agile: Apple, Philips, Microsoft, Spotify, Cerner, C.H. Robinson.
The Meaning of Some Agile Terms
Iteration: This is descriptive of sprints. Each sprint is an iteration toward the MVP.
Backlog: A list of tasks necessary to accomplish the MVP. The backlog tasks get slotted into sprints based on priority and necessity.
MVP: The Minimum Viable Product is a complete product with all the basic features for the first customers. This allows for quick launch while allowing further iterations to build further features onto the basic product.
UAT: User Acceptance Testing is testing done by the client at the end of a project to ensure that the product works as they expect. Based on their feedback, changes are made before launch.
This post will be updated regularly. Think of it as an MVP post.
If this sounds like how you want your project run, send us a message and we’ll follow up with you to see if we’re a good fit.