Agile working (none software)

[Jimbeam3678]

. 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. 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 . Just out of interest, all you guys that think it works are you mangers.

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.

@theone8181 agile is a framework which is incredibly powerful if done correctly I was going to type a detailed explanation but Nutty death has explained it perfectly. A few things I would add, you mention with R&D problems always crop up, this is one of the reasons the agile framework works so well. You adapt, review, improve and continue.

Also try to keep a growth mindset try to be little better everyday which fits into the agile methodology. Also you don't mention retrospectives which arguably is the most powerful tool Agile offers.

Disclaimer - I'm Product Owner/BA however you want to word it, ultimately I'm not a manager

 

[Rroff]

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.

As always it comes down to quality of management and the tools they have at their disposal - what my criticism is really is companies that try to use these tools to take shortcuts, etc. and/or implemented with idealism without being in touch with the reality of what is going on.

 

[Lopéz]

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 Think we've been "agile" for over a year now. I'm sure somebody is doing something different, somewhere. Right, right?

Then the issue is your company's poor implementation of a methodology, not the methodology itself.

 

[wolfie138]

we've had agile forced on us too, seemingly because it was the latest coolest buzzword to show what an awesome company we are. it's totally unsuitable. i have no doubt agile is great for certain things, but for us it's horrendous and caused nothing but trouble, so much so we call it "fragile".

 

[[FnG]magnolia]

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.

This but ironically which is what I hoped you were going for and then I started weeping for you because even that first sentence has BULL SHIZZLE BINGO written all over it

 

[!bluetonic!]

Basically, it's like a church. You worship in perceivably efficient ways. Sermons, singing, donations tin.

And when this doesn't work out for you, you either change it or set up your own church with more singing and less sermons. Or more congregation interaction and less one-person preaching.

'Agile' by its nature is never wrong. It will be your implementation.

 

[thenewoc]

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.

Sounds like the last place I worked except I also had to endure a project director doing brain storming sessions on improving productivity and what could be done differently when escalating stuff doesn't do Jack. Oh not to mention all the onboarding training including how to spot terrorists, as though anyone has the time to get their normal work done lol.

 

[Nutty_Death]

Basically, it's like a church. You worship in perceivably efficient ways. Sermons, singing, donations tin.

And when this doesn't work out for you, you either change it or set up your own church with more singing and less sermons. Or more congregation interaction and less one-person preaching.

'Agile' by its nature is never wrong. It will be your implementation.

It does feel like that sometimes

There were certainly things I used to come out with that I actually didn't understand but knew that was the expected theoretical thing to say.

It just comes across as theoretical guff.

However a lot of agile issues are just poor implementation, communication/alignment and culture. You can see the distain in several of the posts in this thread, so no wonder it's not working in those environments.

 

[thenewoc]

It does feel like that sometimes

There were certainly things I used to come out with that I actually didn't understand but knew that was the expected theoretical thing to say.

It just comes across as theoretical guff.

However a lot of agile issues are just poor implementation, communication/alignment and culture. You can see the distain in several of the posts in this thread, so no wonder it's not working in those environments.

Nothing a good glass of novichok wouldn't solve for those insisting on using such a defunct methodology.

 

[FoxEye]

I'm a Lead Scrum Master working with other Scrum Masters across 14 teams.

Why did they (intentionally?) have to use such ridiculous names for everything in the agile space?

Project Manager = fine, does what it says on the tin.
Scrum Master = you've got to be kidding me? This just sounds like a joke title.

I'm all for having a bit of fun in the workplace (and we do). But upon hearing a lot of agile terminology for the first time, you can't help but just roll your eyes at it all. I'm not the only one that's for sure. It gives the first impression of being a parody, frankly.

"At the next burn-down, we're going to spike the Scrum Master before time-boxing for some extra story points. We've got to up our Epic velocity!"

Yeah, OK then. You do that. Meantime we'll just be doing our jobs, over here, away from you

 

[Deleted User 298457]

Why did they (intentionally?) have to use such ridiculous names for everything in the agile space?

Project Manager = fine, does what it says on the tin.
Scrum Master = you've got to be kidding me? This just sounds like a joke title.

I'm all for having a bit of fun in the workplace (and we do). But upon hearing a lot of agile terminology for the first time, you can't help but just roll your eyes at it all. I'm not the only one that's for sure. It gives the first impression of being a parody, frankly.

"At the next burn-down, we're going to spike the Scrum Master before time-boxing for some extra story points. We've got to up our Epic velocity!"

Yeah, OK then. You do that. Meantime we'll just be doing our jobs, over here, away from you

You are part of the problem not the solution. It isn't hard to get your head around, it is very well documented. Maybe then you could constructively criticise and add value.

 

[FoxEye]

However a lot of agile issues are just poor implementation, communication/alignment and culture. You can see the distain in several of the posts in this thread, so no wonder it's not working in those environments.

Yeah but that's part of the issue. "You have to believe, brother. You have to want it to work."

I'm sure advocates of homeopathy say the same thing Or faith healing...

And let's face it, many of us have had agile forced on us. We were over-worked to start with, and now we've got even less time in the day to do actual work, thanks to all the extra agile stuff we have to fit in.

 

[thenewoc]

Yeah but that's part of the issue. "You have to believe, brother. You have to want it to work."

I'm sure advocates of homeopathy say the same thing Or faith healing...

And let's face it, many of us have had agile forced on us. We were over-worked to start with, and now we've got even less time in the day to do actual work, thanks to all the extra agile stuff we have to fit in.

And you still can't see how long something is going to take or be done or how far the project has slipped because of the chaotic nature of the ToDo list making and rearranging or that assigning multiple tasks to everyone doesn't mean they're all being worked on in parallel.

 

[D.P.]

And you still can't see how long something is going to take or be done or how far the project has slipped because of the chaotic nature of the ToDo list making and rearranging or that assigning multiple tasks to everyone doesn't mean they're all being worked on in parallel.

doesn't sound like you at all know what Agile is then, thus your opinion is worthless

 

[adolf hamster]

Yeah, OK then. You do that. Meantime we'll just be actioning our deliverables, over here, away from you

translated for you.

You are part of the problem not the solution. It isn't hard to get your head around, it is very well documented. Maybe then you could constructively criticise and add value.

top tier motivation, i like it!

 

[thenewoc]

doesn't sound like you at all know what Agile is then, thus your opinion is worthless

I don't want to know for my work as it's not a process that can be improved and tweaked for the most part, it adds nothing. There's no advantage over using waterfall / gantt chart, since most agile in my experience is not implemented by those that know what they're doing. It's used as an excuse for not hiring people with the right skills for the job let alone agile itself, hence you end up with too many meetings and a few people with technical skills having to manage the chaos. Fine if you don't mind project slippage and in software you can get away with pushing release of features further back but that lack of disciplined milestones and not managing a structured waterfall plan doesn't suit all projects.

 

[D.P.]

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"

Agile is new though, it has been around for a good hundred years in various forms.

while there are plenty of people out there monitizing the recent popularity, the theory snd evidence if the effectiveness spsns many decades.

Fundamentally, Agile is not a system or a methodology, or a framework. Agile is set of principles, largely that empiricism is critical to efficient delivery and that it is impossible to accurately predict complex processes such as an exact prediction of how long a complex software system will take to deliver.

Now there are frameworks like scrum from whuch practitioners can develop their own methodology, but the methodology is not prescribed. By definition, empirical based modification to whatever methodology was implemented is at the core of Agile. So if something is not working out then the fault lied with people and not Agile.


if meeting are not productive then by definition of Agile principles, you should be adjusting the meetings to make sure they are, and that can include not having the meetings at all.


And it is nit like Agile processes have more time spent in meetings than a Waterfall methodology. Instead of spending 6months planning and scooping and then endless meetings during development to figure out whst went wrong and how to fix the major screwup that no one foresaw, or how to manage the fact the project is 5 months behind schedule, etc,. you reduce the up-front planning and Instead iteratively proceed i developing prototype functionality and continuously scope out complexities and upcoming challenges catching them early in the development process before they hsve a big impact. This is a just-in-time planning, which is why meetings are regular. But being regular they csn be focused on th immediate no-problems, not worrying about unimportant details of interoperability of some tiny widget that the developers may or many not integrate in 9 months time snd writing detail spec documents for software that isn't written.

 

[theone8181]

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.

 

[Jimbeam3678]

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.

Have you tried researching the subject ? Scrum.org is as good a place to start as any. Alternatively have you asked whoever is introducing this way of working what they want to achieve with it? I'd be going into it with an open mind and do some research and try to be constructive.

 

[FoxEye]

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?