Agile working (none software)

[swillsy]

its slow (more meetings than actual working) and bloated and allows non-IT people to be involved (break) IT projects Works in small teams with accountability fine.

 

[thenewoc]

Well clearly since agile doesn't mean one particular thing, and agile can never fail (you can only fail to agile), it seems to be a somewhat catch-22 situation If you have a problem with agile you just haven't found the agile that works for you

Well anyhow, take my situation.

Before agile we had a config item database, we had incidents, changes and problems (and we still have these).

Now a problem takes as long as it takes to resolve, and often involves going to other teams for their subject matter expertise (and to fix issues beyond our remit).

Now we have agile, and a problem ends up mapped to a single backlog item on a sprint. A sprint being two weeks. The problem is something like, "300 of our laptops have failed to apply Windows update x. Find the cause and resolve."

Now I have two weeks to fix it, or it rolls over to the next sprint. And the next, and the next. Especially because the problem involves emailing suppliers, clients, other teams, and the problem is not even in my hands the whole time. I'm not actively working on it a lot of the time (waiting for replies to emails, work done by other teams).

But I have this backlog item now (=problem) and the record for "most rollovers" in the team. But a problem takes as long as it takes, and can't be squeezed into a two-week sprint.

So what's the point in "making it agile" by turning it into a backlog item on a sprint? What would you do, Scrum Dark Master General Zod?

Escalate and then when everything is escalated, escalate again

Seriously though, can't you split the issue in two,

- requested x from supplier
- implement solution dependent upon supplier details requested

You toggle the first as complete when appropriate and don't start the second until you receive the necessary input. Therefore you have no outstanding tasks since you haven't started the second. If you can't do this or are told you can't then ask why not as it's meant to be an adaptable methodology.

 

[Nutty_Death]

Well clearly since agile doesn't mean one particular thing, and agile can never fail (you can only fail to agile), it seems to be a somewhat catch-22 situation If you have a problem with agile you just haven't found the agile that works for you

Well anyhow, take my situation.

Before agile we had a config item database, we had incidents, changes and problems (and we still have these).

Now a problem takes as long as it takes to resolve, and often involves going to other teams for their subject matter expertise (and to fix issues beyond our remit).

Now we have agile, and a problem ends up mapped to a single backlog item on a sprint. A sprint being two weeks. The problem is something like, "300 of our laptops have failed to apply Windows update x. Find the cause and resolve."

Now I have two weeks to fix it, or it rolls over to the next sprint. And the next, and the next. Especially because the problem involves emailing suppliers, clients, other teams, and the problem is not even in my hands the whole time. I'm not actively working on it a lot of the time (waiting for replies to emails, work done by other teams).

But I have this backlog item now (=problem) and the record for "most rollovers" in the team. But a problem takes as long as it takes, and can't be squeezed into a two-week sprint.

So what's the point in "making it agile" by turning it into a backlog item on a sprint? What would you do, Scrum Dark Master General Zod?

Doesn't sound like using scrum is particularly useful with your example.

Kanban for that type of work could help. Essentialy you have varying tasks which you need to complete, competing for your attention. You visualise these tasks on your kanban board and control how many of them you work on at once as a team (WIP), when you have capacity within your team to do more work then you pull in the next task. So rather than planning what you think you'll do over the next two weeks you constrain your process to only work on a set number of things at a time.

 

[Narj]

Agile is a Cult.

There, I said it.

It's a headache for IT engineering/operations. The amount of man hours we waste every week in meetings is mental. I like to just get stuff done rather than constantly worry about creating and updating PBIs and having retrospectives etc.

It's probably good for development when you can split things into multiple tasks that anyone in the team is capable of doing.

 

[FoxEye]

Escalate and then when everything is escalated, escalate again

Seriously though, can't you split the issue in two,

- requested x from supplier
- implement solution dependent upon supplier details requested

So that's what I've do with my backlog items - break them down into tasks, exactly like you said there.

I could break the backlog item into two backlog items, but then I've got two backlog items in my sprint instead of one? Both of which keep rolling over until the supplier responds or the other team does their bit

Doesn't sound like using scrum is particularly useful with your example.

Kanban for that type of work could help. Essentialy you have varying tasks which you need to complete, competing for your attention. You visualise these tasks on your kanban board and control how many of them you work on at once as a team (WIP), when you have capacity within your team to do more work then you pull in the next task. So rather than planning what you think you'll do over the next two weeks you constrain your process to only work on a set number of things at a time.

We used to use Kanban but now everybody uses DevOps. Everything is a sprint. Everything is a backlog item.

Often I despair watching my backlog items roll over from week to week. It makes me look bad every time it happens. Yet often it's just the nature of the work.

The example I gave being fairly typical of (one aspect of) my job.

 

[thenewoc]

Agile is a Cult.

There, I said it.

It's a headache for IT engineering/operations. The amount of man hours we waste every week in meetings is mental. I like to just get stuff done rather than constantly worry about creating and updating PBIs and having retrospectives etc.

It's probably good for development when you can split things into multiple tasks that anyone in the team is capable of doing.

Glad I'm not the only one that hates it with a passion.

 

[FoxEye]

Glad I'm not the only one that hates it with a passion.

I don't hate it I just don't see that it's brought any benefits (at all) to our team. I can't think of a single thing it's enabled us to do we couldn't before, or helped us in any way become more productive.

We've been trying to be "agile" for about a year, now. Maybe longer.

 

[thenewoc]

So that's what I've do with my backlog items - break them down into tasks, exactly like you said there.

I could break the backlog item into two backlog items, but then I've got two backlog items in my sprint instead of one? Both of which keep rolling over until the supplier responds or the other team does their bit

We used to use Kanban but now everybody uses DevOps. Everything is a sprint. Everything is a backlog item.

Often I despair watching my backlog items roll over from week to week. It makes me look bad every time it happens. Yet often it's just the nature of the work.

The example I gave being fairly typical of (one aspect of) my job.

Surely if you've done the request it becomes something that should be in your suppliers sprint rather than yours. You should also probably create a chase task so it isn't just lost in the ether but as far as the implementation task is concerned it should just be in the unassigned pool until you have what you requested from the supplier. That way your adding visibility / metrics to what has been actioned and what is blocked from being assigned rather than the block(s) counting against the wrong people.

 

[FoxEye]

Surely if you've done the request it becomes something that should be in your suppliers sprint rather than yours. You should also probably create a chase task so it isn't just lost in the ether but as far as the implementation task is concerned it should just be in the unassigned pool until you have what you requested from the supplier. That way your adding visibility / metrics to what has been actioned and what is blocked from being assigned rather than the block(s) counting against the wrong people.

Well it stays in my sprint because the problem (in the config item database - a parallel system) is assigned to me. So the backlog item representing the problem is also assigned to me. Also I've done some work on it, but the matter is unresolved. Some of the work I've done needs to be tested by another team before roll-out, and they don't have capacity currently for anything like that. In the meantime a supplier needs to respond to our request for info (been several weeks of chasing so far and no response, this is not unusual atm due to Covid...)

So the backlog item (=problem) just sits in my sprint and rolls over

I don't know. Just seems we've duplicated the housekeeping and not actually done anything clever or useful, by switching to "agile" and having "sprints" for all our work.

 

[Jimbeam3678]

For me getting into specifics has limited worth for the purpose of this discussion. Kanban, Scrum etc. all ultimately have the same purpose breaking things down small enough to highlight where the inefficiencies, blockers and issues are as a team.

You then, as a team have 2 options either ignore them and accept it will keeping coming back round and they do Or you can look at it together as a team (retro) then come up with some small changes to see if they work for the next iteration. If they do great, if they don't lets try something else.

You generally get out what you put in, as with most things in life.

My advice to anyone who doesn't understand what they are trying to achieve is to ask in a constructive manner as I you can bet you are not the only one.

Impediments world cup might be a good way to start https://retromat.org/en/?id=88

EDIT to OP good topic to discuss on a Friday, thanks for starting it

 

[FoxEye]

For me getting into specifics has limited worth for the purpose of this discussion.

Surely getting into specifics allows you to demonstrate the real-world applicability of agile? (Or otherwise..)

Not being rude, but if people don't want to talk about specifics, how do you demonstrate the worth of agile at all?

"Agile is great and works really well for us, just don't ask me to talk about anything specific." OK!

 

[thenewoc]

Well it stays in my sprint because the problem (in the config item database - a parallel system) is assigned to me. So the backlog item representing the problem is also assigned to me. Also I've done some work on it, but the matter is unresolved. Some of the work I've done needs to be tested by another team before roll-out, and they don't have capacity currently for anything like that. In the meantime a supplier needs to respond to our request for info (been several weeks of chasing so far and no response, this is not unusual atm due to Covid...)

So the backlog item (=problem) just sits in my sprint and rolls over

I don't know. Just seems we've duplicated the housekeeping and not actually done anything clever or useful, by switching to "agile" and having "sprints" for all our work.

I think that's because the 'problem' is too big and needs breaking down. I'm no expert but could you not devise something like a Kanban board with two swim lanes, one for your team/company and another for 3rd parties.

Incoming problem arrives in unassigned on your swim lane, you switch it to a request task and move it to done when appropriate and create a new pending task in the assigned column of the 3rd party swim lane and a new chase task in the unassigned column of your swim lane in chronological order. When you chase you move it to complete with the latest update on progress ETA etc and create a new pending to be assigned chase task. This way you don't accept the deployment part of the task until you have the necessary to do that task. You still have the fragments of the issue in your swim lane but only when they're actually achievable.

 

[Jimbeam3678]

Surely getting into specifics allows you to demonstrate the real-world applicability of agile? (Or otherwise..)

Not being rude, but if people don't want to talk about specifics, how do you demonstrate the worth of agile at all?

"Agile is great and works really well for us, just don't ask me to talk about anything specific." OK!

In my defence I gave a general way how I would go about it and some reasoning. As I said its something to go through with your team and ultimately solve together.

But if you would like me to take a blind stab in the dark you've highlighted 2 areas which I would bring up for discussion. I'd be approaching along the lines of what thenewoc kindly suggested. In addition I'd be asking if we can do anything about the other team's capacity, if not then I would be looking to become more aligned with the other team so when you have done your work they can test and give you prompt feedback so you can adapt your approach if needed while your mind is on it.

Its all fairly high level stuff because its about working together, discussing and coming up with a solution which works for your team.

As I say keep an open mind No truer sentence than in the book 'Drive' Autonomy, Purpose and Mastery is what keeps most people happy & motivated at work.

 

[Guest2]

Yeh, its dump!
We had external people come in years ago and run some presentations and it seemed like (project) management methodology waffle to me. Maybe a way of paying more money to project managers who have no technical understanding of a project they are trying to deliver "i'm agile qualified" ...great

All I could understand was it was supposed to be a more efficient way of working and to deliver things faster (even if they get delivered incorrectly)

In practice that doesnt work as there isnt enough time to properly test and plan. It all comes crumbling down when the service delivered doesnt work.

We just stick to planning in small teams and if its a large project a PM gets involved to bring teams together

 

[Narj]

Yeh, its dump!
We just stick to planning in small teams and if its a large project a PM gets involved to bring teams together

Yeah, getting sprints and tasks aligned between completely different teams is a nightare. Sometimes the sprints are not in sync, or that team doesn't work Agile/DevOps anyway.

It's demotivated me really, drives me nuts.

 

[Guest2]

Yeah, getting sprints and tasks aligned between completely different teams is a nightare. Sometimes the sprints are not in sync, or that team doesn't work Agile/DevOps anyway.

It's demotivated me really, drives me nuts.

I would rather build my technical understanding of a service / technology than some new marketing methodology. Tripe like this is for none technical people who want to get paid more

Everyone at our company luckily has some sense so Agile quickly went down the pan

It might be alright in a software only company, but when that software is being updated on something like a mobile device that will require infrastructure changes.
Things like firewall rules, MDM server changes, load balancers etc. it cannot be done in 2 days. Network security changes often require lead time (e.g. 7 days) and Security teams need to be contacted. It needs to be tested first then have change and test plans after. So no Agile won't work at all

 

[Angilion]

I really hate meetings.

At my old place we would have a ‘Monday Morning Meeting’ where everyone told everyone else what they were doing for that week. This could take us up to lunchtime some weeks.

We’d then have a daily stand-up meeting every morning for the rest of the week to remind everyone what we’d all told each other on Monday…

The amount of hours lost to ******* meetings was ridiculous. Thank god I don’t work there any more.

Here's the best "pointless meetings" story I've heard - a 3 hour drive to attend a 4 hour meeting to tell people about a simple picture that was going to be used in marketing. Dozens of people travelling hours to waste hours on something that could have been done with a single short email.

"Agile" systems are also bad for the environment because of all the trees that have to be cut down to print out the poster-sized buzzword bingo sheets that they spawn

 

[Irish_Tom]

Here's the best "pointless meetings" story I've heard - a 3 hour drive to attend a 4 hour meeting to tell people about a simple picture that was going to be used in marketing. Dozens of people travelling hours to waste hours on something that could have been done with a single short email.

*Picard facepalm*

I think I would have ragequit the company if something like that had happened.

 

[Narj]

"Agile" systems are also bad for the environment because of all the trees that have to be cut down to print out the poster-sized buzzword bingo sheets that they spawn

Don't forget the Post-It notes everywhere. Absoutely. Bloody. Everywhere.

Whoever invented Agile has shares in whoever makes Post-It Notes, I'm sure of it.

 

[D.P.]

So to try and elaborate on my issues, say a task is set, but a problem comes up our 'points' suffer and the boss gets unhappy. Unfortunately there is no way r and d can avoid having issues (although ironically most of it is down to poor management and trying to cut costs on a product). I'm not sure how well it works with physical things. Our team has about 8 people in it, with 5 of is doing a job that the other 3 can't and vise versa. In all honesty it's not vastly different to how we used to work where we got new priorities each week. Now we just have a ridulous amount of meetings.

ehh, that is exactly why you should do Agile. Ylu can't predict what will come up pr how long a task will take with any accuracy, so don't even try.

If you were on a waterfall method ypur whole project timeline would be screwed. With Agile you just re-evaluate as you go, increase the expected work with new tasks and more effort points. If there is a deadline then you reprioritize scope, or increase resources

Sounds like the problem is the boss. If you are using Scrum and ypu don't get the tasks completed by end if sprint, it doesn't matter. No one should be upset.It would a best guess estimate of work to do.