-2

So most companies i've been at say they are agile, but really aren't. I understand...it's hard to transition but I was put as the owner of the QA department in a small company and im really trying to get an actual process going.

So one thing that HAS worked is actually get a Kanban board system setup for Issue tracking. we've been linking MR's to issues and as they close they get pulled into retest (where I test them) and finally moved to close.

However the actual "start" of the development cycle is where this falls apart. Collecting requirements and so forth. I understand the "general" idea of how agile works but im really trying to understand in detail.

To "Me" what feels right is the following steps:

  1. New Project-->Statement of Work
  2. Requirements identified from SOW (Would require a BA or knowledgeable dev or COO or someone to list them out (How?) and then get signoffs from client.
  3. Estimation and Discovery phase (do story points get assigned in discovery phase? what about estimation)
  4. Using some system (Like Jira?) list all Story points
  5. Per Sprint (or weekly meeting) assign stories.

This helps me because I can test against stories and know exactly what to expect. But how on earth do you set this up against a client that is not used to this process. We've used basecamp before and it's just....messy?

I was just trying to get an idea if what I see is even remotely correct?

Thanks!

Improve this question
4
  • 3
    Are you expecting this to be a step 1, step 2, step 3 linear process that never deviates from a rigid template? I very much doubt that it ever works that way. Agile itself is supposed to be agile. Otherwise, why would you call it Agile?
    – Robert Harvey
    Commented Aug 9, 2017 at 3:49
  • It sounds like your company does contract-based work for other external clients. Do you have any real say in how the contracts are written up between your company and its clients? Are your process proposals for the whole team or only for the QA department?
    – Derek Elkins left SE
    Commented Aug 9, 2017 at 6:29
  • Agile/scrum does not tell you what to do, it only provides a framework for planning and information transfer. You have to bring your own core activities, those that actually lead to useful software, including any methodology if you think you need one.
    – Martin Maat
    Commented Aug 9, 2017 at 11:25
  • @DerekElkins I think that may be the issue is that contracts come and we do keep clients long term of course, but a lot of them are quicker. Also the clients obviously differ A LOT per each one. However some are very long term. Im also sort of trying to look for it for the whole team. I can handle QA once we get requirements/etc... actually lined out
    – msmith1114
    Commented Aug 9, 2017 at 14:11

1 Answer 1

Reset to default
2

If the five steps that you outlined, when followed, lead to working software on a timeline which your stakeholders find acceptable, then there is no problem. Don't worry whether or not it is "agile" or anything else.

But if there are problems, you should state what they are.

In your question, you seem to state that you have been put in charge of a QA team and so you are trying to start a process for your team. Great. Try something. See if it works. Learn from it. Modify your process to deal with the parts that don't work and keep the parts that do. Over time you will find a path. Don't worry about names and titles.

Improve this answer
2
  • I think the main issue is that QA doesn't work as well if the beginning of the process is struggling. IE not receiving requirements and explicitly marking them off/etc....
    – msmith1114
    Commented Aug 9, 2017 at 14:12
  • 1
    Who knows the requirements? Maybe instead of waiting for them to be provided, go find the person who is most likely to know what they are and ask for them...
    – RibaldEddie
    Commented Aug 9, 2017 at 15:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.