Agile is a software development philosophy that encourages the team to release the solution in increments throughout the project instead of delivering the solution all in one release at the end of the project.
Software projects are resource-intensive operations that can take a long time to execute from beginning to end. Traditional waterfall methodology requires the customer to wait until the project fully executes before they can see any results from the project they are funding.
This long wait introduces a number of challenges that agile is meant to help overcome.
The Benefits Of Agile
BENEFIT 1: Reduce Unnecessary Delays
Oftentimes, the customer would like to begin using the portions of the product that have been built, but cannot do so because the waterfall methodology requires them to wait until the end to receive the product.
Agile attempts to alleviate this problem by making releases to the customer at regular intervals throughout the project. On agile projects, the project will schedule releases at regular intervals, and work to deliver a certain portion of the overall product at each of the scheduled releases.
BENEFIT 2: Reduce the Risk Of Building The Wrong Product
The customer cannot provide early feedback on the product when they’re forced to wait until the end of the project to get access to the product. This lack of early input introduces the risk that the customer will receive a product that does not fully meet their business needs.
Most agile projects make heavy use of prototyping to get the product in front of the customer as early as possible. This alleviates the risk of going “off-tangent” in the middle of the requirements and development stages of the project and keeps the solution grounded in real customer feedback.
BENEFIT 3: Avoid Bad Requirements
The customer does not always fully understand their own business needs well enough at the start of a project. The waterfall methodology requires the business analysts and customers to establish and commit to the requirements before the project can take on any significant development activities. This pressure to produce requirements can force the customer to commit to requirements that do not truly meet their business needs.
Agile attempts to alleviate this problem by allowing some flexibility in how the requirements are established and absorbed into the project. On most agile projects, it is not necessary to understand the full picture of the end state before starting the build on a significant portion of the product.
The Confusion Around Agile
There are many philosophical debates about the definition of agile and its relation to other popular terms such as Scrum and Kanban. It’s important for us to disambiguate between these terms to get a crystal clear understanding of the subject matter.
Agile vs. Scrum
Agile is a philosophy while Scrum is more of a methodology. The agile philosophy encourages organizations to follow a few very important principles but does not dictate how the organization is to achieve these goals.
The agile philosophy promotes the following principles.
- Strive to release as much of the product as possible to the customer as early as possible.
- Ensure that the first release of the product has the bare minimum that the customer needs to operate a self-contained area of their business.
- Structure project activities in a way to allow the team to build momentum over time. The team should become more efficient as their experience of working with one another builds, and they should strive to progressively increase their output as the project moves forward.
Agile methodology dictates the specific way in which organizations can achieve the goals of agile philosophy. Scrum is one such methodology. Kanban is another.
Scrum vs. Kanban
Agile methodologies, scrum, and kanban have a lot more in common with one another than they do differences.
The major difference between Scrum and Kanban is in the way that features get from the product backlog into the work in progress (WIP) status.
Here is a point-by-point breakdown of each agile methodology.
| Scrum | Kanban | |
|---|---|---|
| Product Owner | The person in charge of interfacing with the stakeholders to determine the product roadmap, and populate the product backlog. | Same as Scrum. |
| Product Backlog | A prioritized list of product features that the product owner and stakeholders have deemed to be the most critical. | Same as Scrum. |
| Sprint | A block of time that the development team spends on developing a fixed set of features. Usually 2 weeks in length. | The concept does not exist in Kanban. There are no sprints in Kanban. The development team pulls items directly from the product backlog as their development capacity allows. |
| Sprint Backlog | The fixed set of features that the development team has in scope for any given sprint. | The concept does not exist in Kanban. |
| Sprint Planning | The process of allocating features from the product backlog into the sprint backlog. This is usually negotiated between the product owner and the development team. | The concept does not exist in Kanban. The product owner ensures that the product backlog is always prioritized and the development team pulls the highest priority item from the list when ready. |
| Status Board | Called a “Scrum Board” – a canvas that shows the current development status of the features that are in the current sprint. Statuses are typically (1) Sprint Backlog, (2) Building, (3) Testing, (4) Done. | Called a “Kanban Board” – a canvas that shows the current development status of the features that are currently in progress. Statuses are typically (1) WIP, (2) Testing, (3) Done. |
| Daily Meetings | Called a “Daily Scrum”, is a daily meeting where the team meets for a maximum of 15 minutes where each team member discusses three things: (1) What they completed yesterday, (2) What they are doing today, (3) Any blockers that may prevent their progress. | Called a “Daily Standup”, is the same as the daily scrum. |
| Product Review | Called a “Sprint Review”, is a review of the product with the customer at the end of each sprint. | Called a “Stakeholder Demo”, is a review of the product with the customer at scheduled intervals or on an as-needed basis. |
| Retrospective | A meeting between the team members at the end of each sprint to discuss how they can improve the way they perform their development work in future sprints. | A meeting between the team members to discuss how they can improve the way they work in the future. Because there are no sprints, these meetings can happen at regularly scheduled intervals or on an “as-needed” basis. |
| WIP Limit | The concept does not exist in Scrum. | This is a hard limit on the number of items the development team can pull into WIP at any given time. Because there is no sprint backlog, the WIP limit is what determines the volume of work the team can take on at any given time. |
Agile Is Widely Misunderstood
Many inexperienced managers and project managers expect far more out of Agile than Agile can do for their organizations.
Inexperienced managers often do not understand the full scope of the architecture and planning work needed to properly deliver holistic solutions. This, combined with heavy marketing hype from the agile industry creates a significant disconnect between what agile was originally designed for and what managers and project managers expect from their agile teams.
This misunderstanding often creates an over-reliance on agile which in turn introduces a few major drawbacks to using agile to run projects.
The Drawbacks Of Agile
DRAWBACK 1: Not Enough Architecture
The single biggest challenge that agile creates for both business analysts and software architects is the lack of time set aside to properly architect the business and the solution.
The reality of agile is that it only covers the software construction part of the project, and does not take into account the activities that precede development. This often sets very unrealistic expectations with management.
Once a project is funded by the organization, there is often pressure to kick off directly into the development of the product using agile. This leaves the much-needed architecture activities neglected, seeding many downstream challenges for the project team.
Business analysts and software architects experience this situation often on their projects. This is why the more experienced analysts and architects will negotiate additional slack into their deliverable estimates to make up for the time needed to perform the design and architecture work needed to deliver solid solutions.
DRAWBACK 2: Not Suitable For All Organizations Or Projects
Adopting agile practices can yield great results for organizations that are well suited to make the change, but attempting to adopt agile can create havoc in organizations ill-equipped to incorporate the philosophy into their project execution framework.
The Role Of Culture
If the organization’s development team isn’t prepared to put in the effort to significantly change the way they perform their work, then attempting to go agile only disrupts their current work patterns and does not replace it with a more efficient way of developing. Many developers are “set in their ways” and simply will not be able to make the shift from their current ingrained work patterns into agile.
Going Agile Requires a Significant Investment
Any organization that wants to make the shift from a pure waterfall to a pure agile way of operating must make a very significant financial investment to have any chance of success. A great deal of re-training is needed along with a significant re-tooling of the team with agile-specific project execution tools. In many instances, the cost of going agile can exceed the financial benefits that the organization would yield from it.
Some Projects Are Better Suited For Waterfall
Agile projects are aimed at getting a product to the customer quickly by delivering the MVP (minimum viable product) and then working to deliver the rest of the solution over time. There are many instances where an MVP cannot be established because the customer would require the entire solution for it to be useful to them. Some solutions cannot be broken down into smaller pieces to be delivered in an agile fashion.
Most Organizations Adopt A “Hybrid Agile” Approach
Attempting to go agile in these cases simply does not make sense. This is the reason that most organizations elect to pick and choose the beneficial aspects of agile and try to incorporate them into the way they currently operate, creating a hybrid-agile approach.
It is very rare to see a traditional organization that has fully adopted agile with success.
The Bottom Line For Business Analysts
Business analysts should prepare themselves for the environment that they are actually going to face in the real world.
If the BA role you’re aiming for requires you to do heavy project execution work, then you’re most likely to be in a full waterfall or a hybrid agile environment.
If the BA role you’re aiming for is more of an “application support” or “solution support” type of role, then you may be more likely in more of an agile environment.
If you’re trying to decide where to spend your time and effort to learn, you should be spending it learning the basics of the agile world, but learning how to execute projects in more of a hybrid-agile world.
So insightful, I appreciate every line that I read and it is going to aid my performance at work
I’m happy to hear that. Thanks Frank.
Difference between Agile and Scrum is clear now. Also, thanks for explaining the concepts in Scrum and Kanban! I find this article very insightful. Thank you!
You’re welcome Preetha.
So in the hybrid agile environment, you recommend that the Requirement and Design phases are executed the way they do in waterfall but the development of the solution should follow agile?
So BA will complete the requirements which once signed-off on, will move into Design phase. So how long should these phases be? Does the business analyst need to be involved in the Design phase (specially when he/she has no deeper technical knowledge)?
Hi Asher,
Ideally, the BA should get the business to agree on the business requirements before kicking into agile to produce the detailed functional specifications.
There is no standard size for the length of the phases. Each project must be estimated based on a number of factors.
The BA should be involved all throughout the project until the solution is delivered to the end customer. This may not be possible in all circumstances.
I hope that helps.