Agile working (none software)

[D.P.]

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!

Agile isn't a specific methodology though, so there sre no specifics to discuss.

Agile is. aset of well founded principles. Agile means an empirical process , if something isn't working then you adapt. If you don't adapt and keep finding your process is not working then you are not doing Agile so then you can't complain.

 

[D.P.]

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

This is just nonsensical gibberish. Why can't any of those things be done in Agile?

Fact is that is exactly how most Agile software development is done, requiring extensive QA, security audit, DevOp infra changes.

Inknow, because tjat is how i woek in a larhe multinational working on complex software where security is critical, there is a cloud based backend combined with onsite customer hardware.

 

[krooton]

I have seen Prince2 and Agile methodologies try to be implemented at my work, and they both failed miserably because they would only work if everyone followed them, and there are so many moving parts in the company that it just fell flat. The digital agency we use runs in the Agile method, and that works really well, but is limited to the work we send their way.

 

[Guest2]

if something isn't working then you adapt. If you don't adapt and keep finding your process is not working then you are not doing Agile so then you can't complain.

We adapt, if process is not working then process is also adapted. That doesnt mean to say we are working Agile... or does it?

 

[dlockers]

I have seen Prince2 and Agile methodologies try to be implemented at my work, and they both failed miserably because they would only work if everyone followed them, and there are so many moving parts in the company that it just fell flat. The digital agency we use runs in the Agile method, and that works really well, but is limited to the work we send their way.

I mean you have described "PRojects IN Controlled Environments" so maybe the organisation you work in is basically a "jobbing" shop full of inefficiencies and old boys where the task follows the individual.

Would love to cross-reference this thread of people whinging about work with the "whats your morning routine" thread

 

[krooton]

I mean you have described "PRojects IN Controlled Environments" so maybe the organisation you work in is basically a "jobbing" shop full of inefficiencies and old boys where the task follows the individual.

Would love to cross-reference this thread of people whinging about work with the "whats your morning routine" thread

I aint whinging, I like my current free-flow, working to my own schedule way of doing things, and that is why I got out of the Project Management game back in 2014. I prefer doing, analyzing and reporting, rather than what was effectively herding cats

Trying to run a PRINCE project when you are working with a marketing team, a call centre team, and a sales team, who all work very differently, and aren't utilizing any sort of object-orientated ways of working was excruciating.

 

[dowie]

The BS meeting defeats the point of this stuff tbh... you shouldn't be spending two days in meetings every fortnight, scrum, for example, should be a longer meeting between each sprint and like a 15 min meeting each morning max.

I guess part of the problem with this stuff is people try to keep old habits or old roles etc.. like there isn't a BA role in scrum per se, there isn't a dev manager role, there isn't a project manager role or a QA role or various manager roles for some of those - like QA manager etc.. some of those people might want to keep old ways of doing things, keep their old roles etc.. so when an organisation adopts "scrum" instead of getting people to adapt to a new role or just making them redundant because they're no longer needed they'll end up with some half-arsed attempt at it with plenty of additional bottlenecks because some BA wants to carry on being a BA etc.. or some QA guy just wants to do QA stuff or some manager wants to manage some subset of people and really shouldn't even have a role left/should have been made redundant perhaps if there wasn't a role for them to adapt to.

 

[D.P.]

We adapt, if process is not working then process is also adapted. That doesnt mean to say we are working Agile... or does it?

You are following the main Agile principle, so yes.

 

[dlockers]

I aint whinging, I like my current free-flow, working to my own schedule way of doing things, and that is why I got out of the Project Management game back in 2014. I prefer doing, analyzing and reporting, rather than what was effectively herding cats

Trying to run a PRINCE project when you are working with a marketing team, a call centre team, and a sales team, who all work very differently, and aren't utilizing any sort of object-orientated ways of working was excruciating.

Marketing and sales should only be working in an agile way. They'd be fools to be planning a sales campaign and not be analyzing and refining the approach, performing A/B testing on different segments and methodologies... nothing brute force an ignorance about sales or marketing.

Call centres again are prime examples of agile... I mean, each call centre agent has a capacity, demand should be modelled and then sufficient capacity sourced to meet demand within the acceptable KPIs/OLAs/SLAs...?

 

[D.P.]

The BS meeting defeats the point of this stuff tbh... you shouldn't be spending two days in meetings every fortnight, scrum, for example, should be a longer meeting between each sprint and like a 15 min meeting each morning max.

I guess part of the problem with this stuff is people try to keep old habits or old roles etc.. like there isn't a BA role in scrum per se, there isn't a dev manager role, there isn't a project manager role or a QA role or various manager roles for some of those - like QA manager etc.. some of those people might want to keep old ways of doing things, keep their old roles etc.. so when an organisation adopts "scrum" instead of getting people to adapt to a new role or just making them redundant because they're no longer needed they'll end up with some half-arsed attempt at it with plenty of additional bottlenecks because some BA wants to carry on being a BA etc.. or some QA guy just wants to do QA stuff or some manager wants to manage some subset of people and really shouldn't even have a role left/should have been made redundant perhaps if there wasn't a role for them to adapt to.

This is a common problem when people adopt something like Scrum but implement their own hybrid approach with hhe same people in the same roles.

However, I wouldn't say all these roles are redundant. Scrum defines specific roles but does not prohibit anyone else. You still need project managers and product managers, BAs, QA is as critical as ever etc. But the way of working needs adpating. QA has to be a continuous process testing every new release or even each merge. The BA needs to work closely with the PO and attend project demos. Their responsibilities also change,the project manager handles more HR related issues and more holistic aspects of the team.

 

[skyripper]

This thread has been eye-opening. We "adopted agile" a few years back in a traditionally waterfall technology and we're facing all the same issues as everyone else I'm so glad we're no more crap at this than others!

 

[R.P.L]

All sounds like a ball ache to me

 

[krooton]

Marketing and sales should only be working in an agile way. They'd be fools to be planning a sales campaign and not be analyzing and refining the approach, performing A/B testing on different segments and methodologies... nothing brute force an ignorance about sales or marketing.

Call centres again are prime examples of agile... I mean, each call centre agent has a capacity, demand should be modelled and then sufficient capacity sourced to meet demand within the acceptable KPIs/OLAs/SLAs...?

They do their own things is what I mean, the call centre has it's resource management process, the sales team do their thing (they aren't that hot on analysis and reporting, I've had to build a few Power BI reports for them), I just mean the business isn't using a single unified way of doing things, so when cross-departmental collaboration is required, it can get messy.

I just do all the QA, A/B testing, modelling, segmentation and such myself for our Direct Marketing channel, the other departments just aren't as evolved, and I'm not going to dumb down my processes in a race to the bottom

 

[dowie]

This is a common problem when people adopt something like Scrum but implement their own hybrid approach with hhe same people in the same roles.

However, I wouldn't say all these roles are redundant. Scrum defines specific roles but does not prohibit anyone else. You still need project managers and product managers, BAs, QA is as critical as ever etc. But the way of working needs adpating. QA has to be a continuous process testing every new release or even each merge. The BA needs to work closely with the PO and attend project demos. Their responsibilities also change,the project manager handles more HR related issues and more holistic aspects of the team.

Well that is a hybrid approach and makes things less "agile", creates bottlenecks - I guess you could have a separate QA team (that is also arguably a bottleneck but perhaps needed in some cases) just as you have separate dev teams for particular products or parts of products - but there are QA an BA aspects within the dev team and really they should be self organised, there might be varying skill sets but if people want to silo themselves and only do certain tasks then that is a less agile approach, really everyone should be responsible for some BA work and everyone should be responsible for QA within the team... there are no separate roles there, just a development team - you can't just have one QA or BA guy sitting around being like "hey guys, let me know if you need me for anything". There is no role for a project manager at all within scrum - they can perhaps become a scrum master (as could a BA), likewise they or a senior BA might become a product owner (ditto to a dev manager).

If an organisation tries to embrace "agile" and transition into some new process but a bunch of people want to hang onto and still perform their old roles, which might not even exist in this new way of doing things then you're going to get a hybrid solution and things could get messy - I reckon a lot of companies do end up with some hybrid way of doing things - I mean arguably the dev team ought to be self organising w.r.t. tasks but realistically if you're defending roles and saying one person should work with this other role outside the team etc.. and one person should mostly focus on this etc.. then it isn't anymore.

I'm not saying scrum is best or waterfall is best but perhaps some things fail when people don't even embrace them in the first place and start off with preconceived notions of previous roles and keep working as though they're in those roles while going through the motions of meetings, sprints... that only adds to bottle necks and extra faff tbh...

 

[Kenai]

It's interesting to note that despite the topic of the thread being the use of 'Agile' in non software environments, a lot of the pro Agile comments seem to circle back to referencing software development.

Is anyone actually using it successfully in an environment outside of software development? I'd be interested to read about it being used effectively in other environments, as most stuff online is also fairly software focussed and there's not much out there about it's use in other environments in practical terms.

 

[krooton]

It's interesting to note that despite the topic of the thread being the use of 'Agile' in non software environments, a lot of the pro Agile comments seem to circle back to referencing software development.

Is anyone actually using it successfully in an environment outside of software development? I'd be interested to read about it being used effectively in other environments, as most stuff online is also fairly software focussed and there's not much out there about it's use in other environments in practical terms.

Which is why I chucked in my tuppence (software development is pretty much the only function not done in our UK office, that is for Global IT to deal with).

 

[Guest2]

You are following the main Agile principle, so yes.

If something isnt working, then fix it. It's not 'Agile' because of this

However if Agile is to just fix things including process if it doesnt work then that's always been around. It's just called fixing things

 

[theone8181]

It's interesting to note that despite the topic of the thread being the use of 'Agile' in non software environments, a lot of the pro Agile comments seem to circle back to referencing software development.

Is anyone actually using it successfully in an environment outside of software development? I'd be interested to read about it being used effectively in other environments, as most stuff online is also fairly software focussed and there's not much out there about it's use in other environments in practical terms.

That was the general feeling I got. When we first started agile (bearing on mind were only on our 5th sprint) one of the things the boss mentioned was that it's mainly done for software, which was a massive red flag to me. Also the boss loves to micro manage, so a few times we've agreed on work for the sprint, then extra work gets shoved in, with a stupid deadline. For instance we needed to do about 3 weeks work testing a product, but due to meetings and removal and rushing, I think it got about 3 days work on it, then the customer complained it had problems. I'm opened minded about it but I know my boss won't leave stuff alone.

 

[dowie]

That was the general feeling I got. When we first started agile (bearing on mind were only on our 5th sprint) one of the things the boss mentioned was that it's mainly done for software, which was a massive red flag to me. Also the boss loves to micro manage, so a few times we've agreed on work for the sprint, then extra work gets shoved in, with a stupid deadline. For instance we needed to do about 3 weeks work testing a product, but due to meetings and removal and rushing, I think it got about 3 days work on it, then the customer complained it had problems. I'm opened minded about it but I know my boss won't leave stuff alone.

So I guess your boss has introduced a process then undermined it anyway - is he supposed to be the "product owner" in this scenario?

 

[tom01]

Out of interest, what is everyone's industry or at least role that has adopted Agile? We have just recently started this and I must admit I have never heard of anyone outside of the developer community using it? So it's really interesting that engineering and now operations teams are starting to take this on. I'm still on the fence as to whether I think it is correct for my specific industry, however as someone else said man it is a lot of meetings and what feels like an endless amount of admin! I quite like just getting on with stuff as others have said, however now we must generate user stories for each action and save it for the next sprint which at times doesn't feel very flexible or productive.