Skip to main content

Tag: Scrum

Seven Common Mistakes with the Daily Stand-up Meeting

Written by Greg Smith on . Posted in Articles.

The daily stand-up meeting, also known as the daily scrum, may be the best of all of the agile practices. Why? Because it meets three criteria:

1. It’s easy to start using
2. It can often be used without other agile practices
3. It provides great value

Stand-ups can be interjected into waterfall teams and they can be used without converting to iterations or other common agile practices. From an adoption perspective, the resistance to using stand-ups is low. From a value perspective, teams quickly see the how the stand-up identifies risks and issues early. The stand-up gives them more time to react and still hit their goals.

As good as the stand-up meeting is, if done incorrectly it can do more harm than good. As an agile coach I have found I often skimp on stand-up training because it seems so simple. But this skimping has come back to bite me several times. How have I been bitten? By the seven common stand-up mistakes below.

Mistake # 1 – Not Standing (the daily sit down)SmithDec18 Img02

Teams usually stand when they first start doing the daily stand-up because they have just came out of agile training and they were taught to stand. But as time progresses it is common for some teams to assume standing is a formality and they start sitting more and more. This especially common if the meeting is in a conference room where chairs are available.

Standing is not a formality but rather a key success factor in establishing collaboration and keeping the meeting short and effective. How can you keep the team standing? Here are some tips that usually help:

  1. Try to do the stand-up where chairs are not available.
  2. Keep the team focused on the three key questions: What did you do since we last met? What will you do between now and the next meeting? Do you have any blockers or constraints that are impeding your progress? It is common for team members to explain their impediments in detail, and for a dialogue to start up between a few team members on how to resolve the impediment. This is fine if a solution is agreed to in a few seconds, but usually this a long conversation that ties up the whole team when only a few team members are needed. So as a Scrum Master, coach, or team member, get select team members to work impediments together after the stand-up.
  3. Use a physical status wall (covered in mistake # 5 below).

Mistake # 2 – Team Members Not Showing Up On Time

Many teams struggle with team members drifting into the stand-up, often 5 to 10 minutes late. This contributes to the issue noted above, not standing, but also demonstrates a lack of personal discipline. Here are some tips for addressing the late arrival issue.SmithDec18 Img03

  • Pick a time of day that the team all agrees to, to have the stand-up. Sometimes management will ask the Scrum Master to have the team meet at a certain time, but I have found it is better to meet when everyone has arrived at work, and at a time the team all agrees to.
  • Get support from line managers. Agile is about team self-management and self-discipline, but everyone does not arrive at this state at the same time. If you are a Scrum Master, work with all of the managers who team members work for, and get agreement that the daily stand-up is important, and that punctuality is important. Line managers can emphasize these values when they do one on ones with their team members.
  • Provide a buffer between meetings that occur before the stand-up. If there is another meeting that precedes the stand-up, make sure the stand-up is not scheduled when the other meeting ends. Instead add a buffer of 10 to 15 minutes so that the stand-up is not impacted by any upstream meetings that runs over.

Mistake # 3 – Allowing DistractionsSmithDec18 Img04

Daily stand-ups are ineffective if the team is not focused during the stand-up. Here are some tips for keeping the focus:

  1. Location, location, location. If you do your standup meeting in the wrong location the team will get interrupted by passers by, or be distracted by eye candy such as the street below. Pick a location without chairs, some level of isolation, and if possible no windows.
  2. Set a team norm of no cell phones or laptops during the standup.
  3. Focus on good meeting etiquette – no side conversations or whispering.

Mistake # 4 – Updating the Project Management Tool During the Stand-upSmithDec18 Img05

Are you using an online tool to track project status? Maybe Mingle, Rally, or VersionOne? Many times the team will stand idle while someone is updating the tool during the stand-up. Try to avoid this at all costs. Have someone take hard copy notes and update the tool later, or even better, use a physical status board and have team members physically update their tasks during the daily stand-up. Remember that the tool serves the team, the team does not serve the tool.

Mistake # 5 – Not Using a Physical Status Wall

SmithDec18 Img06I love electronic project management tools. They let me consolidate information and do reports across a portfolio of projects. But the tools can impede collaboration during the daily stand-up. If one person is projecting the virtual status wall from an electronic tool, and discussing it with the team, the team often becomes an audience and just listens. However, if you have a physical wall with task cards, team members move and update their physical cards during or before the stand-up, which leads to much richer discussion and interaction. You can use an electronic tool in parallel (most of my clients do). It may be a little redundant, but the value a physical wall provides offsets maintaining 2 tools. And it will lead to a better stand-up meeting.

Mistake # 6 – Not Having a Dedicated Team Room

SmithDec18 Img07

You may be wondering why you need a dedicated team room for a stand-up. You do not need a dedicated team room for the stand-up meeting, but you do need one for a good stand-up meeting. Confused? Here is the scoop. If your team is distributed all over your campus, and they come together physically each day for 15 minutes, do you think you can get them to only discuss status? I have not been successful in doing this. Developers and testers will want to get into testing details during the stand-up, user experience wants to talk to developers about screen details, and so on. If you have a dedicated team room, team members can talk about the construction details all day long, and they will not need to deviate from the stand-up status/impediment discussion.

Mistake# 7 – Not Using a Stand-up for Distributed Teams

SmithDec18 Img08Most companies I work with have team members in the United States, India, and China. These teams will often tell me they cannot do stand-ups because everyone is in different time zones. I understand this issue but I also understand that we undertake a lot of risk if we do not communicate daily. To get around this issue I have teams do the following:

  1. Do a stand-up meeting at each location. At a minimum get team members synchronized at each site
  2. Have one team member from each team work a staggered schedule. These team members on staggered schedules can do a video call or audio call to synchronize each day, and then take that information back to their local teams.
  3. Use electronic tools to share status details. Electronic tools really show their value with distributed teams. Everyone can see the status information around the world, as soon as it is entered.

Follow these steps and you will establish a sound daily stand-up process, which will provide a great foundation for all of the agile practices you use with your team.

Don’t forget to leave your comments below.

The Power of Story in Business Analysis

Written by Jarett Hailes on . Posted in Articles.

Tell me if you’ve heard this one before – you’re on a project that was thrust on your stakeholder groups from high above.  They were insufficiently consulted during the problem definition phase, and they are now questioning everything during implementation. These stakeholders can’t get the project to be outright cancelled, but they can cause it to be ultimately unsuccessful if they don’t commit to putting their time and energy into ensuring that the solution being developed is appropriately used.

Sound familiar? Business Analysts can often be faced with reluctant or even hostile project participants. Sometimes this can be due to lack of sufficient involvement early on, other times it is because they do not see the value in your project. How can you work to overcome these powerful barriers and get your entire stakeholder group to work with the team to successfully implement change?

A few years ago I was working in the education space and faced this challenge. The government had decreed that a change was to occur and that all school boards within the jurisdiction needed to conform within a certain timeframe. As more boards became aware of the change and the impact it would have on their organizations, many naturally questioned why the change was needed. The project team needed an effective way to present the long term value of the change without boring people with facts or figures, or getting into long winded explanations. So we focused on the one common value driver that all the school boards had in common: the student.

We used a short two minute before-and-after video depicting a day in the life of a new student and how the change would positively impact their educational experience. Even seasoned educators had their heartstrings pulled seeing the video; they could immediately empathize with the student and recognize how the situation described was all too common in today’s world. We used this story to introduce nearly every presentation and dialogue we had with our stakeholders for several years, as it helped establish the reason for why the change was necessary and put everyone’s mindset into focusing on the common goal all stakeholders had – providing the best possible education to the student.

Stories can captivate an audience, give them the critical information they need to understand a complex problem in a concise package, and be used to get people with very different backgrounds and goals to relate to shared events and situations. Leveraging stories to engage readers is used in the educational setting to help students process new or challenging experiences. Danielle Lowe, an educator in the state of New York, has observed “story-telling is a timeless teaching tool. Expression through text offers readers of all ages the opportunity to find solutions through the characters and conflicts within a story, and thus within themselves.”

Business Analysts have several opportunities to leverage stories in their work:

  • Defining a business need: sometimes worthwhile projects are never started because the individual(s) who recognize the problem are not in a position to allocate resources to develop a business case. Many Business Analysts who are embedded in business units can uncover problems or opportunities that can have a massive impact on the organization. Stories can be a great way to convey the business need to potential executive sponsors and get them interested enough in the topic to have a business case commissioned.
  • Documenting/communicating requirements: as Scrum methodologists are well aware, sometimes requirements can be best described in the form of stories. These do not need to be long narratives, but rather simple, structured descriptions about what needs to be addressed and in some cases why. Stories can also be effective when you need to summarize detailed or complex requirements. When performing a current state analysis of an entire division, I analyzed over a hundred processes and documented hundreds of requirements. To communicate my findings, I used three simple stories to describe the main challenges the division faced in their daily operations. This gave me a starting point to show how these challenges could be addressed through changes in processes and supporting technologies.
  • Secure stakeholder buy-in: while this activity is not solely performed by Business Analysts (indeed, the responsibility for buy-in is usually assigned to the Project Manager or Change Management team), we often directly engage with the stakeholders that will ultimately make the solution being implemented successfully operate and realize its full potential. As a result we are the first to encounter signs of potential resistance, and can be put on the spot to justify why a project exists or receive criticism for how the project is going. BAs have an opportunity to put forward a succinct but effective description of why a project is valuable, and can use story to relay the message in a narrative that matters to the stakeholder at hand. This can be tailored by stakeholder, often by using problems that they are encountering in today’s world and describing how the project will address those issues. When working on an inventory management project, I used two examples of the biggest pain points the group was encountering to convince them that performing extra data entry up front was worth their time and effort.

You don’t need to have the skills to pen the next great novel to effectively use stories. Focus on the narratives that matter to your audience and think about what compels them to do a better job. For some groups or individuals, it’s the customer that drives their desire for doing good work. For others, it may be recognition or compensation. Like any good story, start off with a problem that needs to be solved and then have your hero (in this case, the proposed solution) save the day. Don’t over exaggerate what the solution can do for the sake of the story, or else you may lose credibility with your audience. Even if the story has a fictional character or problem situation, make sure the benefits the solution is shown to perform are something it can actually do.

Stories can be a powerful and effective tool at conveying information to audiences, and when done well can be used to give people with entrenched viewpoints a chance to look at another perspective without being bombarded with facts or differing opinions. Business Analysts can look to leverage stories to engage and expand the minds of stakeholders in working towards a common goal. 

Don’t forget to leave your comments below.

Agile Misconceptions: What Agile is Not

Written by Curtis Reed on . Posted in Articles.

Introduction

Over the course of my career in software development, I have had the fortune of working in a wide variety of companies employing radically different approaches to the software development life-cycle (SDLC). Some strictly stuck to traditional Water Fall. Others called themselves “agile” but never actually bothered to adopt any agile framework, and were thus a blend of Water Fall and Agile—and all too often, not a successful blend either. Another strictly adopted a true agile methodology and decided that there was no need for a PMO since, as they put it, “we’re SCRUM.” Other companies used the same Scrum methodology but saw the value of having a PMO as well.

As I have closely followed discussions on Project Times (and other blog sites), I have noticed some discussions around Project Management methodologies that are fine in theory, but often seem divorced from real-world applications. You can often find arguments prefaced by statements such as “good project managers do X,” or “the PMBOK methods require Y,” or even “any experienced Scrum Master knows…”

After working in so many different environments, the most important lesson I learned was that a dash of humility goes a long way. In other words, no matter what framework is employed, most companies will adapt the theoretical suggestions of the framework to make it work for their needs. Project Managers who suffer from what I call “theoretical myopia” may fail to see the value in the adaptations the company has chosen. A strict enforcement of a theoretical framework, without regard to results, is sometimes just as harmful as not enforcing any framework or process at all.

Target audience

There are several types of readers for whom this article is intended. Some readers may currently work in Water Fall environments and may not have any experience with agile. Others may work in companies that claim to be agile, but really are not. And a few others may work in true agile environments that strictly follow the guidelines provided by whoever trained them in that framework, and don’t realize that there are “many ways to skin a cat.”

Let’s answer the question: “What is agile?”

The simplest explanation is that it is an approach to development based on iterative and incremental development. It is characterized by “adaptive planning,” “evolutionary development and delivery,” “time-boxed” iterations that result in incremental releases of functional product, and must provide rapid and flexible response to changes and discovery.

What exactly does this mean in the real world? One must remember that in the traditional “Water Fall” approach, the project flows through a series of steps or gates, and does not progress to the next step until the current one is complete. As an example, Requirements Gathering only begins once the Project Charter and Statement of Work (SOW) have been approved and signed off. Development begins only once the full set of requirements for the entire solution are gathered and approved by all stakeholders. A testing phase begins when the entire platform is developed. Because the development phase can last for many months, even years, before code is released, Project Managers may struggle to differentiate accurately between perceived progress (often reported as developers’ guesses of “percent complete”) and actual progress. This, in turn, results in unpleasant surprises when the delivery date looms two weeks away and the developers unexpectedly report that they still have eight weeks of work to perform!

What is the unsurprising response from senior management and the client? “Why didn’t we know we were behind schedule earlier?”

As a concrete example, let’s look at a real-world application, first for a Water Fall approach.

Think about developing a Web page, especially one designed to handle flight reservations. In a Water Fall approach, many weeks would be spent gathering comprehensive requirements for the entire page and every field on the page. This would include not just a list of fields but all the validation rules for every data point. Development would not begin until this comprehensive document was completed and then agreed upon by stakeholders.

Once the requirements were gathered and approved, development begins. The entire page (or even the entire website with all functionality) would then be created and tested. The page or site would then be released to the customer. This same process might be performed not only for the initial home page, but for every subsequent page in the site.

In many cases, the very first time the customer saw the direction the team had gone is when the page, or entire site even, is unveiled for the first time in a customer demo. This is when many customers balk in frustration because the released product did not accurately represent what they thought they had described. A crisis ensues because the client is very unhappy that functionality is unsatisfactory. From the development company’s perspective, changes to the design and implementation are quite difficult and very expensive.

I will make the comparison by examining the Agile framework I know best, which is Scrum. In Agile development, high-level ‘requirements’ are gathered during the project estimation phase, often when the project charter (or SOW) is being written. This information is gathered in “user stories” (or other equivalent) that describe how the major components are expected to behave, in terms of user experience. “As a customer, I want to be able to book a flight from one destination to another, for a range of dates.” Additional functionality may be captured in other stories, such as “Flight Cancellation,” “Reservation changes,” or “Choosing seating.”

Experienced teams are able to size the anticipated work by a measurement of complexity, rather than guessing how long it will take as a measure of time. Once work begins, refinement of requirements and behavior often occur with direct client involvement while development is underway, in an iterative process.

The Scrum approach breaks up the whole page into discreet areas of functionality and plans to work on each piece. The “Flight Reservation” page is broken into “Select an origination Airport,” “Select a Destination Airport,” “Select a range of origination dates,” “Indicate seating preferences,” etc. These become the User Stories, which are given acceptance criteria. The stories are then sized by complexity, tasked (with estimated hours for each small task), and planned out across short iterations. The stories and iteration plans are reviewed with direct client input. As development progresses, the customer sees the result every couple of weeks as each iteration (or “Sprint”) is completed. The customer then approves the output, or suggests changes that, being found early in the process, require minor “tweaks” instead of large architectural changes.

The frequency of these “demos” helps the customer participate in constant revision and modification, so each delivered piece of product is much more likely to satisfy the customer’s needs. Rework and associated cost is thus reduced. Client satisfaction is increased.

The benefits to Agile are quite simple to comprehend. The agile development cycle is designed to provide valuable functionality that accurately represents customer wishes on frequent deliveries, contrasting with the Water Fall approach, which often leaves customers waiting for long periods of time before they see the first benefit from their investments.

What agile is not

An Agile team is flexible, agile, and adaptable. The Agile team proactively elicits and documents the desired function with direct and frequent client involvement. It also frequently reviews the developed product with the client to verify that functionality meets client wishes. The talented development team is encouraged to meet those needs creatively. The project manager (Scrum Master) vigilantly monitors a daily “burn down chart” that allows the team to change direction swiftly in order to get the development back on track, in the case where circumstances have caused deviation from the plan or to quickly react to new information received.

Having laid out this basic understanding of what Agile is, and contrasting it with Water Fall, it is important to reiterate that the core concept of Agile is not a lack of process or a “watering down” of documentation! In my experience, this misunderstanding has been propagated by some managers who believe that Agile frameworks translate to nothing more than a loosening of control and reduction of analysis and planning. Improper implementation of an ill-defined concept of “Agile” can result in even graver problems arising. It has been my experience that “the cure was worse than the disease” in those cases.

I will dive into specific problematic areas in subsequent articles.

Don’t forget to leave your comments below.

It’s the Goal, Not the Role: The Value of Business Analysis in Scrum

Written by Ellen Gottesdiener on . Posted in Articles.

In agile development, what happens to the traditional business analyst? Consider Scrum, currently the most popular agile method. In Scrum, there is no “business analyst” role. In fact, there is not an explicit role for tester, project manager, architect, developer, data administrator, user experience designer, customer support representative, or product trainer. Instead, Scrum has three roles: the product owner, the ScrumMaster, and the delivery team. Their collective goal is to deliver high-valued product needs continually. So, where and how can a business analyst contribute?

One possibility is the ScrumMaster role. Great ScrumMasters are facilitative leaders with a diverse set of analysis skills and strong communication and facilitation abilities. In addition, they have a sound understanding of the business domain. Business analysts and project managers with those strong skills are good candidates for the ScrumMaster role.

Another possibility is the delivery team. On some Scrum teams we’ve coached, the business analyst blends into the delivery team, participating and often leading the activities of planning, analyzing, testing, and demonstrating the product. Using Scrum terminology, that work is burned up and burned down, along with the work of design, development, and so on. 

The Business Analyst Is Not the Product Owner, Unless …

The product owner role requires deep domain and product knowledge to guide decisions about what to build and when to build it. The product owner, in collaboration with the delivery team, explores and evaluates product needs to make those decisions. That’s business analysis work. 

The product owner may choose to explicitly and transparently delegate decision-making authority. We’ve seen this responsibility delegated to a business analystwho reports within the business or product management organization and has the requisite domain and product background.

Strategic and Tactical Work of the Product Owner

The product owner role in Scrum is crucial for success. The product owner is responsible for the planning, analysis, communication, and decision making to ensure that the right product is delivered.

 Strategic product owner responsibilities include:

  • Lead customer and product-discovery activities.
  • Create strategic product plans and define business value (product profitability).
  • Communicate the product roadmap and plans to internal and external stakeholders.
  • Develop and manage a lean, dynamic product backlog (also called “pruning” or “grooming” the backlog).
  • Select and analyze product backlog requirements to prepare them for agile planning workshops.
  • Identify themes for each planning cycle.
  • Lead or participate in agile planning and retrospective workshops.

Tactical, day-to-day product owner responsibilities include:

  • Participate in product backlog grooming (e.g., work ahead, make ready, planning, agile analysis, and pruning workshops) to prepare backlog items for estimating and planning.
  • Specify acceptance criteria for each backlog item.
  • Review and approve user stories.
  • Attend daily stand-ups and the end-of-iteration and end-of-release demonstrations and retrospectives.

That’s a lot of responsibility—and it’s time-consuming, to boot. In addition, most product owners wear many other hats. In commercial software organizations, they may be product managers. Or, in organizations that develop software to support their internal IT operations, product owners may be mid- or senior-level business managers. No wonder the product owner needs help! 

Balancing Strategic and Tactical Work

In our experience, many product owners don’t have time to balance the strategic responsibilities with the tactical work needed to sustain a healthy flow of delivery. A time-pressed product owner has the following options:

  1. Do it all (sometimes not very well, causing bottlenecks and delays).
  2. Establish a product owner council headed by an über-product owner, with strategic responsibilities distributed among the members.
  3. Get help with the tactical analysis work. Rely on the folks on the delivery team to do much of the business analysis, and retain strategic and tactical decision-making authority.
  4. Retain strategic responsibilities and delegate the tactical work to someone else (e.g., a domain-savvy business analyst). This delegation should be explicitly and transparently communicated to all stakeholders.
  5. Some combination of the above.

Beyond Roles to Goals

After exploring and evaluating requirements options, the goal of analysis is to allocate the highest-value requirements for delivery. No matter how roles are classified on your agile team, that business analysis work is vital. It is best done collaboratively, leveraging everyone’s skills to build and maintain a shared understanding of product needs.

Above all, it’s the goal, and not the role, that matters.

Resources

Product Owner Role

  • Pichler, Roman. Agile Product Management with Scrum: Creating Products That Customers Love. Addison-Wesley, 2010.
  • Schwaber, Ken, “Product Owners Not Proxies.” 

Agile Analysis

This article was originally published on TechWell and Agile Journal, August 2011

Copyright © SQE, 2011

Don’t forget to leave your comments below.

Ellen Gottesdiener helps business and technical teams collaborate to define and deliver products customers value and need. Ellen is an internationally recognized facilitator, trainer, speaker, and expert on requirements development and management, Agile business analysis, product chartering and roadmapping, retrospectives, and collaborative workshops. Author of two acclaimed books Requirements by Collaboration and The Software Requirements Memory Jogger, Ellen works with global clients and speaks at industry conferences. She is co-authoring a book with Mary Gorman on agile practices for discovering and exploring product needs. View her articles, tweets, blog, and free eNewsletter on EBG’s web site.

Mary Gorman, CBAP, CSM, and VP of quality & delivery at EBG Consulting helps business and technical teams collaborate to deliver products your customers value and need. Mary works with global clients, speaks at industry conferences, and writes on requirements topics for the business analysis community. She is currently co-authoring a book with Ellen Gottesdiener on essential agile requirements practices.

Scrum vs. Waterfall Round 2; The Fight Continues

Written by Elizabeth Larson on . Posted in Articles.

scrumvswaterfall1Last month we began our “fight” by exploring two estimating techniques that are often used on both Scrum and Waterfall projects (view here). The first was relative sizing (one kind of analogous estimating) and the second Delphi (called Planning Poker in Scrum). Scrum won both rounds (barely) because, although both techniques can be used on both types of projects, their usage in Scrum seems easier to understand, learn, and apply. I don’t know about you, but when I hear the terms Analogous and Delphi I think academics and hard work. When I hear about tee-shirt sizes and planning poker, I think fun.

This month, inspired by a debate on Agile vs. Waterfall, presented by the Phoenix chapter of IIBA, I want to compare Waterfall to Scrum in a variety of different ways. As I listened to the two sides during the debate, I was amazed at the number of the similarities, as well as the importance of the subtle differences. This month’s blog will explore both the similarities and differences.

Before I begin, I want to stress the point that neither one is a methodology. Neither is prescriptive. Waterfall is an approach. Scrum is a framework, part of the myriad Agile methods. Both allow for the use of a variety of techniques. To be effective, both require an appropriate amount of rigor, although we acknowledge that both approaches have been implemented in a wide variety of ways. For the discussion below, we’ll assume the appropriate level of rigor for the project at hand.

Similarities

There are many ways in which these two approaches are similar. Both:

  1. Have processes to request, approve and prioritize changes. Both put focus for the approval and prioritization on the Business (product owner/sponsor/SMEs).
  2. Stress the importance of communications.
  3. Allow for more or less rigor, as appropriate.
  4. Find communications easier when the teams are co-located.
  5. Both face more challenges with virtual teams.
  6. Have processes to manage the scope.
  7. Estimate the work involved in business analysis whether phase (s), releases, iterations/sprints.

Differences

Many of the differences lie in how these processes are implanted. To understand the vast differences in implementation, we need to understand that many organizations have their own methodologies, so their processes for completing business analysis vary extensively. Also, many organizations use hybrids or “best of breed” implementations. With that in mind, let’s examine some differences between Waterfall and Agile.

Intricate, large projects. On large, intricate projects with many business and technical interfaces and impacts, with a variety of cross-functional SMEs or with many compliance regulations, there are advantages to the Waterfall approach. While these projects can also be implemented using Scrum, it is harder when there are project dependencies.

  • Coding and testing. On the large projects I managed, we were always touching programs and test data that other teams needed and vice versa. It seems to me that following a detailed plan places less stress on all the teams. Even when slippage occurs or the team completes programs earlier than anticipated, following the plan and communicating variances in a more formal and proactive way is helpful to all the teams involved. Again, it can be done using Scrum or other processes, but I have found that following a plan is a stress-reliever.
  • Incorporating changes. Again, when there are approved changes and there are significant project dependencies, it can be helpful to change the plan, so that a schedule for completing these changes can be determined and communicated to everyone impacted by the change. This is particularly true when the approved changes have significant impacts and can cause changes not only to work completed by the team, but by work already completed and tested by other teams.

The winner: Waterfall!

Defining requirements when they are highly volatile. Waterfall projects have approval points, often called toll or stage gates. When requirements are unstable, business analysis can seem to take forever and the sponsor may get frustrated with what appears to be analysis paralysis. I once had a sponsor tell me that he had never seen analysis take so long, but was surprised and delighted that the project get done so quickly once we had the requirements. Thoroughness in requirements definitely paid off. However, there was significant frustration as the churn was happening.

Scrum projects have the wherewithal to handle this kind of churn better in my opinion. User stories that are pretty well understood are closer to the top of the product backlog and are ready for inclusion in upcoming sprint(s) than “epics” that are less understood.

The winner: Scrum!

Managing scope and changes. On Waterfall projects, schedule, cost, and scope baselines are established (as well as others). These become project constraints. When changes are approved and prioritized by the Business, the sponsor, often upon the recommendation of the project manager, needs to decide which of the baselines will change. I have talked to many Scrum proponents who argue that Agile projects expect change, but Waterfall projects do not. This assertion is simply not true. I have yet to be on or hear of a Waterfall project that did not expect changes. Having said that, modifying the schedule, particularly when it involves changing dependencies, can be cumbersome and frustrating.

I think managing scope on Scrum projects is easier in many respects, most of which relate to the fact that having small sprints helps the framework accommodate changes with far less pain. In addition, I have seen more consistency in the way changes are requested, approved, and prioritized on Scrum projects.

The winner: Scrum!

I could go on with this comparison, but my little blog is turning into a full-fledged article, so I’ll simply list out areas where I think Waterfall wins and address them in more detail in future blogs.

Waterfall Wins in these Areas:

  • Effectively using the role of the BA to define requirements completely, using a variety of elicitation and modeling techniques. Although Scrum is catching up, it still lags behind.
  • Defining the business need and business case. Most of the visioning I have seen on Scrum projects has tended to be superficial. Again, this may be due to the way I have seen it implemented.
  • Getting from the “as-is” to the “to-be.” Ensuring that the solution in general and software in particular supports business processes or if not, that the business is ready for the change with such things as new processes, training, the required sales, marketing and support resources, etc.

Of course Scrum wins in some other areas, too. More later!

Don’t forget to leave your comments below