Agile working (none software)

Pants said:
To be fair I thought it was quite clear that dowie is saying if you are using SCRUM properly then you are agile. Of course if you are not using it properly (or any other agile framework properly) then you might not be agile.
Click to expand...

I'd argue it's the other way around. You can't do SCRUM properly unless you're agile in your values and behaviours. The values and behaviours need to come first, you can't expect SCRUM to do that for you.

Those values and behaviours also need to be organisational, not just for a department or two.
 
Another bug bear of mine is the ninjas, I. E. The continuous improvement cult. They sit there and analyse a problem using "science" and then "prove" why its at fault. Invariably that fault was already known about and invariably the solution
requires ITdevelopment.

CI go speak to It about a solution. It say yes we know about that as we had a BA look at it 5 years ago. The cost then was 20k to fix now its 40k would you like a solution?

Business says no we
can't afford it. So CI come to speak to someone like me who works in shadow IT within the business. Yes we can come up with a solution but it won't be optimal and can't be integrated with Corp IT. Solution is implemented by us, CI get credit for improving the business... 5 years latet CI find a problem again, they speak to IT this time it will cost 80k... Etc.

It's madness just a gravy tain to keep non technical middle class people in a job
 
dazzerd said:
Another bug bear of mine is the ninjas, I. E. The continuous improvement cult. They sit there and analyse a problem using "science" and then "prove" why its at fault. Invariably that fault was already known about and invariably the solution
requires ITdevelopment.

CI go speak to It about a solution. It say yes we know about that as we had a BA look at it 5 years ago. The cost then was 20k to fix now its 40k would you like a solution?

Business says no we
can't afford it. So CI come to speak to someone like me who works in shadow IT within the business. Yes we can come up with a solution but it won't be optimal and can't be integrated with Corp IT. Solution is implemented by us, CI get credit for improving the business... 5 years latet CI find a problem again, they speak to IT this time it will cost 80k... Etc.

It's madness just a gravy tain to keep non technical middle class people in a job
Click to expand...
If only IT were aligned with Business Strategy then shadow IT wouldn't exist :p
 
dLockers said:
If only IT were aligned with Business Strategy then shadow IT wouldn't exist :p
Click to expand...
I think thats a good point. The problem for me and the last company I worked for is that the business as a whole were terrified of creating bespoke solutions the the problems which are encountered day to day. So they play it safe a but a configurable off the shelf solution and pay for 3rd party support. That system works well for the core processes which the business need to run. But is poor or obsolete very quickly to the ever changing needs of the customer and operational teams. Hence shadow IT exists and CI live on forever higlighting problems we have forgot about!
 
My head hurts with all the buzzwords. Ive worked in tech my entire career in different capacities and still cant understand what an agile mindset/story/ceremony is.

I shall ask my PM tomorrow if we use ‘agile’.

As it stands, myself(MD) and sales team in collaboration with dev spec projects fully and extensively start to finish, agree timescales internally before sign off from customer.

Work is allocated by PM to individual members of dev/design/marketing, goes into ‘sprints’, managed via kanbans within Asana. The team have a 10 min max standup every morning to ensure things are on track(projects typically run simultaneously including smaller helpdesk/feature requests thrown in from existing customer base). Work is carried out to internal deadlines and testing phases. Continual rotation of work and fast paced.

I dont know what label you’d put on it but its simple and effective for me. The daily stand ups highlight blockers or delays allowing myself to communicate with third parties or manage expectations should issues arise.

edit; work is also tracked to the minute automatically via browser add on, every task making up a project or retainer giving me data to quote/allocate time effectively. Invaluable data.
 
Thankfully I'm in a business where over-enthusiastic PMs, internal consultants, and continuous improvement people get politely ignored and sidelined while the real professionals like engineers and accountants get on with it.
 
Participant said:
Thankfully I'm in a business where over-enthusiastic PMs, internal consultants, and continuous improvement people get politely ignored and sidelined while the real professionals like engineers and accountants get on with it.
Click to expand...
I envy you:p. It was the start of our sprint when I got set those tasks, the problem is most of them were assigned to me without me saying yes which is the complete opposite of what we were told initially. What you guys have got to remember is that as its not it, we can't all do each others jobs (generalising here, but in it if it's software related I'd say the whole team should be interchangeable, assuming same language). With our job being physical and a different set of skills that's just not possible.
 
theone8181 said:
So for my next sprint (which is really only about 8.5 days of work), I've been given about 40 points:rolleyes:. Thats why it doesn't work for us, **** poor management.
Click to expand...

That isn't Agile though.

You should never be assigned more work than what the historic team velocity and schedule of the sprint looks like (e.g. account for holiday weekends etc.).

Where possible, no one should be assigned work specifically as it is a team commitment. In reality the team may well have specialists so this doesn't always make sense
 
Nutty_Death said:
Yeah, you don't get assigned points/ stories in scrum.
The sprint plan is a team commitment based on prior velocities and refinement of the stories by the team.
It doesn't make sense to pre assign a ticket because you should work collectively as a team to achieve your sprint goal.

Sounds like a sprint of people just working in silo against a plan they didn't agree to.
Click to expand...


The problem here is that assuming everyone has equal expertise which only happens on vthe simplest of projects.

For more complex work you have specialists that hsve specific and non-transferable skills, so tasks have to be assigned.

As an example, in an old project we had a couple of machine learning experts with PhDs/PostDocs, 10-15 years experience and earn 200k per year, video compression expect with PhD, embedded systems expert who would hook the hardware up to an oscilloscope etc, UX designers, web UI developers, IOS developer, an external translation team, middleare software developers, QA and a couple of interns


You don't get an intern who dropped out of college to éead the deep-learning development any more than ypu get the embedded systems guy with a soldering iron in his hand to to the UX workflow.


Task assignment is fine. But the important part is that it is a team commitment, with everyone helping where possible and the total sprint workload is set by the actual engineers and not the Boss or manger, not even the Product owner. The Po just helps priorities from a bussiness perspective and hell the team understand where the product development should focus. The people doing the work hsve the final say ln what tasks have to come first and what the sprint commitment looks like.
 
dowie said:
How are they "doing scrum" then? You're basically giving examples of people not doing scrum... but just using terminology or bastardising the thing.

Scrum is an agile framework. You might as well claim that not all people who are agile actually are agile - it depends what you mean, if you're including people who are simply claiming to be following some agile process but aren't really then sure, but there is a clear flaw there.
Click to expand...

Scrum is a framework, not a specific methodology. An organisation has to implement a methodology based on the framework. If the implemented methodology is not Agile then despite them calling it Agile or trying to implement Agile, then the methodology is stilll not Agile.
 
D.P. said:
The problem here is that assuming everyone has equal expertise which only happens on vthe simplest of projects.

For more complex work you have specialists that hsve specific and non-transferable skills, so tasks have to be assigned.

As an example, in an old project we had a couple of machine learning experts with PhDs/PostDocs, 10-15 years experience and earn 200k per year, video compression expect with PhD, embedded systems expert who would hook the hardware up to an oscilloscope etc, UX designers, web UI developers, IOS developer, an external translation team, middleare software developers, QA and a couple of interns
Click to expand...

He didn't make that assumption though, he's pointed out that you don't get personally assigned stuff in scrum by some PM etc.. that people within the dev team have different skillsets doesn't mean they can't self organise, tasks don't "have to be assigned".

D.P. said:
Scrum is a framework, not a specific methodology. An organisation has to implement a methodology based on the framework. If the implemented methodology is not Agile then despite them calling it Agile or trying to implement Agile, then the methodology is stilll not Agile.
Click to expand...

It's not about calling it agile, scrum is an agile framework if you're not actually making use of it other than going through some of the motions (stand up meetings) or using some of the lingo etc.. but really you're still using PMs and allocating work etc.. then sure, you're not going to be agile... because you're really using scrum.

You can describe this in some vague way and talk about "agile mindsets" etc.. but that's all fluff, bottom line is if you're not actually using the framework you claim to be using then you're not necessarily going to be "agile".

I'm not saying that is bad necessarily or that being agile or not is the correct way to do things.
 
You must log in or register to reply here.
Back
Top Bottom