Skip to main content

Tag: Agile

Turn your specifications into living, digital documentation

Digital transformation requires the use of new tools and new ways of working – also for business analysts. We often facilitate this for other groups of people, and we should be ready to look at our own habits and preconceived notions as well and embrace new mindsets and tools. This article offers a take on what ways of working could look like for the digital business analyst.

Collaboration is becoming increasingly digital, and this also gives business analysts many opportunities to work smarter and better. That is, if you are ready to let go of documents and spreadsheet, and instead embrace digital tools for wikis, notes and backlog management. With a wiki tool, you can easily build your requirements documentation using webpages in a tree structure. Your first pages describe your scope. Each of those pages can then be broken into details on several pages that branch out. If you are familiar with mind maps, you will see that this is basically the same structure. In fact, a mind map can be a great first sketch of how to structure the content of the wiki.

Advertisement

The wiki structure allows your documentation to grow dynamically without you losing the overview. This structure is very well suited for agile development. If you focus on establishing the scope first, you will soon have some documentation that is accurate, though it is high level. You can describe the scope of your initiative first, and sign that off with your stakeholders. Based on that, you can discuss deliverables with your developers, and establish your backlog with features or epics. The features or epics can then be prioritized with your stakeholders. You can then detail out the requirements on your wiki, and the team can break down the user stories based on the wiki. This means, that while your scope is fixed and signed off, your detailed requirements get fixed and signed off incrementally in the same pace as the team is developing. I have experienced this to be a good way to be able to handle scope creep (because I have the scope to keep the requirements in check) and to avoid analysis paralysis and requirements rot. Because it is digital, I can create links from my backlog items to the relevant parts of the specification.

The basic concept can be illustrated like this:

Why not just add my requirements to the backlog items, and avoid all the linking? Well, because I want my documentation to describe my product holistically, including its context. And I want my backlog to describe the increments that the product is built in. So I need both.  I can then communicate, what my product is and does without also having to communicate the increments it was built in, which is completely irrelevant to most of my stakeholders. I can easily share a wikipage with a link or present it in a meeting. This means fewer powerpoints to produce.

Once the product is built, I no longer need the backlog – my documentation is what describes the product. And with that documentation established at the very early stages of the product development phase, I can communicate what the product looks like through its whole life cycle, from the birth of the idea to the decommissioning of the product. Each page is automatically version controlled, which makes the change control much more granular, and changes easy to manage without keeping extensive change logs. In some digital tools, you can even set up approval workflows to make sure that the right people sign off on changes. I like to think of it as the DevOps mindset implemented in requirements analysis.

You can add any kind of content. A webpage has no limits when it comes to content – pictures, text, tables, links, and attachments. Your documentation can contain much more than a traditional requirements specification, such as personas, test data, samples of production data and other types of examples. Because of the tree structure, I always know which objective or process a detailed requirement supports. Obviously, various kinds of diagrams play an important role. Traditionally, you would argue that you must do your modelling using a modelling or BPMN tool. The reason for this is that your models can then be reused by others. In theory, this is true. However, I have never experienced this reuse in my 15 years as a business analyst.

Over the past couple of years, I have practiced using pen and paper for visualizations, and I have integrated this into my ways of working. It is a great way to work because it helps me focus and process information. It is also free of the constraints a computer program sets when you create digital visualizations. To my own surprise, this approach is very compatible with digital documentation. Simply take a photo or scan a drawing and add the image to the page. It can then be enriched with text for elaboration. This is particularly useful when describing scope, features or epics and application landscape. Digital and analogue are not contradictory, but complementary.

I have recently published two articles on BA Times related to using pen and paper, which provide some tips for getting started:

Start your visual facilitation journey with letters

The icon library: My favorite analogue tool

Top 10 Business Trends to Watch for in 2022

By Andrea Brockmeier, Jason Cassidy, Susan Heidorn, Jose Marcial Portilla, and Mike Stuedemann

While 2021 has been better in many ways than 2020, it doesn’t feel much more predictable. Yet, at Educate 360 we have identified some the biggest trends we are seeing and expect organizations to continue experiencing in Project Management, Business Analysis, Agile, Data Science, and Leadership in the year ahead.

Overall, the theme of working remotely comes through loud and clear and we expect it to impact almost every area that we covered.

Here are our Top 10 trends to watch for in 2022. We’d love to hear your thoughts about our observations and prognostications.


Advertisement

Project Management

Project Managers as Project Leaders

The recognition that project managers are both leaders and managers is not new, but the need for the leadership aspect of the role has intensified in the last couple of years and will continue to do so in 2022. In fact, we are hearing more organizations using the title project leader as opposed to project manager.

To be sure, the technical aspects of the job such as scheduling, budgeting, and tracking haven’t been eliminated, but the need for skills like influencing, facilitating, communicating and other “soft” skills associated with the PM as leader has become paramount. Project managers as leaders are going to continue to be challenged in 2022 with distributed teams and all the distractions of ever-changing global and work environments. Leading the team and engaging stakeholders to sustain buy-in is going to continue to be job one for effective PMs in 2022.

More Organizations Using Project Management Tools

In 2022, expect to see a continued increase in the use of project management tools beyond the standard Microsoft Office suite. We used to see only the occasional client using a PM application of any kind and it was almost always Microsoft Project. Whether because people are working remotely, tools have become more cost effective, or tools have become more accessible and easier to use, we see more organizations using PM-specific tools and we’re seeing a wider variety of tools, as well.

At first this may seem contradictory to the previous trend of project leadership getting emphasized over project management; tools are not generally used for the leadership aspects of the PM role. Perhaps these trends are mutually reinforcing in that tools like Asana, Wrike, Easy Project, Smartsheet and others help with project management which allows the PM to tend to the demands of project leadership. Whatever the reason, we look ahead to 2022 as a robust year for PM tool implementation.

Business Analysis

Strong Facilitation and Communication Skills for Remote Business Analysts

We have all have heard about the Great Resignation – employees leaving their jobs in record numbers in search of better pay and career opportunities, a healthier work-life balance, a less toxic working environment, and desire to continue to work remotely. As a result, many companies are reducing their carbon footprint as well as costs, so they either have smaller offices, holding a space for meetings or providing “hoteling” spaces when employees need or want to go into the office to work. Organizations are also realizing that they can hire talent around the globe.

So, what does this mean for business analysts? It means we must get better at communicating and facilitating in a virtual environment. We must learn how to build trust when we can’t directly “see” stakeholders daily. We must be able to facilitate virtually to ensure we elicit inclusive requirements and not just those from a few vocal stakeholders. We need to learn to creatively collaborate with our team members, colleagues, and key stakeholders to ensure we have their buy-in.

BAs need to think about communicating and facilitating with more intention. This calls for mindful facilitation as opposed to simply the ability to use Microsoft Teams, Slack, or other communication platforms. We are already starting to see – and we continue to see in 2022 – more BAs focus on learning how to create safe, trust-laden, and collaborative environments within which stakeholders readily share information in a world that has been changed forever.

Digital Transformation Strategy Supported by Business Analysis

Digital transformation has been a trend for some years, and it is still going full steam ahead. Yet, most of these efforts fail. There are many reasons cited for this failure; among the most common include:

  • NOT understanding the business problem, but instead just throwing solutions or technology at the wall to see what sticks.
  • NOT determining success criteria so organizations have no way of knowing if the initiative has been successful because there was not a shared understanding of what success looked like.
  • NOT realizing that digital transformation introduces cultural changes in the organization (which is also one of the reasons many organizations had difficulty adopting agile).

Because of these failures, organizations moving toward digital transformation will rely more on business analysis capabilities to effectively address root causes of the problems above. BAs will be used on digital transformation initiatives to ensure the business problem or opportunity has been fully analyzed and understood, to verify that the organization is ready to adopt the new culture, and to identify overall success measures as well as identifying smaller, incremental success measures that can be measured throughout the project.

These efforts will also require a business analyst’s in-depth knowledge of agile business analysis approaches, tools, and techniques that will be critical as organizations strive to become more agile in their ability to respond to customers and competitors. Look for lots of opportunities in 2022 for BAs to plug in as key strategic resources on digital transformations.

Agile

Teams Continue to be Distributed – By Choice, Not Necessity

It can be argued that the COVID 19 pandemic did more to transform the world of work than any document, framework, certification approach or technology. One of the lasting impacts of the pandemic is that distributed teams are here to stay. Product development team members and their leaders will need to permanently adjust to working in a distributed fashion.

While many still share the perception that all Agile frameworks require co-located teams (see principle 6 associated with the Agile Manifesto), technology has advanced to the point where a team adopting a framework doesn’t need to all be in the same location. Continued discipline, particularly in the area of communication and team working together agreements, will be required as teams shift from distributed work by necessity to distributed work by choice.

Scaling – Addition by Addition or Addition by Subtraction?

The marketplace continues to see the emergence and growth of a number of Agile scaling frameworks. The Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), Scrum at Scale (S@S) and Disciplined Agile Delivery (DAD) are just a few of the prominent entries in this space. Next year will see organizations continue to adopt these frameworks as they seek to realize the benefits of being more responsive to change at a global level.

Current thoughts are mixed regarding how to achieve this goal. While many of the current frameworks (e.g., SAFe) advocate adding structure and layers, some like LeSS believe that true organizational agility can only be achieved by removing items from the organization that don’t directly contribute to the delivery of customer value. This debate is even more nuanced when the idea that some additional structure might be necessary on a temporary basis while the organization is being transformed. In 2022, we expect to see continued debate as to what steps are actually necessary to achieve agility on a global scale.

Agile Outside of Software

The Agile movement was born in the software development space. After all, it is called the “Manifesto for Agile Software Development”. In recent years, other domains have adopted a number of the values and principles that define the Agile movement in attempt to accrue its benefits. For example, there is currently an Agile Marketing Manifesto as well as efforts to bring an Agile mindset and some of its practices into education.

This trend will accelerate in 2022 as events such as the pandemic, natural disaster, and political and economic shifts remind organizations that the only constant is change.

Data Science

Increasing Application of Artificial Intelligence and Reinforcement Learning

We often hear that Artificial Intelligence is one of the trends that will change the world. This past year certainly validates that sentiment, and 2022 will continue to see evidence of this powerful trend.

But what is actually meant by the term “Artificial Intelligence”? Technically speaking, AI systems typically incorporate a special type of machine learning known as “Reinforcement Learning.” These specialized programs allow a computer to learn the same way a human does, through experience with trial and error.

In 2016, DeepMind (an Alphabet company) made headlines when its computer program AlphaGo beat the world’s best Go player, a feat many previously thought was impossible. The AlphaGo program worked through Reinforcement Learning methods, where the computer played thousands of games against itself, learning the best tactics to win the game of Go.

Fortunately, Reinforcement Learning has applications beyond just board games. In 2021, DeepMind released AlphaFold 2, a computer AI program that can accurately predict protein folding structures, opening up new possibilities in drug discovery and medicine.

The application of AI and reinforcement learning will definitely be a trend to keep an eye on, as the progress has increased exponentially.

Huge Strides to Continue with Natural Language Processing

Natural Language Processing (NLP) is the use of machine learning models to interpret raw text data, such as Wikipedia articles or even code written by humans. Traditionally, NLP technology has been used for classifying text articles into categories or sentiment analysis of reviews. By simply training NLP models on existing text data sets, the models can learn the topic of a new article, or whether a movie review is positive or negative.

Huge strides have recently been made in the capabilities of upcoming NLP technology. In 2020, OpenAI released “Generative Pre-trained Transformed 3,” commonly known as GPT-3, which has the ability to generate text that is nearly indistinguishable from that written by a human. GPT-3 was trained on hundreds of billions of words that were scraped from the internet and is even capable of coding in CSS, JSX, Python, among others.

In 2021, OpenAI further expanded on the idea of an NLP model that can code, by releasing Codex and Github Copilot. These futuristic state-of-the-art models can not only automatically complete large portions of code, but they can also accept a description of what the code should do and produce the corresponding code. Check out this Codex demo launch video.

The future is already here! We are definitely looking for exciting new applications of NLP continue to make headlines in 2022.

Leadership

Attracting & Retaining Talent – But Different Than Before

Attracting and retaining talent is the most prominent topic of conversation we’ve observed in media related to leadership, specifically attracting and retaining talent in a COVID-changed environment. It’s not clear anyone has permanently figured out the solution as the situation is still in flux, so we have listed key points that we hear leaders weighing in with in their decisions related to remote work and its implications for finding quality team members.

Let’s start by making a broad assumption (that certainly can still be refuted) that some jobs cannot be done remotely (e.g., printing and shipping) and some jobs potentially can be done remotely. Below are the key topics of debate that will continue to shape this discussion in 2022:

  • Job Equity: Is it fair to the people whose roles cannot be done remotely and who have to come into the workplace that others can work at home? As this question is discussed topics related to safety, expenses, commute time, flexibility, teamwork, fairness all come into play.
  • Productivity: Even if jobs can be done remotely, what is the level of productivity of remote work versus work in the office? As this question is discussed one hears that people work longer hours at home because they are not commuting, that people are more productive at home because they can focus and not be disturbed. On the other hand, you hear others say that people are less productive at home because they are distracted by non-work items and that people are less productive at home because they are not being watched. You also hear discussion of managers’ ability to manage in-person versus remote team members.
  • Cultural Impact: Even if a job can be done at home, is it better for the organizational culture? As this question is discussed topics related to collaboration, mentoring, camaraderie, organic problem solving and innovation, and work-life balance come into play.

These debates and questions will dominate leadership conversations in the coming year as leaders continue the challenge of finding and hanging on to top talent.

Jason Cassidy, PMP, is CEO of Educate 360, the parent company of Project Management Academy, Watermark Learning, and Pierian Data. – training partners of choice helping organizations improve organizational efficiency and effectiveness, increase cross-functional alignment, and drive results to help meet and exceed business performance goals.

Andrea Brockmeier, PMP, is Director of Project Management at Watermark Learning, an Educate 360 partner company. Dr. Susan Heidorn, PMP, CBAP, BRMP is Director of Business Solutions at Watermark Learning. Jose Marcel Portilla is Head of Data Science at Pierian Data Inc., an Educate 360 partner. Mike Stuedemann, PMP, CST, is a Scrum-Focused, Agile Agnostic Coach and Trainer at AgilityIRL and partners with Watermark Learning for Scrum courses.

Join our webinar on December 10 to hear our contributors talk about these trends and answer questions.

How to Build a Story Map with Persona & User Stories

Organizations build various products to achieve certain outcomes. These can be to help support the growth of the organization, achieve its vision & mission, customer delight, regulatory obligations or to respond to new possibilities. The interesting point here is that customer or the different persons that can be derived may benefit from these outcomes or may get impacted as a result of action taken to achieve these outcomes. Thus, it is imperative to understand the value that is being delivered to the customer in the form of a product or service, benefits, or features when a product is designed.

What is a Persona?

A persona is profile of a user which represents needs of the customer, problems that they may face and their attributes like age, preferred social media channels etc. They help us understand the market segment and target market for a product or service that the organization is looking to improvise or launch.

The personas are usually based on findings from research on end-users of a system, potential customer research etc. It is essential to not create personas on poorly available data or unrealistic assumptions.

Why use Persona?

Personas are depicted as a form of a written document with attributes like age, profession, style of living, preferred social media channels, buying behavior, demographic etc. Personas can be end recipient of a product or could be negative user personas to understand who explicitly not to take into consideration when developing a product. Thus, they are the “characters” of user stories. This persona documentation helps to drive conversations around the product features, delivery, output, expectations and what not to address which in turn connects the customer profile with value proposition in a cohesive manner. This is the foundation for creating compelling products and services the customers would want to buy.

For example, an attribute on the persona could be that the customer wants to connect anytime anywhere with the website of your organization. A potential solution is to provide live chat functionality leveraging chat robots to handle common FAQs when the staff is not available to directly chat to the customer in off-line hours.

Another example could be the system solution of providing hints, tips and online step-by-step guides to assist a customer who wishes to perform steps required to say, set up an adverting campaign on the adverting platform website on his own without having to interact with customer service staff on chat or email.


Advertisement

How to translate Persons to User Stories?

Once the customer goals are defined, we can start planning out the product features that would be required to meet those objectives.

Each feature can then be broken down into epics, which leads to smaller user stories and ultimately tasks. A popular structure used to document user stories is “As a [Persona] I want to [action] so that [goal]”

What is a Story Map?

Story mapping is a visual exercise to capture the journey a customer takes with the product including activities and tasks they perform with the system to achieve certain goals or objectives. This helps teams to define work, identify holes and omissions, plan releases by assigning priority to stories/tasks in order to formulate plan of action.

There are a few models that can help the team in prioritizing namely,

  1. Stack Ranking
  2. Kano Model – Customer Dimensions of Satisfaction and Investment. Features in 4 categories: Performance, Must, Attractive, Indifferent
  3. MoSCoW Model – Must-have, Should-have, Could-have and Would-have features
  4. Cost of Delay – How time would impact outcomes

Conclusion

In order to maximize the value you deliver to customers, creating customer persona goes a long way. It is a critical step to put planning before product design which ultimately leads to a product which addresses the customer needs leading to greater uptake, loyalty and acceptance.

Mentoring and coaching newly hired BAs in an agile organization

As an experienced Business Analyst in a fast-moving company with an extremely complex technology stack, I am often faced with the challenge to transform a new hire into an effective analyst. She will initially find it very hard to successfully navigate and benefit the organization. That gets even more complicated because in modern organizations we rarely have the opportunity to consolidate and clearly document our processes, tools, and software applications.

I am going to share my experience in arranging a lean yet effective mentoring program.

Problem statement: what’s the best way to bring a newly hired Business Analyst up to speed in the most efficient way?

The answer I elaborated on overtime was through mentoring and coaching. I believe that you need guidance and feedback to be able to gain complex core and technical skills as those required of a Business Analyst.

Mentoring is aimed at improving someone else skill sets

My objective was to conceive a full-fledged mentoring plan. I wanted this process to be generic and reusable. At the same time, it would not have to interfere with my other work commitments. As a first step, I drew a list of projects that I was or had been working on recently as these would most likely make up the new hire’s work background for a while. For each of them, I noted down the main concepts she would have to retain, as a sort of Acceptance Criteria.

I did the same with tools and techniques, and these were especially focused on the Agile software development process.

Getting to know the main stakeholders, teams, and their responsibilities was to be also part of our mentoring activities. These would give the new hire a sort of system view of our company, especially of the technology platform.


Advertisement

I estimated the time needed to go through those and give her the basic information. Hence, I built a rough timeline of my mentoring sessions and tried to stick with it. Our sessions usually lasted one hour and were held early in the morning, so as to avoid being interrupted by other colleagues.

The result was a win-win situation: the new hire would feel more at ease with each class and soon started to contribute to her development team. I also improved my teaching and collaborative learning skills.

Coaching helps you achieve your goals

It is common knowledge that skills acquisition is only possible through practice and real learning does not occur unless you apply what you’ve studied to real-life problems.

Putting my early extreme programming skills at work, I introduced the concept of pair analysis in our mentoring program.

Whenever I had an analysis activity at hand (in fact, that was all days the entire day) we would sit together with the new hire and try to understand the requirements, share some assumptions, note the open points, contact the relevant stakeholders, take part in some meetings together, document and evaluate our solution options, etc.

A typical exercise was for her to write the User Stories for the requirements we had elicited together and then to explain them to the development team. Initially, she was charged with relatively simple problems, and as her skillset started to improve, I asked her to take on more challenging requests.

In terms of core competencies, I told her to prepare and facilitate lessons learned sessions with the development team. Every time she would have to change the format of the session and to follow up on the action items. Facilitating group discussions in the comfort of your team enhance your self-confidence and is an excellent way to improve your interactions and communication skills.

Personal development is always of paramount importance for a Business Analyst and even more so for a junior one. My advice span from books to read, to other training material or courses I had attended myself. Sometimes we would both listen to the same free webinar and discuss what we had learned afterward.

Key Performance Indicators

We were also able to establish some key indicators to assess how our mentoring and coaching process was performing. They were also used for other analysts joining our organization afterward.

The ones we selected are below:

  • The time needed to bring the new hire up to speed (number of weeks)
  • The complexity of the problems the new hire would be able to autonomously manage after a given amount of time. That assessment would be repeated at different points in time, e.g. 3, 6, 12 months.

Waterfall vs. Agile: A Relative Comparison

The merits of Agile versus Waterfall are well documented. However, it is useful to understand the relative differences between the paradigms and how they impact Business Analysis – particularly if you work in an environment where both approaches are used.

This article attempts to provide a visual, relative comparison between:

  • A traditional Waterfall method that moves through defined phases that include Requirements, Design, Implement and Verify, with a defined gateway denoting the point at which the method moves from one phase to the next.
  • An Agile method that aligns with the 12 principles of the Agile Manifesto.

The approaches are compared across three areas that matter to many Business Analysts:

  • The relative effort is involved in specifying and managing requirements.
  • The relative risk posed by ill-defined requirements.
  • Time to realize benefits.

Requirements Management

The timeline for discovering, specifying, and managing requirements differs greatly between the two approaches. A traditional Waterfall approach includes the requirements phase early in the initiative where the focus is on requirements specification and management activities. At the end of this phase, the ability to change requirements is limited. Therefore, most of the effort to elicit and manage requirements happens during this early phase.

By comparison, requirements elicitation and management activities for an Agile initiative are more evenly distributed over the life of the initiative as requirements are constantly reviewed, updated, and prioritized.

The relative requirement management effort over time for each approach is shown in Figure 1.

Figure 1 – Waterfall vs. Agile: Relative requirements management effort over time

Relative Risk

Missing, incorrect, and/or otherwise ill-defined requirements put the delivery of fit-for-purpose products at risk.  However, the relative risk associated with ill-defined requirements is quite different when comparing Waterfall and Agile approaches.

The risk posed by ill-defined requirements for a traditional Waterfall approach is lower during the requirements phase of the initiative as this is the time when requirements can be added and changed without impacting other areas. After this phase, the risk posed by ill-defined requirements dramatically increases and continues to increase for the duration of the initiative. By comparison, the risk posed by ill-defined requirements to Agile approaches is largely constant throughout the initiative. Figure 2 shows the relative risk of both approaches side-by-side.

Figure 2 – Waterfall vs. Agile: Relative risk posed by ill-defined requirements over time

However, it is worth analyzing the relative risk by its constituent components – the likelihood requirements will be ill-defined and the impact of having ill-defined requirements.

For a traditional Waterfall approach, all the effort to elicit and document requirements happens at the beginning of an initiative with limited mechanisms in place to revise or revisit requirements in later stages – regardless of what new information may come to light. This means that it is comparatively more likely (i.e. higher likelihood) that there will be ill-defined requirements. The likelihood of having ill-defined requirements is fairly consistent throughout the initiative as it is the result of a constraint imposed by the methodology.

Advertisement

In contrast, the impact of ill-defined requirements is low for Waterfall approaches during the initial requirements phase of the project as this is when there are mechanisms in place to actively review and change requirements. After this point, the impact of ill-defined requirements can increase quite dramatically (particularly for initiatives that involve the procurement of resources and/or base products as per the requirements as part of the next phase) and continues to increase throughout the life of the initiative. This is because the cost of changing products increases as the initiative progresses through the design, implement and verify phases.  This is demonstrated in Figure 3.

Figure 3 – Waterfall: Likelihood and impact of ill-defined requirements over time

In comparison, Agile methods include mechanisms to incorporate new information into requirements throughout the life of the initiative, meaning the likelihood of ill-defined requirements decreases as the initiative progresses. By comparison, the impact of ill-defined requirements increases over the life of the initiative as products are incrementally released. This is shown in Figure 4.

Figure 4 – Agile: Likelihood and impact of ill-defined requirements over time

By the end, the impact of ill-defined requirements on comparable initiatives is relatively similar for both Waterfall and Agile methods – it is the likelihood that contributes to the overall difference in relative risk.

Benefits Realisation

Another key point of difference between Waterfall and Agile methods is when benefits are realized. For Waterfall initiatives, benefits cannot be realized until after its core products are fully delivered. There is limited opportunity for early benefits realization in traditional Waterfall initiatives. By comparison, Agile methods offer opportunities to realize early benefits with the incremental delivery of products, as demonstrated in Figure 5.

Figure 5 – Waterfall vs. Agile: Relative time to the realization of benefits

Why does it matter?

So why is it useful to understand the relative differences between Waterfall and Agile approaches? There are a few ways increased understanding of the relative differences between methodologies can help, including:

  • Resource Planning – helping you to plan and allocate resources where they are needed most based on the approach being used.
  • Communication – better able to describe the relative merits and risks of an approach to stakeholders.
  • Arguing your case – provide some talking points to help you argue for an alternative approach.
  • Assessing alternatives – provide a basis for assessing alternative approaches and for tailoring methodologies.

Conclusion

This article has provided a relative comparison between Waterfall and Agile across three areas. In comparing Waterfall and Agile paradigms in relative terms this article does not seek to promote one over the other – both have their place. In addition, this analysis has not accounted for all the available variations, flavours, and mashups of approaches. However, understanding the relative differences between the basic paradigms can assist when preparing and planning to work with a specific methodology – particularly in environments where analysts may be expected to work with multiple different approaches.

Resources: