Are we doing agile?

(Faith Roberts) #1

I was hoping someone could help me wrap my head around agile…

I have worked in an agile environment in a previous company and I thought it was alright, nothing really to rave about and nothing to complain about either.

However, in my current company they recently introduced - recently, meaning February this year.

I hate it.

We run a two-week sprint. In that, we have daily stand ups, 2 hour sprint planning, 2 hour sprint retrospective, 2 x 1 hour sprint reviews (one to stakeholders, and then one to the rest of the company), and 3 x 1 hour backlog refinement meetings.

I spend most of my time in meetings talking about how we are going develop/test X, Y and Z, and barely any time actually doing the work. However, our project manager - who is also our scrum master and pretty much product owner - still expects us to produce the same volume of work as before.

This is a headache but I could probably still bear it.

What I cannot bear though is the fact testing just isn’t accounted for. I am still being expected to regression test within one day, which is something that has always taken me three days. I’m not a slow worker, but the nature as to why the regression is so large and long-winded is beyond scope of this chat and warrants its own rant.

I’m on day 17 of the sprint doing regression while the programmers are on day 3 of the next sprint, doing programming work. I raised a high priority regression bug but apparently no one is able to come off sprint work to fix this sprint and they decided to revert the entire epic that was being blocked.

Surely I am not the only one that thinks this is a bonkers way of working and totally defeats the purpose of agile?

(Kate) #2

They aren’t doing agile. They’re doing agile-but or scrummerfall or agilefall (even agile-fail) - you’re effectively being thrown a 2 week window with extra meetings and expected to do the waterfally thing inside it.

Some of the bigger problems I can see:

  1. Your project manager should NOT also be scrum master and product owner. That they are means that all three roles are getting short-changed. The most important part of a scrum master’s role is getting impediments and blocks out of the way. When the product owner’s insistence on doing something is an impediment and the product owner is also the scrum master, that block is not going away.
  2. Part of the art of managing this is leaving enough of a buffer to allow for things like critical regression bugs to be handled in-sprint. At my current employment this typically means that we commit to between 70 & 80% capacity because we know enough bombs (unplanned essential work) will land to soak up the buffer.
  3. Critical work uncovered late in the sprint is something my team by mutual agreement drops into the next sprint before normal planning starts. We may not be working by a “pure” agile method, but since we also act as second/third-line helpdesk and can be pulled into an all hands critical emergency at any time, we do have times when it’s necessary to slip work that got derailed into the next sprint. If we get a series of bombs, we could slip work several sprints before we get it done.
  4. Identify front-load vs back-load items: as a general rule, items that need more testing or are very public facing happen early in the sprint to keep my workload a bit less clumpy. This means I’m often doing mini-regression around parts of the application from day 3 or 4.
  5. There is no “I am on day 17 doing regression while the programmers are on day 3 of the next sprint’s programming” - if the testing is that backed up and the programmers have no current-sprint work, they help test, just as in the early parts of the sprint, the tester digs into the user stories, plans their test commitments for the sprint, and asks those interesting, awkward questions that force features to be redesigned.

Doing this kind of thing has helped the team where I work (and I’m the only tester in the team and the organization) - some of the suggestions may be valuable to you.

(João Farias) #3

I would argue that one doesn’t “do agile”, but “is agile”. Therefore, the phrase “they recently introduced” is a good sign that something is not happening organically - people are just being told to follow process X or Y.

Nonetheless, I like to go back to the Manifesto itself:

About the critical bug, it seems that the first iteration work package cannot be considered working software because it was delivered in a way that do not satisfy the customer.

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

Additionally, the simple fact that you are doing regression after iteration means that the result of the iteration is not working software, because no one show this as such.

About the endless meetings, it seems that focus are not on the right place:

Working software is the primary measure of progress.

About the regular “rest of the company review”, it can be a symptom that the stakeholders are trapped in some contract / process which is not focused on helping the team to better work towards the needs of the customer, but to have the buy-in another set of stakeholders.

Customer collaboration over contract negotiation

Business people and developers must work together daily throughout the project.

When people suddenly start “doing agile” this kind of problems often arise. I think you have to evaluate how you can better implement the last agile principle:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

If Continuous Improvement start getting traction, the problems can be slowly address and people can better understand how they can contribute to the main goal: Helping the customer.

Tip: About the endless meeting, I like to track the total amount of time spent and ask the manager to calculate the amount of salary payed for meetings. Show that 10-15 people hourly salary * 2 is spent in a “sprint review” to the rest of the company can make your manager rethink if this is really worth it.

(Lisa) #4

My favorite definition of agile is Elisabeth Hendrickson’s “Agile acid test”. A team is agile if it is delivering value to customers frequently, at a sustainable pace. “Sustainable pace” encapsulates all the good technical practices that we know helps a team deliver value frequently without killing themselves and getting mired in technical debt.

Your team is doing mini-waterfall. If I were you, I would make testing a team problem. The whole team has to first decide what level of quality they will really commit to - knowing they will have a lot of problems to overcome to deliver that level of quality. Then they have to take responsibility for planning all the activities that will eventually achieve that level of quality. For my teams, that has required practices such as test-driven development, acceptance test-driven development, and team “rules” we made ourselves such as: Focus on finishing one story at a time (that means non-testers take on testing activities when needed, Deliver a story ready for final testing by the end of the 2nd day of the sprint.

I know that’s all easy to say and hard to do, but I have not seen teams be happy and able to deliver value frequently any other way.

(Robert) #5

If you are on Day 17 of a sprint when the devs are on Day 3 of the next sprint, then that means that effectively your sprints operate on a different cycle - what Kate accurately and excellently described as “scrummerfall”. If that’s the way the company wants to do things, they are welcome to - after all, in my experience, Agile seems to be a menu that different organisations implement in their own ways - but the company has to accept the baggage that comes with that. In this case, it means that your management have to accept that you are one sprint behind the devs; whilst the devs have to build bug rectification time for your sprint into theirs. This in turn means that you have to have an agreed means of bug triage so that the urgent bugs can have priority for attention during the rectification time, and there will have to be an agreed process whereby less urgent bugs get deferred to a rectification dev sprint at an appropriate point.

This isn’t ideal, but we made this work in a previous role that I had working with a comparatively uncommunicative remote dev team. But the managers recognised the problem and we were all determined to find ways to try to make it work better. (And it was actually better than what had gone before.) Getting your manager to accept the problem is probably going to be the most uphill part of sorting this, by the sounds of it.

(Faith Roberts) #6

we commit to between 70 & 80% capacity

What do you do when the programmers run out of work in that current sprint?
I have made that point myself in sprint planning and in the sprint retro they complained they ran out of work and now we are at full capacity, and about 120% for me.

1 Like
(Faith Roberts) #7

I like your idea about calculating how much money is spent on meetings. I’m going to calculate mine, which I’m sure will be an eye opening amount.

people are just being told to follow process X or Y.

This is exactly what is happening. That process is constantly changing though to the point where every one of us has our own idea of what the current process is

(Ileana) #8

thay have to take some work out of the backlog

(Faith Roberts) #9

If they are taking work out of the backlog, thus adding to the sprint, that then leaves more for me to regression test, doesn’t it?

It’s a large, complicated system, and takes days to regression test. Although, we can be smarter with regression testing, that’s still something that we are trying to sort…

(Ileana) #10

In my case what we do is, have devs pull out sth out of the backlog but they don’t upload it for me to test until we are in the following sprint. Otherwise I would never finish my regression testing for the corresponsing sprint.

(Robert) #11

If any of this is at all Agile, it sounds as though it’s more by accident than design.

1 Like
(Kate) #12

If the programmers run out of work, they have several options: they can follow one of the many training courses they have available to watch, they can catch up on other projects they may be involved with, they can pull new work into the sprint (as long as it doesn’t overload the tester since I am the test team), they can go through the system and find documentation in need of updates, or they can pick up on some of the testing that’s not been done yet.

It’s the same situation as when I find myself in a holding pattern early in a sprint: I can update documentation, work on other projects, work on a training course, plan tests for the more complicated stories…

If programmers are complaining they’re out of work and the tester/s are overloaded, the programmers should test. If testers are out of work and the programmers are overloaded, the testers should pick up work - coding if they’re up to it, other programmer work like documentation updates, machine setups, etc. That’s the whole point of a multi-functional team. Everyone has things they’re best at, but they pick up enough skills to handle general work.

1 Like
(Kate) #13

This is exactly what is happening. That process is constantly changing though to the point where every one of us has our own idea of what the current process is

Been there… It’s not pleasant. Aside from looking for a better work environment your options are pretty limited.

You can try to work with your devs to get a sane work process that isn’t overloading you at the end of a sprint.

You can also try to work with your devs to get a reasonable amount of automated testing into your application, preferably starting with unit tests that run each build. Depending on how old the system is and how much spaghetti code is in it, unit tests could be impossible, but you could also work with your devs to get enough basic UI regression in and running on a regular basis that you aren’t trying to regression test everything manually. It will be ugly at first, but refactoring and adding to it can then be something the devs do while you’re running your manual tests - if you can get their cooperation.

You can negotiate with your product owner/project manager/scrum master person to run the regression testing on a plus-one cadence where your first 3 days after the end of sprint are your regression test days - on the understanding that regression bugs go into the sprint and soak up some of that 20 - 30% buffer your team is building into the sprint.

The other main option I can see is to prioritize the regression tests based on what’s been covered in the sprint, and not stress yourself (because you’ll burn out if you try to keep doing it all). At the end of sprint, you report on what you covered, what you didn’t cover, why you didn’t cover certain things, and what you see as the risk of you not covering those things.

In my experience it can take months - or even well over a year - but eventually someone gets a clue that they need to change how things are done if they want to keep things going well.

Another suggestion worth considering when you report bugs is whenever you can note which customers will be most affected. It may not help you much at the time, but when an irate customer is blasting someone over that very bug, you can point to it and note that it wasn’t prioritized due to other work in progress. My experience is that being able to do this helps managers work out that they need to change their practices.

(Faith Roberts) #14

I feel like I’m already at the stage of burnout. I do cut down the regression where I can if there are areas that definitely haven’t been changed.

I actually sent this thread to one of my programmers at work who found it interesting. We then discussed afterwards what it is I feel I need to make things work better.

Most of it all comes back to poor management and our hands are tied.

I guess I’ll just have to see how it goes and keep raising things as and when I can.

(Faith Roberts) #15

Sounds like it doesn’t it!

(Kate) #16

I sympathize. I’ve been there, and it’s not pleasant. I do hope you and your programmers can work out something that will help you and them.

In my experience most problems like this come down to management issues. I don’t know enough about your specific situation to say whether your management is generally-good-but-misguided or outright incompetent (or anywhere in between), but sadly, until they figure things out, you and your devs will be picking up the slack for it. Such is life…

The best thing you can do in a situation like this is to try to pull back enough that you’re not driving yourself insane, do what you can with what you have, and keep feelers out for a better position.

Good luck.

1 Like
(Faith Roberts) #17

Thank you for your time and effort in providing your responses. I really appreciate it :slightly_smiling_face:

(Lene) #18

A few thoughts off the top of my head (and they are very general as I don’t know all the details):
This is not agile.
You are following a scrum procedure, but you are not doing the work agile.

First point of the agile manifesto: Individuals and interactions over processes and tools
You are focusing on the process.

If someone in the team has moved on, and you have not, it does not really sound like you are a team.

It sounds like you are spending a bit too much time in “meetings”. Backlog maintenance should be done as part of the teams day to day work, so skip that as meetings. For a 14 day sprint I would not spend more than 1 hour on planning. And 2 x review, if the whole team is joining in, is also a bit much (can it be done 1 time?). Could you maybe have 21 days or 28 days sprint with that amount of meetings?

The work planned into a sprint must fit the sprint length, so either plan less work or extend the sprint. Also work should be broken down in such a ways so that it can be shipable within the sprint, i.e. including testing, documentation etc. Small chuncs of coding + testing, and repeat.

And another point; it takes a long time to “get it working”. The team will loose speed if it is changed (process, +resource, -resource) for as much as 4 sprints. So less work for a period may help the team “get scrum working”.

1 Like
(John) #19

If the regression tests are taking 3 days to work through I’m assuming these are manual tests? I’d look to plan in some time to get the developers working on building out the automation towards the end of the sprint to reduce the time taken to do this?

(Alexander Dunn) #20

“I have made that point myself in sprint planning and in the sprint retro they complained they ran out of work and now we are at full capacity, and about 120% for me.”

In scrum, there are no Dev and test roles. The point is for the team to commit to delivery of a certain amount of work over the sprint. Devs should be completing test tasks and only when ALL testing is clearly being completed within the sprint should they look to bring in additional work.

If the team has not completed everything, the whole team is responsible. In this case you should probably be identifying the key testables early in the sprint and prioritizing what you (the most skilled tester) should be testing, and what you can leave as tasks for the others to pick up.

1 Like