If you are into agile software development, chances are you might have heard some or all of the statements below.
But when I first started learning about Agile, I could not understand it easily. If you are someone like me, I want to highlight what I learned in the last couple of years on agile.
What is Agile?
Agile manifesto explains the following value of Agile.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
However, despite this definition, one of the most discussed topics is Agile a methodology. Understanding this concept of "Agile Midset" might be a little difficult for us practitioners since we are more comfortable with the methodologies which say what to do next.
To understand the "Agile mindset", let's briefly discuss why Agile came to existence in the first place. Since the 1990's people have understood that software should respond to changes more frequently. At the end of the 1990s, software was in high demand; some analysts projected a 3-year lead time between requirements and delivery. During 3 years, a lot can happen. Requirements evolve, end users change their minds, opportunities become obsolete, and in some cases, complete companies or industries disappear in 3 years. However, most of the time, software teams don't want to work with uncertainty & they want the requirements to be precise. Sometimes management teams did not want to take too many risks with the projects. Responding to this popular demand, many organisations adopted different approaches to respond to changes.
In 2001 when the Agile manifesto was first signed by 17 pioneers in Snowbird, Utah, they understood these realities about the industry & they came from different practices which were popular at that time. They did not want to enforce any method on any organisation. Instead, they proposed a different way of thinking which would help the organisations to build their own way of responding to changes better using tools and techniques available in the market even during that time.
The main objective of Agile can be summarised in the below 3 points.
- Work with what we know while constantly refining what we know and what is required next.
- Obtaining feedback as frequently as possible from stakeholders.
- Work on the items which have higher business value & delivery value to stakeholders as early as possible.
When to use Agile?
Sometimes we believe Agile replaced waterfall. In most cases, where businesses require agility, this could be correct. But identifying when not to use Agile is also very important at times.
Stacey matrix (although it has its fair share of criticisms) help us to understand how and why Agile can help in projects. Stacey matrix is drawn between 2 axes, agreement & certainty. When a project has a certain scope and all parties agree, we can call projects "Simple". Simple is a very arguable statement, but in this context, we can identify this as simplicity of completion due to clarity of requirements and agreement between parties. Continuous feedback and iteration might become a nuisance to some participants in such cases. A good example I can think of is developing a telecom back-end service based on a 3GPP specification. Since service is clearly explained in the specification, continuous feedback sessions will not add much value to the process. There are not many changes the development team can make based on any feedback which is not already specified in the specification. In such cases, the traditional waterfall mechanism will work better.
If the project has no certainty and no agreement, it is classified as "Chaos." In the chaos, any form of planning is hard and sometimes impossible. One good industry example I have come across in a few places is a service outage of a large service. In such cases, we can look at mitigation mechanisms, such as fixing the most urgent issues and moving to the next problem. Although this looks iterative since we continue to solve issues, there is not much information we could learn from 1st issue to solve the next issue most of the time.
When you exclude these 2 extreme points, everything else can be categorised into 2 classes.
1. Complicated - Projects become complicated in 2 scenarios.
a. When what is required is certain, but how to deliver (agreement) is doubtful. For example, when you need to connect two modules or components, what to do is certain (connecting two modules), but how to implement it (mapping attributes, selecting APIs, authentication) needs to be agreed upon.
b. When how to deliver is clear, but what to deliver is doubtful. For example, when you need to design an e-commerce store for a new brand, how to deliver is clear as there are many proven platforms such as woo commerce, Shopify and many more. But what to deliver (content, channels, promotions) is not clear at the beginning of the project.
An iterative process can significantly help a complicated project achieve its goals. Agile encourages starting with what we know and working on unknowns iteratively. Rather than waiting for the whole scope to be clarified. However, other schools of thought suggest analysing, designing and executing (waterfall) approach works better in complicated domains.
2. Complex - Anything between Chaos and Complicated is categorized as complex. Complex domains have no agreement about what to deliver or certainty on how to deliver. This inherent "unknowingness" create a perfect background for the "Empirical process". When project teams work around the uncertainty, detailed planning is not possible & unresultful. Working on what is evident at the moment and working in small increments makes adopting the changes readily in the long run. Since work is carried out with some doubt, frequent feedback is essential to identify the readiness of deliverables and new scope.
Is Agile = Scrum ?
Due to the widespread popularity of scrum, some beginners may assume scrum and agile are the same. However, Agile is an umbrella term used to identify a family of methods to deliver projects iteratively. A quick search on Wikipedia will give you the following list of different agile methodologies.
| Framework | Main contributor(s) |
|---|---|
| Adaptive software development (ASD) | Jim Highsmith, Sam Bayer |
| Agile modeling | Scott Ambler, Robert Cecil Martin |
| Agile unified process (AUP) | Scott Ambler |
| Disciplined agile delivery | Scott Ambler |
| Dynamic systems development method (DSDM) | Jennifer Stapleton |
| Extreme programming (XP) | Kent Beck, Robert Cecil Martin |
| Feature-driven development (FDD) | Jeff De Luca |
| Lean software development | Mary Poppendieck, Tom Poppendieck |
| Lean startup | Eric Ries |
| Kanban | Taiichi Ohno |
| Rapid application development (RAD) | James Martin |
| Scrum | Ken Schwaber, Jeff Sutherland |
| Scrumban | |
| Scaled agile framework - SAFe | Scaled Agile, Inc. |
Comments
Post a Comment