Falling Up the Waterfall?

Blog Barista: Mary Pawloski | Aug 22, 2018 | Testing & QA | Brew time: 6 min

So, how does one transition from Waterfall’s “hurry up and wait” cycle to Agile’s “there’s no time to wait, hurry up” cycle?

Over twenty years ago, IT jobs were compartmentalized. The Waterfall style of the software development lifecycle was the norm. Each role in the process had well defined responsibilities. I’m not saying they were any easier than they are now, but the roles and responsibilities related to the job were more specific and there was less overlap across the different roles. Fast forward to today, more companies are moving away from the Waterfall method of development toward the Agile process.

So, how does a person go from being a Software Tester in a Waterfall world to a Business Analyst on an Agile team? Silent screams. Kidding, but not really. It takes a lot of patience, perseverance, and an attitude adjustment. It’s definitely an interesting transition, but it can be done.

Waterfall – A “Hurry Up and Wait” World

When I started in the Software Testing role, I made the move from the role of a Customer Service Representative for the same product I now had to learn how to test. I didn’t have any technical skills, but I already had a working knowledge of how the system was supposed to work from the customer’s point of view.

As a Software Tester in a Waterfall world, details were important. The type of project and for whom I was working for determined the level of repetition and details that were included in a test case.

Test cases were written to verify that both the business requirements and functional requirements were met for each area of the product being developed. They were executed by the end users. If it applied, end-to-end test cases were written to test the business flow across the system.

A release cycle lasted anywhere from three to six months. Requirements were gathered and adjusted for development constraints, developers created technical requirements documents, and testers created test cases before development even started. Once viable code was produced, it was given to the testers. All testing was done during the last phase of the project.

Code builds for new code and bug fixes might happen once every couple of days.  Sometimes code builds were only done once a week. If a tester was blocked from testing, they may or may not be assigned to help another tester as projects were segregated by functional area and cross-training was not the norm.

Agile – A “There’s No Time to Wait, Hurry Up” World

The Agile process has more flexibility regarding who does what. There is more flexibility and less downtime if multiple people on a team can perform multiple jobs. While a developer is still a developer, a well-balanced Agile team will have several people who can write code, review code, merge and build that code, and even troubleshoot and fix code that they didn’t necessarily create. On the business side of a project, especially larger projects with fewer resources, both roles overlap to the point where, in many cases, one person or a small team is responsible for both jobs.

On Agile teams, the entire team is constantly busy, making adjustments on the fly so that a working version of the product can be deployed quickly. The product is built incrementally with critical functionality developed in a logical order for the greatest efficiency.  Of course, these decisions are not set in stone. Stuff happens. Life happens. When things don’t go as planned, it changes development’s course of action, sometimes temporarily, sometimes permanently.

As I became an Agile Business Analyst, I needed to learn how to build and identify gaps in the requirements for the current product delivery, write the test cases needed to test the piece of the product in development, provide as much information as possible for the developer so that they develop what the business needs, all while planning what needs to be done for the next piece of the product that will be developed. It wasn’t easy.

However, I wasn’t prepared for the quick transition from leading Requirements Review meetings to putting those requirements into visual aids and technical details for the developers, while creating the test cases needed to adequately test the product.

Once that was done, I needed approval on my tests, had to make any adjustments based on the user’s feedback, and finally test the product, all while I began the process all over again with the next piece of the product while finishing up the last piece I was working on.

I had many “deer in the headlight” moments, and plenty of times I wanted to walk away.  I felt it was just too much, too fast. I questioned why was I doing things, that in a Waterfall world, would have been the developer’s responsibility? (“Calgon, take me away!”)

Adapt. Then Adapt Some More.

The hardest part in this transition was letting go of the details. I had always documented every possible scenario in detail. The existing data was identified up front or it was created to meet the criteria of the test case. Doing that was not possible because of the time constraints that exist on an Agile team. I had to learn how to move up to the highest level of detail that still captured the scenario that would meet the functional and any applicable business requirements.

In addition, I had to be able to provide the developers with the actual source of the data that had to be displayed. Sometimes, it could be found in a single table in the database.  Sometimes, it could be found in a single table pointed to another table to define the values found in that table. And sometimes, the connection was made through a maze of table data that was so convoluted that I needed an interpreter to understand the connection! But, I did it.

Just when I thought I knew what I was doing, I was informed that something I worked on didn’t meet one of the norms, needed to be changed because it couldn’t be implemented as written, or was almost, but not quite right.

Can I bang my head on my desk now?  

The best part of this whole transition has been learning new stuff. The screen mock-ups were initially only supposed to be a representation of what the screen could look like, though it quickly became what the screen should look like. This meant that the details had to be consistent with the rest of the screens, otherwise things would look bad. This also meant there were more things that could change.

As I became more comfortable with what I was doing, and less stressed about how much there was still to do, or not getting it right the first time, being stressed wasn’t such an issue. That is what happens in an Agile world. Things can change at a moment’s notice and you have to be able to adjust on the fly.

Working on my first “real” Agile project required a lot of patience, a huge learning curve, and confidence that I could get the job done. There are still times when I get frustrated and want to bang my head on the desk, but isn’t that normal on any project?

Other recent posts: