Teamwork & Making Good Choices

Agile is pretty mainstream now, but some folks still aren’t sure what testers do. In addition, the “Whole Team” approach to quality and the idea that testing and coding aren’t separate phases still mystifies some people. I think my team’s activities the past two days are a good illustration of how agile teams work together to produce high quality software, yet we testers still make valued contributions.

Our software manages all aspects of 401(k) retirement plans. A “plan sponsor” is the company or employer that establishes the 401(k) plan for their employees. We’re working on a theme to allow more than one person working at a company log in and do “plan sponsor” functions for their 401(k) plans, such as submitting payroll contributions or enrolling employees.

Up to now, since only one “plan sponsor” account existed per 401(k) plan, we called that user role “plan sponsor”. This term appears all over our website. Now, we are working on a theme to allow multiple accounts to do the “plan sponsor” functions. These users are not plan sponsors – the employer is. Earlier this week, we had a couple of different discussions on what to call these users and what terminology to use on the user interface. Every manager and developer had a different idea, we kept going round and round discussing it in twos and threes.

Yesterday, I scheduled a meeting with ALL the stakeholders to make a final decision on terminology. You might say, “It’s not the tester’s job to call a meeting like that! Shouldn’t the ScrumMaster or Product Owner do that?” Well, they could, but our ScrumMaster was out sick, and our PO is always swamped. We needed to stop wasting time changing verbiage over and over. In 15 minutes, the various business managers agreed on the term “plan administrator” and on some other related terminology.

Changing terminology - from a mockup

Since the PO was too busy to do it, I mocked up all the changes for all the various pages, posted them on the wiki for our remote developer to see along with narrative requirements and test cases for the changes, and stuck them to our task board along with a task card. Our remote developer, who lives many time zones ahead of us, made most of the changes before we got to work the next morning, and another developer made the rest. I verified the changes, showed the PO, and updated an automated regression test.

We had an issue, though. The modules and classes in our code still used the “plan sponsor” term. We have a “plan_sponsor” table in the database and a column called “sponsor_id”. Eventually it would become very confusing that our UI says “plan administrator” all over the place, and the code has “plan sponsor”. One of our developers decided to copy the “plan_sponsor_mgmt” module to a new module called “plan_admin_mgmt”, and renamed anything in the new module with “plan sponsor” references to be “plan admin” references. This required renaming classes, config files, variables and more. He deleted the code from the old module and will delete the old module itself when the dust settles. (He found out later he could have done the renaming in the old module, but as he says, live and learn).

Later, we will change URLs, velocity variables and spring field declarations, but as that will change HTML Ids and names and cause automated GUI regression scripts to fail, we are coordinating that. And, we still need to change the database table and column names.

It’s a lot of trouble, but it would have been more trouble later, when someone wants to change the “plan administrator” functionality, and can only find “plan sponsor” in the code. We all think we’ll remember everything forever, but we have a big code base considering our team size, and what if we hire a new developer?

So what’s my point? As a team, we did what needed to be done to maintain a high standard of quality, and avoid technical debt. No manager told us to do that. Our Product Owner did not “prioritize” refactoring the code to have the new terminology, because that isn’t a business decision – we control our internal code quality. Though everyone on our team cares about quality, I made my own particular contribution by getting everyone to agree on terminology and verbiage, writing a task card and posting the mockups. It’s been a fun couple of days!

10 comments on “Teamwork & Making Good Choices

  1. yes refactoring is the team’s decision.
    You never ask a chef why he cleans his kitchen.
    It’s one of the things great chefs do.
    You can not hire a chef and tell him not to clean his kitchen. In IT we should not allow our customers tell us they don’t need refactoring.


  2. My Congratulation!
    You have great real “Agile Team”! It is really great that your team care about quality.

    About testers role – scheduling meeting etc. There is no testers in Agile 🙂 (in theory) so you are team member, and if there is necessary to schedule meeting or do something else, every team member can or even should do this.

  3. Thanks for sharing, I admire the teams and your proactive approach, Something we try to encourage in our team and our projects.

    I’ve seen it all to often where people complain that a decision needs made, or that the team should be performing a function like core review.

    But often I’ve seen the opposite, one person chasing a decision, advocating a feature, gathering the team to instigate change. The actions of individuals, people taking responsibility, can change things from good to great.

  4. You make such a good point here. I was a little shy about “overstepping my bounds” as a QA lead on a small agile team when I started. It seems like every time I do take the lead though, the devs are grateful to have my team’s prospective and it ends up being a very good experience for all of us. It is so nice to see whole-teamwork in action.

  5. I’ve been meaning to post a followup to this. Within a few sprints, we got all the other tasks such as renaming the database objects completed. Now it’s almost a year later, and this functionality has worked well, and been extended into other areas of the application.

Leave a Reply

Your email address will not be published. Required fields are marked *


Recent Posts: