2

I am not the first one to ask this but i also did not get anything concrete from other such posts to tell me what is needed so i am posing the question here. Feel free to refer to some other resource.

My organization is constantly trying to implement the agile methodology as its shiny but we know we have not implemented it properly. We are currently completing a sprint items by saying that they are dev complete. The QA part of the effort is not required to successfully mark the item as completed in the sprint. This means the primary motive of a sprint deliverable is not achieved.

Now knowing that is different from knowing how to get to the ideal world of a structure that supports true agile delivery.

So what i am looking for is all that is needed to implement the structure that can deliver in agile fashion. A book's reference or an online post or whatever you know has worked for you will be helpful as long as its not just theoretical mention of principles but a practical guide of how to implement it.

The basics like implementing automation is what is being worked on. But that still does not cover for at the least a little time when dev has completed developing vs QA has completed testing the deliverable. How can both be completed by the end of the sprint and neither is remaining but still not have a dev sit idle near the end of the sprint while they wait for QA effort or QA starts some QA work after the end of sprint because dev just finished their work.

  • 2
  • 6
    This is all about how your QA organization looks like (which you forgot to tell us). Do you have a separated QA team or QA department? Is this something you want to keep that way, or is your goal to integrate the QA people fully into the dev team? Note both models can be integrated into an agile model, but which one do you think will better fit to your environment? – Doc Brown Oct 29 '18 at 6:46
7

How can both be completed by the end of the sprint and neither is remaining but still not have a dev sit idle near the end of the sprint while they wait for QA effort or QA starts some QA work after the end of sprint because dev just finished their work.

There's really no reason someone can't be idle at the end of the sprint, since scrum optimizes for the team rather than the individual.

That being said, I find it hard to imagine any scenario where this would be possible unless it's the very last sprint of a project. Once the development work is finished, the devs simply need to continue to work with the testers to test the product. Software development under scrum is a team sport. If you have a dev that is unwilling to help test his or her own software, or that of their team mates, they don't belong on a scrum team.

Things devs can do after they think their development work is done:

  • help write automated tests. For example, if using a keyword-based testing tool, they can write the lower level keywords,
  • help the testers with the generation of test data,
  • fix issues with the testability of the code. For example, if building a web app, add missing id attributes as soon as the tester mentions it,
  • work with the product owner on grooming the backlog,
  • optimizing small sections of code,
  • help other devs cross the finish line with their code
  • help write any necessary documentation

Likewise, I can't imagine any scenario where the QA has nothing to do before coding has finished. Here are some of the many things testers could be doing during the first few days of the sprint:

  • working with the product owner to fully understand the acceptance critieria, and collaborating with the dev on how they plan to do that,
  • generating high level test scenarios,
  • gathering test data,
  • making suggestions to the dev on how to make the code easier to test (simple example based on a web application: make sure they add unique ids for every web element you need to interact with),
  • collaborate with the product owner and dev to help refine the high level testing scenarios,
  • start working on the automated tests. With the right testing frameworks it's fairly easy to write automated tests before the software is ready, if you and the developers have been collaborating all along on what elements are on the web page or in the app, how they are identified, etc,
  • reviewing the code that is being written so that you are prepared to test it once it is ready to be tested,
  • working with the product owner on backlog grooming and writing acceptance criteria for the following sprint.
  • Agree with most of this but you may want to be careful about devs doing things like "optimizing small sections of code" don't do anything which requires testing (as that will add to the work of busy team members). It's a question of risk – Liath Oct 30 '18 at 10:01
  • 1
    @Liath: I thought about that when I wrote my comment. With optimization, the code should work as fast after as before, and all of the same tests should still pass. That's why I left the optimization part in, since at least in theory it requires no new tests. Still, you bring up an important point that they shouldn't be adding more work for others near the end of the sprint. – Bryan Oakley Oct 30 '18 at 11:38
3

...But that still does not cover for at the least a little time when dev has completed developing vs QA has completed testing the deliverable...

The key to a sprint is that the team are collaborating all the time. So at the start of the sprint, testers work alongside the developers to understand what they are doing with the first pieces of work, so as to better know how to test. Those pieces of work should be hours-long, not days-long, so that testing starts almost straight away.

As they test, the testers are providing feedback and the developers are then fixing issues found. So the developers haven't finished until testing is finished. There is no "at least a little time when dev has completed" until testing has finished too, unless that testing is finding no issues, in which case the testing serves no purpose.

The problem of testers having nothing to do at the start of a sprint and developers having nothing to do at the end only occurs if each task in the sprint is treated as a mini-waterfall. So don't do that. Instead, treat each task as a collaborative effort between a developer and tester.

  • Sometimes a developer simply does not know how there are going to approach as task so test details can be sketchy as best. Arguably this points to a lack of grooming but it happens quite often. – Robbie Dee Oct 29 '18 at 10:55
  • It does, that's why backlog refinement and planning are so important. Testers can advise on the tests which need to be carried out for each user stories so they're not on the critical path at the end of the sprint when it comes to completing them – Liath Oct 29 '18 at 11:39
1

This is often a bit of a mindset change for a lot of people. The simple answer is that the team is responsible for developing AND testing something in the same sprint, if that's too much work then they need to commit to less functionality.

Imagine work as a grid, each row represents a feature the team wants to implement, each column represents the various traditional stages. Dev, Test, Resolved, Done etc...

In a typically waterfall application the team would do the Development for all the features, then move into Test, Resolved... as I'm sure you know this approach often leads to large amounts of rework and poor communication.

A scrum team should contain all the skill sets to take a piece of a work from plan to Done (Done, should - unless you can argue a REALLY good reason should mean done and in Production with live customers).

So, instead of completing one entire column a team aims to complete a small number of rows at a time. Finishing a few of these each sprint and pushing them into live before starting the next set. There are many, many reasons why this is a good idea which I'll leave out of scope for this answer.

So, now we know that we want to take your small number of features from Ready to Done we can look at your question - how to help your team both develop and test in the same sprint (I also want to include deploy in this).

Firstly, make work visible. If people can see all the work that is required to get these features into Production then you'll stand a much better chance of completing it.

Next, it is the entire team's responsibility to complete the tasks. Testing isn't one person's responsibility, it's the entire team's jobs - sure some people may have more testing expertise but they can assist other team members, they are not the only people who can test.

Changing mindsets/culture is hard, but here are my main suggestions:

  • Take a small number of small tasks and deliver them to live each sprint
  • If developers find themselves with nothing to do don't let them pull in more work, they need to help the testing/deployment process
  • Get testers involved early, use your refinement/planning sessions to identify the tests that should be run. Having tests like this planned out makes it much easier for non-testers to get involved in testing. Encourage developers to automate tests!

TLDR

Encourage the team to deliver to production each sprint, this will naturally balance itself out for people to pick up less work but push it all the way through.

Think of your team members as engineers with different skills. There's no reason developers can't test and testers can't advise on development in progress. Planning the tests to be carried out as part of your Definition of Ready makes it much easier for testers to design tests for other team members to carry out.

I strongly recommend your Definition of Done includes getting something into live and stories are not closed until they are in production. This makes work piling up in test/awaiting deployment extremely visible and encourages frequent releases.

1

Let me suggest a different approach than the ones mentioned already. When QA shall remain a separate team or department, you may consider to work this way:

We are currently completing a sprint items by saying that they are "dev complete"

That is fine, so whenever you have completed your sprint, you have a new release you can deliver to QA. Let's say this release has the version number 5.0. QA will then start testing 5.0 with a focus on the new features from the previous spring. Meanwhile, your devs start developing the next sprint, lets say they aim for 6.0.

Whenever QA finds a serious defect, it is fixed in the "5.x" branch as well as in the current dev branch. This may result in an intermediate release 5.1, 5.2 etc to QA after fixing a set of defects. You will have to plan your sprints to have some time reserved for such bug fixings (but you would need such time also if not your QA people would find the defects, but your devs in the current sprint). Fixing the bugs in two branches instead of one should typically need only a little bit more time than fixing it in the dev branch, since once the root cause for the defect is found, in most cases it will be just fixing the bug once in the dev branch, merge the fix also back into to 5.x branch (using your version control system) and create a new release in the 5.x line automatically.

When QA has ended testing for the 5.x line, the final release can be deployed to production. Note that not every defect found by QA needs to be fixed immediately, it is perfectly possible to put certain issues into the backlog if they have a low impact.

As you see, this model does not require the devs to sit around and wait for QA to complete. If QA completes testing of the 5.x line before the new 6.0 release is ready, I am sure they will be happy to invest the remaining time into test automation, think about new tests to improve the test plan, or work on the documentation or tools. It will allow you to work in sprints, in an agile fashion, for the price of having a "production ready" release with a delay of approximately one sprint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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