Agile working (none software)

Soldato
Joined
27 Mar 2013
Posts
9,409
Hi guys, we've recently had this forced on us at work, but it seems now we just end up having roughly 2 days of meeting a fortnight and don't get any more work done (we actually get less done as it's a practical job and the meetings are at our desks via teams). Has anyone used this and it worked well? I suspect there will be a different in opinions between mangers and works (I'm a worker not a manager). It seems like a mega inefficient way of working.
 
I can only speak as a manager in an IT end-user support business unit, but we've had a strong focus on delivering value to the the business using the standard SCUM methodology over the past 2-3 years and we've hugely benefited from it.

Providing your setup supports Agile delivery, for example with a Product Manager/Owner, Scrum Master/Squad Lead and an Organisational Lead and a strong Product Team (you 'the worker') of sorts, regardless of how you name or organise the roles, you'll certainly feel the rewards, but it doesn't happen overnight.

Remembering that the PM/PO defines the WHAT and the WHY and the Product Team defines the HOW and WHEN, get that kick started and you'll be off and running.

Becoming truely Agile takes several years and you'll likely never stop refining that journey.
 
While the meetings might not seem efficient at the start, they will ensure that the product will remain on track, that work is focused on delivering value, problems are discovered earlier.

Important to time-box the meetings, and also have a strict agenda. The scrum master or PO should make sure the meetings are focussed and on track. Heck, if a meeting is not being productive they should probably cancel the meeting.
 
It's never been successful where ever I've worked. Total sham of a system compared to conventional waterfall methodology. Glorified To Do list egits who can't project manage properly in my experience. I wish someone would burn the whole Agile system since it never needed inventing in the first place.

Software development is actually one of the few areas that I think it kinda works but only if your end goal isn't critical that you ship xyz feature by a deadline.
 
Last edited:
It works for us.

Small team, lots of itty bitty system and IT changes.

Efficient meetings.

Visibility of work.

Constant review, refinement and improvements in our process.
 
Heck, if a meeting is not being productive they should probably cancel the meeting.

It sounds like that's the issue.

One day of meeting a week is overkill unless you've got serious issues or you're in initiation, in my opinion.

Short daily meetings to check progress and identify issues would be better.
 
The agile scrum way of working is a fantastic system when done properly! (if I ever look for other jobs, I will be 100% only going to another company who use the same system).

We use it throughout our place (sprints, quick daily stand-ups each morning etc.) and benefit massively in every way possible. It's nice being able to have the people who take ownership of PBIs being able to estimate how long an item should take them and being left to just get on with the work rather than having a PM who has no clue on the particular work item setting unrealistic ETAs or/and trying to scope out the work/tasks.....

Does largely come down to having a great PM/scrum master though who knows what they are doing and knows when to step in to escalate issues or if people aren't pulling their weight etc.
 
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… :rolleyes:

The amount of hours lost to ******* meetings was ridiculous. Thank god I don’t work there any more.
 
Maybe it works when everybody knows what it even means.

I can say from experience that, after deciding we're "going to shift to agile working," that what we observed was: 500% increase in buzzword bingo ("today we're going to slipstream under the glass highway with a rubber duck process flow"), lots of new daily recurring meetings, and an expectation that the word "agile" will feature in every communication and conversation.

What does it mean? Still have no idea, frankly :p Think we've been "agile" for over a year now. I'm sure somebody is doing something different, somewhere. Right, right?
 
what we observed was: 500% increase in buzzword bingo

i did think there was a bit too much acronym spam going on in this thread.

tbh i reckon a lot of these new fangled systems are just the same old fashioned systems with some fancy make-up slapped on so consultants can justify the amount they're charging for a copy-paste "solution"
 
OP, share the Teams link with us and we can listen in.
:D. We have a 30 minute scrum every morning, and every fortnight we have the product demo which lasts a couple of hours, the the retrospective which lasts a couple of hours, a planning session which lasts a couple of hours and now we have to have a pre demo meeting to discuss what's going on in the demo:rolleyes:. It seems to me management has palmed off all the work of managing onto the workers. For reference my job is probably quite different to most of you as its in R and D in developing fricking lasers. Unfortunately agile doesn't work with r and d as problems crop up (nature of r and d), which means all the times get thrown out the window. I believe it's been brought in to give a score to everything. The system as it stands seems to benefit people grossly overestimated they're score, 1 manager was boasting he had the most point, I then found out one of his guys managed 84 points in a fortnight :rolleyes:. Just out of interest, all you guys that think it works are you mangers:p.
 
It seems to me management has palmed off all the work of managing onto the workers.

Even with the best manager in the world a framework is a good idea but I always get a feeling a lot of these approaches are a crutch for poor management and/or cheaping out on good managers.

EDIT: I can sometimes identify when such a system is in use when a company is continuing down a pre-set path when everyone else can tell the situation has changed and/or it isn't working and it can take a lot longer to turn the boat around (which is ironic for something named agile) even with the whole concept of sprint and reassessment.
 
Ok trying not to use too many buzzwords.

Scrum is meant to be an empirical process, by that I mean you make a change, observe how it went and then decide what to do next. This is both in the thing you're producing, where you get feedback from your customer to help inform what the next change is, from you the team where you learn more about the thing you're making. It's also in the processes you follow in how you work together and the changes that you make to make those working practices more effective.

The scrum meetings (events) are where you re-evaluate and plan based on new insight from above, coordinate how you'll work together as a team or review the thing you've made or how you worked together to make it, so you can work out what to do next.

Often a failure for people attempting scrum is a misunderstanding that agile means no planning. This isn't true, it's just that you accept there are things you don't know yet, so any plan you produce will need to be continuously reviewed and adapted based on what you learn as you go.

I'm a Lead Scrum Master working with other Scrum Masters across 14 teams.
 
:D. We have a 30 minute scrum every morning, and every fortnight we have the product demo which lasts a couple of hours, the the retrospective which lasts a couple of hours, a planning session which lasts a couple of hours and now we have to have a pre demo meeting to discuss what's going on in the demo:rolleyes:. It seems to me management has palmed off all the work of managing onto the workers. For reference my job is probably quite different to most of you as its in R and D in developing fricking lasers. Unfortunately agile doesn't work with r and d as problems crop up (nature of r and d), which means all the times get thrown out the window. I believe it's been brought in to give a score to everything. The system as it stands seems to benefit people grossly overestimated they're score, 1 manager was boasting he had the most point, I then found out one of his guys managed 84 points in a fortnight :rolleyes:. Just out of interest, all you guys that think it works are you mangers:p.

A couple if things. Scrum is just one practice you can follow when working in an agile way.
A basic assumption in scrum is that you can predict what your sprint (set period of time) looks like.
If you can't due to the nature of your work then Kanban might be a more suitable alternative, as this is about efficiently managing the flow of work through your system and pulling the next task from a prioritised backlog.

Regarding your comment about palming off.
Generally the idea is that the people involved in doing the work are in the best position to decide how it should be done.
Buzzwords. The gives the people who do the work autonomy to make decisions as the assumption is they're capable of doing this. Requiring someone outside the group that does the work to make decisions creates a dependency on them. These outside people are usually involved with many other groups and therefore become a bottleneck and don't actually have the same insight as the people that did the work.

Finally tracking points (velocity) and comparing them across teams is pointless. As you suggested, this can be gamed and the points aren't comparable due to different team structures or what a point means in terms of effort to that team.
 
Even with the best manager in the world a framework is a good idea but I always get a feeling a lot of these approaches are a crutch for poor management and/or cheaping out on good managers.

EDIT: I can sometimes identify when such a system is in use when a company is continuing down a pre-set path when everyone else can tell the situation has changed and/or it isn't working and it can take a lot longer to turn the boat around (which is ironic for something named agile) even with the whole concept of sprint and reassessment.

Often in poor implementation of agile ways of working there's a lack of transparency.

For example if a big project with many teams was delivering something. There needs to be transparency around how those teams are progressing and how they're forecasting, so that you can react to this insight and adjust your plans (remember all plans are based on assumptions). For me this is being agile.

Often however it's just chaos with a lack of transparency and insight, for you to revaluate with. This isn't agile, it's just chaos.
 
Back
Top Bottom