I’m currently transitioning a team from Agile to Shape Up. QA is seeing the biggest change because we’re leaving JIRA + QA is handled very differently in Shape Up.
The departing PM and QA both said that leaving JIRA is a bad idea because they have invested time in building test cases using Zephyr.
We have no plans to return to JIRA, but I’m wondering how others in the community have handled test case documentation or management, or have addressed this with QA, whether in Basecamp or otherwise.
Coming from a company that had no dedicated QA team…I have a few thoughts on this matter.
As I understand it, with Shape Up the “QA” phase is done by the development party (the team that develops the feature/fix). Considering that the development is done within some kind of restraints of the existing environment, I’d say that this team should add whatever steps are necessary to the QA process as well (automated tests, “manual” tests, system tests, integration tests, etc). And those tests have to be performed, it is the responsibility that moves, maybe, from a dedicated QA team to the dev team.
Using Jira and Zephyr (hate Zephyr btw) is definitely not a necessity. It’s just a tool. I assume the departing PM and QA are saying it’s bad to leave Jira because that makes them feel their work was for nothing. I wish more companies stopped doing things because “they’ve invested resources” and started doing them because they should.
Following the same logic, you’d never refactor code because of the huge investment of writing the original code in the first place.
Thanks Alex for the response! This is helpful.
My learning from this: Process change is one thing, but the people/role change adds another dimension of complexity to shifting to Shape Up. Managing the people side of things matters deeply. Especially in roles such as QA, where new expectations may differ vastly from prior experience.
After some reflection, I’m thinking of the Zephyr tests as a full suit of plate armor. They protect the product but the big tradeoff is the weight they add to the team’s workload. I’ll keep the previously created tests for historical reference, but moving forward, I think the delivery team will have to feel out which tests (if any) are a good fit during any given cycle.
That’s exactly the solution I’d suggest. Taking the “existing” model and slowly working out the new, better way is the right path forward.
If you have a dedicated team of QA people, I would consider integrating them into the “dev” groups together with the designers and the developers, as in the ShapeUp model. Then you are following the model (that is delivering work at the end of the cycle), but yet using the acquired knowledge and experience in the process.
And clearly, I would make an attempt to avoid manual tests as much as possible.