It all started in 2001; an Agile Manifesto that would lay down the principles and core practices upon which agile software development methodologies are based. But before we get into the many agile methodologies organizations use today, make sure to check out our quick guide for everything you need to know about agile.
What is an Agile methodology?
The Agile methodology is a simple, iterative way to turn an idea with a bunch of requirements into a software solution. It uses constant planning, understanding, updating, communication, development and delivery as part of an agile process that gets fragmented into separate models.
Teams use Agile methods to implement a project or a plan, by dividing it into many stages that interact with customer feedback. Development and testing are synchronized, and every phase of the project or software development gets monitored.
Also, due to the fact that the development process is iterative, errors get resolved along the way, which means you end up with a final deliverable product that is closest to what your customer actually wants.
How many Agile methods are there?
There are many ways for project managers to improve structure in their project delivery; every model applies different principles, themes, frameworks, processes and so on.
At the moment, there are over fifty available agile frameworks or methods, some of which are well known, others maybe not so much.
Scrum, Kanban, DevOps, Scrumban, Design Thinking, AgilePM, SAFe, Scrum at Scale, Open Space Agility, Disciplined Agile, Scaled Agile Lean Development (ScALeD), eXtreme Programming (XP); too many to discuss here, or even list, so we'll settle for a few to get the gist.
Scrum is what a lot of teams choose when they start working with Agile; it's also the most popular Agile method. Described by Ken Schwaber and Jeff Sutherland in their Scrum Guide as a “lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems”, Scrum is concerned with getting more work done faster and changing client requirements.
The Scrum framework for project management is simple, and incomplete in the sense that it’s more about guiding the relationships and interactions between people, than it is about providing detailed instructions.
Scrum emphasises accountability, teamwork and iterative progress towards a well-defined goal, with transparency and adaptation at the base. It starts with what can be known at the moment, then allows for tracking progress and tweaking when needed.
Everyone plays a role in Scrum; and in product development, Scrum roles include product owner, who manages the product backlog, Scrum master who helps maintain the agile environment and the Scrum development team. Communication happens via daily scrum meetings to align everyone, and see how best to implement the sprint.
Scrum is good for the first phase of a commercial product life cycle, in which the product is put on the market for the first time; uncertainty is high, while focus is on on-time delivery of the first market-ready product.
Kanban is primarily concerned with process improvements. It was developed back in the 1960s by industrial engineer Taiichi Ohno, to improve manufacturing efficiency within the Toyota Production System; this would later inspire Lean Manufacturing in the U.S..
The Japanese word “kanban” means “visual board” or “sign”, and was only claimed by Agile software development teams (K becoming a capital “K”) in 2007, with the emergence of the Kanban Method.
Kanban is about helping you visualize your workflow and tasks on a Kanban board so you can better understand your processes and get an idea of your workload. It helps you quickly identify problems in work stages so your team can maximize efficiency and constantly improve.
You can start building your Kanban system by setting up the most straightforward Kanban board with three basic columns – “To Do”, “In Progress” and “Done”. It will serve as a real-time information repository that highlights bottlenecks and all other interrupters.
Uncertainty and requested changes will go down as your product life cycle unfolds, and so, in a continuous flow, user stories can be picked up, developed and deployed one by one, by individual team members.
Scrumban is created by combining Scrum and Kanban.
When it first started, it was meant as a transitional model for when you switch from Scrum to Kanban, so that teams would get to experience Lean and Kanban concepts. Today however, it’s a different approach; the team has already chosen to work according to Scrum, with sprints, but while using the Kanban system to continually view, improve and optimize work.
DevOps, (Bus)DevOps, and CI/CD
Transferring to production environments is no piece of cake, but your time-to-market can be made shorter with error reduction and proper transfer. By merging development and operation or IT teams, and automating integration testing and deployment (Continuous Integration and Continuous Deployment CI/CD), a DevOps team gets created.
DevOps as a term came about from the collision of two major related trends:
- “agile infrastructure” / “agile operations” which came about by putting together Agile and Lean approaches to operations work
- a good understanding of the value of collaboration between development and operations staff throughout all stages of the development lifecycle.
DevOps is basically the practice of operations and development engineers working together in the entire service lifecycle, from design, to development and production support. Here, operations staff tend to make use of many of the same techniques as developers, for their systems work.
Extreme Programming - XP
Extreme Programming (XP) is a methodology that emphasizes teamwork, communication, and feedback by focusing on constant development and happy customers. Just like Scrum, XP uses sprints (or short development cycles) and involves a lot of client interaction.
XP is developed by a team when they want to create a productive and very efficient environment. It's very supportive when facing constant demands that change with customers. Also, it helps developers better handle changes, even at later stages in the product development process.
In Extreme Programming, testing happens by collecting feedback. Codes are tested and reviewed on a regular basis throughout the project, which means bugs and issues are fixed on the spot; of course in the name of higher quality software.
The concept of Lean first came up in the 1950s in the manufacturing sector of Japan, where they would strategize their production activities to reduce waste and costs. Of course, later on, the concept of "Lean" was introduced as a major Agile methodology for software development.
Lean is all about achieving perfection by reducing redundant tasks and wastage in software development, including writing wrong code, reworking, or using one's time and resources inefficiently. It helps identify the business value of a project, and create a planned workflow that keeps getting better as time goes by.
What are the seven principles of Lean Software Development?
- Eliminate waste, which could be time spent building, analyzing or designing features you won't use, or fixing bugs.
- Build quality in, to avoid having to rework or put out fires later on, while busy with other tasks.
- Create knowledge, by retaining staff and keeping their accumulated knowledge within the company.
- Defer commitment, make a step, then reflect on what was learnt instead of trying to predict work years ahead.
- Deliver quickly, so you don't pile up work, and so you can measure the impact and adapt based on your findings.
- Respect people, and give them power, because those doing the work have the best view on how to improve it
- Optimize the whole, to achieve true effectiveness across all the work; software is made of individuals who do their part.
Crystal is a group of smaller agile development methodologies introduced by Dr. Alistair Cockburn, co-author of the Agile Manifesto, and that focus primarily on people and the interaction among them as they work together.
Note that Crystal is not a set of prescribed tools and techniques, but rather an approach. Nothing is fixed when it comes to processes and tools; they can be adjusted to the requirements and characteristics of any project; they call this a stretch-to-fit methodology.
Crystal is also known as a “lightweight methodology” which means there isn't much documentation, overhead management or reporting involved. It's all about keeping things light as you focus on developing business value and good software, alongside a good communication among team members and between developers and stakeholders.
The Crystal family of methodologies includes Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond and Crystal Sapphire. Crystal Clear for example is better for short-term projects with a few developers working from a single workspace. Crystal Orange, on the other hand, works well for projects with 10 to 40-member teams and a lifespan of 1-2 years. Crystal Sapphire or Crystal Diamond methods are used in large projects where there's potential risk to human life.
Basically, the weight of your Crystal methodology is determined by project environment and team size.
What are hybrid project management methodologies?
Interestingly enough, the majority of project people say that their organizations have implemented hybrid project management methodologies which combine agile principles with other methods.
Daivat Dholakia, director of operations at Force by Mojio, uses agile processes to direct product development at the company. His team uses a simplified version of agile that incorporates scrums and sprints to move efficiently through projects.
Daivat modified the traditional agile model to suit the status and needs of his team. For example, instead of a daily scrum, they hold short biweekly meetings during sprints: one on Monday to establish goals, and one on Friday to report on progress. Since working remotely and with varying schedules this past year, they’ve reduced their number of meetings.
Just be careful not to lose out on the benefits that made a methodology popular in the first place when using bits and pieces of a methodology; because while you certainly can adapt methodologies for your team’s use, it’s best to use them as intended, adjusting only when necessary.