In our previous blogs, we talked about taking on your strategic challenges with an Agile mindset, and the problems with using an unstructured approach for managing product requirements and design. Before adopting an Agile mindset, we thought it would be a helpful conversation to talk about the various types of Agile methodologies and which one might be the right fit for you. In this blog, we will unpack six different Agile methodologies and where they fit on the Agile continuum. We will uncover the advantages and disadvantages of each one, with a goal of helping you choose the one that is right for your organization, given where you are in your Agile transformation journey. As you might imagine, there isn’t a “one size fits all” strategy when it comes to selecting the right Agile methodology – it depends on a number of factors such as the growth stage of your company, the product development stage and your core competency.
The Agile Continuum
The six Agile methodologies are depicted on the Agile continuum below. Starting from the Waterfall model on the extreme right, as you go towards the left, each of these methodologies gets more Agile on the Agile continuum.
A quick definition of each of these methodologies will be a worthwhile exercise.
Waterfall: The traditional model that companies have followed, characterized by long release cycles (1-2 years or more) with well-defined and gated phases of activities. This is characterized by detailed planning, documentation, testing and coordination.
Hybrid: A combination of Waterfall and Scrum, where a particular phase (typically build phase) is done using Agile scrum (i.e. sprints), but the remaining phases follow the waterfall model.
Kanban: An Agile methodology using a visually managed process where team members pull work items from the backlog based on their available capacity. There are no time-boxed sprints in Kanban.
Scrum: An agile methodology with time-boxed iterations for development known as sprints. The duration of the sprints can vary from 2-6 weeks. The shorter duration is used in teams that are more Agile.
Hyper Agile: Faster than Agile Scrum – there are no well-defined or time boxed sprints. Instead, features are conceptualized, developed and deployed on an ad-hoc basis, typically in 1-5 days. Features may be received from the customer or prospects. As an extreme example, the team may get a feature request in the morning, code it in the afternoon, test it in the evening and deploy at night.
Now that we have defined the various Agile methodologies on the Agile Continuum, we can unpack which one of these may be a good fit for you.
Company Size and Growth Phase
The growth phase and company size are a key variable in this exercise. As you can see below, it matters whether you are an early stage startup, a mid-size corporation or a large enterprise.
The company size matters because developing and releasing a product needs coordination between a number of related support activities such as:
- Product Documentation
- Legal (IP, Copyrights, License Agreements, Contracts)
- Marketing (Branding & Pricing)
- Sales (Training)
- Security
- Regulatory controls (depending on industry)
- Globalization support (for companies operating in a global setting)
An early-stage startup can minimize these coordination activities down to a bare minimum, but a large enterprise cannot avoid these activities.
Product Life Cycle Stage
Another key determinant is the Product Life Cycle Stage. For a product that is in ‘Sustain and Enhance’ mode compared to in the ‘Concept’ stage, you need to think differently in terms of which Agile methodology works best. A key indicator of the product life cycle stage is how many customers are currently using the product. If you have a lot of existing customers for the product, your choice for the ideal Agile methodology will vary. It is almost impossible to follow a Hyper Agile approach in this case.
Your Core Competency
Another key determinant is your core competency – what is your organization really good at? Are you really good at developing software or related technical products? Or are you really good at selling insurance products?
Which Agile method is right for you?
The ideal Agile method for your team depends on a number of variables, such as:
Size and Growth Stage of your company: This dictates the level of coordination required with corporate support functions such as legal, security, regulatory etc. The larger the organization and the level of coordination required, the harder it is to move to the left on the Agile Continuum.
Product Life Cycle Stage: This a good proxy for the number of existing customers the product has. In the early stages of the development life cycle, the product doesn’t have many customers therefore customer disruption is less of a concern which allows more frequent product releases. As an extreme example, an early stage startup company with no customers can define, develop and deploy product features on a daily basis.
Core Competency: If your core competency is writing software (e.g. you are a software focused product or services company), you will be a better fit for one of the Agile methods. If your core competency is not writing software (e.g. you are a retailer or an insurance company), you may or may not be a good fit for an Agile method depending on the individual capability of your team. An Agile method might still work with the right team mindset.
We can now outline some general guidelines for selecting the right Agile method for your team.
Hyper Agile: With a fast release cycle (typically 1-5 days) for new features, this is a great approach for early stage startups. This may also be suitable for small, autonomous teams within larger companies building a new product concept, essentially working in a startup mode.
Agile Scrum – Short Cycle: If you are following the Scrum model for Agile, your Sprint duration is a major variable in how Agile you are. The Sprint duration can range from 2-6 weeks, with less than 2 weeks simply not being a practical option. The shorter cycle of 2 weeks allows you to deploy product releases at a quick pace, although not as fast as Hyper Agile. A 2 week release cycle may suffice for most organizations (except for early stage startups) but it also introduces major sprint planning overhead. This Agile model represents the most Agile of all the available options, which is also practically achievable for most organizations (any more Agile than this will not be practical). Because Sprints are time-boxed, teams usually do their best to deliver what they committed to – resulting in a higher throughput.
Agile Scrum – Long Cycle: The longer cycle of 6 weeks allows you to deploy product releases at a more reasonable pace, although not as fast as the Short Cycle. A 6 week release cycle may suffice for mid-large organizations. A 6 week release cycle also helps lower the sprint planning overhead. The longer cycle means you have less ability to respond to change quickly.
Agile – Kanban: The Kanban method works really well when the team is dedicated to a product and well organized. It is ideal for products in the ‘Sustain and Enhance’ mode. For example – it is a great approach for supporting Production Support issues, where you have a dedicated support team and the issues arriving don’t necessarily follow a predictable pattern. It is also being used more frequently by Agile teams for the core development process as well. It is visual and easy to understand, plan and execute with minimal planning overhead. But because work effort isn’t time-boxed, there is potential for smaller throughput compared to Scrum, as team members are under no time pressure to deliver.
Hybrid: The hybrid approach works well for larger organizations taking on the Agile transformation journey, as an intermediate step in their journey towards a pure Agile method. It’s a good way to introduce the Agile scrum method to a team that is accustomed to the traditional Waterfall approach. This is also a great approach for large, complex, multi-year projects such as Packaged Software Implementations in the Enterprise IT context. This approach also works well for highly regulated and audited industries where detailed tracking and documentation are essential.
Waterfall: This is the not-Agile approach, or the traditional model that companies followed before the advent of Agile. There are some exceptional scenarios where waterfall may be the right approach – large, complex projects that are mission-critical or life-critical where every small detail matters (such as launching a rocket ship). But by and large, waterfall model is losing ground to the Agile approaches.
Selection Matrix
To help evaluate the pros and cons of each of the Agile methodologies and figure out which one is right for you, we have put together a selection matrix. You need to consider your company size, the product life cycle stage as two of the key determinants of evaluation. There are certainly more determinants such as the type of product you are building, type of industry in which you operate to name a few. But to keep things simple, we have focused on the three most important determinants.
The Agile Transformation Journey
When you embark on your Agile transformation journey, the starting and end point will vary considerably for each company. For larger enterprises and mid-size corporations, the transformation journey will traverse towards the left (of the Agile Continuum), eventually landing in a spot that is different for each company. Also, within a given large enterprise, the starting and end points may vary depending on the business unit and the degree of autonomy it has in running its business. For startup companies, their journeys will likely move in the opposite direction, starting from a Hyper Agile approach and settling in on one of the Agile Scrum or Kanban methods.
Think of your Agile transformation as an ongoing journey where you need to constantly optimize your destination based on how your company grows and evolves over time. The steps that you need to take to reach your desired destination need to be thoughtfully mapped out – resulting in a gradual adoption of the Agile mindset that will improve the market performance of your company over time.
Where does your team fit on the Agile continuum? Share with us your ideas and experiences from your own Agile transformation journeys. We welcome your comments in the section below.