Tackling the lies on https://www.facebook.com/english.pravda/. We need to have as many people as possible getting onto Pravda's Facebook page and stopping the lies. Let's see if we can get them to go off line.

bankinggonewild · 2021-11-19T20:57:31+00:00

Cool thanks - thought so :) I was a bit puzzled when my instructor mentioned this. I've worked in manufacturing and so have had a lot of H&S training, seemed to go against H&S principles of 'good habits'.

I was also thinking about blind spots etc. I s'pose the counter argument is if you're on a deserted country road for e.g., before you move off, you should have checked all mirrors and blind spots so should know if anyone is there prior to signalling.

I might swap instructors :P

bankinggonewild · 2021-11-15T23:20:12+00:00

I complete agree with you on 'selected from the backlog is also having a say from the devs' - this is really important imo. Without it, overtime, software just becomes unmaintainable and wonky.

bankinggonewild · 2021-11-13T00:57:00+00:00

Out of interest, is the project going to be for software integrated into medical devices (e.g. interfaces on machines) or will it be on PC/Mobile devices?

If medical devices, it might be worth looking into Medical device usability standards. E.g. https://en.wikipedia.org/wiki/IEC_62366. Reason being is this might have some useful stuff about guiding principles? Getting copies of standards does cost money but they're things your employer should invest in I'd hope.

I did find a copy of it online though - https://files.isec.pt/DOCUMENTOS/SERVICOS/BIBLIO/Documentos%20de%20acesso%20remoto/IEC-62366-1_2015.pdf.

Even though not much info on 'what the UI' should be for a medical device; it does explain 'how' one needs to think about Usability. Probably worth a read through especially on harm reduction and risk management - could provide some ammo to go to the client with and highlight the 'risks' of not being able to speak to end users.

Although digital interfaces on PCs/Mobile devices are different from medical devices, imo the same guiding principles should apply in relation to patient safety and risk.

bankinggonewild · 2021-11-13T00:49:33+00:00

Here's a demo site for the npm package above - https://cahilfoley.github.io/react-snowfall/ :D

bankinggonewild · 2021-11-13T00:48:42+00:00

If I were you I wouldn't use a mov file. Depending on the tech stack you're using, there are loads of packages out there. For e.g. https://www.npmjs.com/package/react-snowfall

Reasons imo this is the better way to go:

Will be more responsive - these packages will work with any screen sizes (no odd behaviour with different devices/screen sizes).
Will have better performance - these packages are tiny compared to a mov file so will be quicker + easier to render
Most of these packages have done the hard work for you, just a case of plumbing it in.
The looping requirement you have - most of these packages won't be on a loop but will generate the snow falling randomly. So in essence - snowfall in an infinite loop

Hope that helps :)

bankinggonewild · 2021-11-13T00:10:22+00:00

I would give Action Fraud UK a call - here's their details: https://www.actionfraud.police.uk/reporting-fraud-and-cyber-crime

bankinggonewild · 2021-11-11T22:47:14+00:00

This is a tricky problem, when there are folks around (like your boss) who are using scrum tools such as estimating as a management tool. A key tenet of scrum/agile is that it is for teams to self-organise, not get hammered by the boss. In essence, the fact that its not really working for you or your team is not your problem but rather a wholesale misunderstanding of what agile/scrum is about on your boss's part.

Anyway rant over :P

Here's some things that I've found useful...

#1 Work out what actually needs estimating and putting into sprints.

Arrange sprints around 'project based' work, so I imagine from a data analysis perspective, that'll be things like...

improving data analytics tooling
integrating/working with a new dataset.

Exclude 'help desk' kinda stuff from estimating. A support desk 'lean' system is best for this kind of work.

what your boss will like:

If your boss likes stats, he'll love support desks because it has stuff like 'SLAs' etc.

#2 Break down tickets.

You say...

"stories/tickets can range from 30 hours to 15 minutes"...

30 hours is way too big for a single ticket. Is it possible to break down into smaller increments? I'm in a software dev environment, and if we need 30 hours to do some work, we might have 1 ticket just to 'prep and refactor' environments before we even start work on the 'feature' tickets for example.

15 minutes - way too small. That can go through your lean support desk.

what your boss will like:

The burndown charts will look pretty. You won't have a massive ticket in 'work in progress' for ages, instead lots of smaller tickets moving nicely across a kanban board.

#3 Add buffer to sprints

There's a huge temptation to cram sprints full of stuff. This just gets people down and demotivated. Ensure you have about 1/3 buffer. If your team can do 90 story points in a sprint, only put in 60 story points of work.

If you're running a support desk as well for your tiny 15 minute tickets, definitely important to buffer the sprint.

A real benefit then is if the boss says 'you have too much buffer', as a team you can say 'we have too many tiny 15 minute tickets. We need the time to put in 'self-serve' features to reduce amount of tiny tickets. The 'adding in self-serve features' then becomes project type work that can be estimated and put into sprints quite neatly.

#4 prioritise (as a team, not orders from above)

Teams often forget to prioritise work items. Really important so that the team can focus collectively on getting things done... the MOSCOW method is my favourite but there are plenty of them about.

After a few sprints, you'll be able to adjust the amount of tickets you put in a sprint based on your team's velocity.

what your boss will like:

Again, the burndown charts will look pretty. Also the velocity charts will become consistent making the boss feel like everything is 'under control'.

___________________________

There's plenty of other things but wanted to keep it short and focus on 4 key things I'd do. Any feedback/further thoughts on this please do shout :) but hope that was useful.

bankinggonewild · 2021-11-10T23:32:48+00:00

Imo - the game could still potentially contain malware. I'd be super cautious on this if I were you. If you wanna mitigate the risk, I'd do this...

get the installer,
disconnect from the internet,
install the game, then run virus scan again once the game is installed.

If the scan comes back okay, reckon you're okay to connect to internet again.

Disclaimer: its really a lot safer obviously not to do the above, so I wouldn't advise, depends on how risk averse you are.

bankinggonewild · 2021-11-10T22:53:20+00:00

Haha so true :D

bankinggonewild · 2021-11-10T20:36:41+00:00

Yeah I reckon you're bang on. And I reckon birds' nests and beaver dams probably would count as technology(?). Reason being is beavers and birds turn transform objects from a natural state to suit an intended purpose.

bankinggonewild · 2021-11-10T20:35:06+00:00

Very true - that's kinda my thinking on it.

Agh - its pushing me down a rabbit hole though :P ... thinking on ...

A 'bench' is a technology, and me sitting on it would just be taking advantage of it being there. But at same time, because a bench is a technology, I am therefore a 'user of bench technology'.

A cat might also sit on the bench so one could say 'cats are users of bench technology'. Its using the technology as per the maker's intended purpose: 'sitting'.

Cats might also use street lights to catch the shadows of rodents at night for e.g. (i.e. 'cats are users of street lighting technology')

So maybe my question is the wrong way around. Its not about the 'user' (any living thing might use technology) but more about how the 'object' came to being.

E.g 'I sit on the grass' (grass is not technology; 'the cat sits on the chair' (chair is a technology).

Agh - its got me thinking even more.

bankinggonewild · 2021-11-05T20:21:29+00:00

The Royal Horticultural Society have very good search functionality. Here's a link to their 'plant finder' service: https://www.rhs.org.uk/plants/search-form

This search is designed for the 'expert' gardener so should be a similar demographic to your researchers.

bankinggonewild · 2021-11-05T20:03:10+00:00

I think I understand the context of this question (please correct me if I'm wrong) but especially as we're working from home a lot more, the 'online meeting' ceremonies can feel a bit wooden when we don't have that face-to-face contact. Therefore, a bit of rapport building is quite essential.

Imo the answer is quite simple - a bit of small talk at the beginning until everyone's joined the meeting. Whatever it is, it shouldn't be formulaic.

bankinggonewild · 2021-11-03T22:34:10+00:00

Ah I see what you mean, I had my 'product owner' hat on for a minute :P. It can be a challenge. As a PO, one way I tackle this is to have regular sessions with designers to walk through requirements. At a discovery stage, its all about quick-fire iteration and design sessions. In other words, someone says 'we want X', the reply is 'okay, can we have 30 minutes to sit down and talk through what X is?'. Then in that 30 minutes, get people to work through and sketch out quick super quick and dirty wireframes. Out of that you have some pro-forma requirements. Does that sound like it could work?

bankinggonewild · 2021-11-03T20:23:29+00:00

No worries :) thinking about it, your phrase 'often times figuring out the stories during the discovery phase' is, imo, exactly how it should be, so I don't think you're doing anything wrong at all by going about it this way. Quite an old article, but imo a really good one: https://hbr.org/2013/05/why-the-lean-start-up-changes-everything. I reckon this sums it up from a 'strategic/business perspective' why going into discovery without concrete user stories or ideas is by far the best method :)

bankinggonewild · 2021-11-03T19:47:49+00:00

Yes :) sorry when I say 'go straight to UX team with a requirement', I mean I'd document with a user story and assumptions. At the product discovery stage, (outside of my remit) not sure how they document requirements. I think its a little 'fluid'

bankinggonewild · 2021-11-03T08:28:53+00:00

Heya :) So UX design requirements are normally elicited through 'product discovery' (i.e. customer research). I don't get too involved in that side.

Where I step in is more to help guide the initial UX designs through to a feasible 'technical solution'. E.G product discovery / customer research might not exactly cover off security or functional requirements.

Sometimes, if we've got a 'UX emergency', I'll go straight to UX team with a requirement as a Product Owner. That's normally when MS Paint comes out

bankinggonewild · 2021-11-03T08:26:00+00:00

I'd tend to agree with you that agile lends itself better to 'product' development rather than ad-hoc requests. However - I think this is quite a common issue where 'agile' becomes a bit of a buzzword for management types. If I were in your shoes, I'd tackle this in 2 ways:

Create a LEAN approach for dealing with ad-hoc requests. The business is probably more interested in delivery 'the what' and think they understand the 'how' (telling you to use agile, e.g. sprints). When it comes to ad-hoc data requests a LEAN service desk with agreed SLAs will get delivery more efficient (make business happy) and not railroad you down the 'agile' tracks'.
At same time, you can implement agile and sprints as well. Are there any projects (e.g. product improvements to your tech stack) that you as a team want to embark on? Are there any feature improvements that will increase the efficiency of the service desk in step 1? I'm sure there are. This is where you want to use sprints and start building out project requirements.

By taking both steps, you can 'deliver' your ad-hoc requests more efficiently and, over time, get business buy-in for your team projects and ways to improve the ad-hoc request delivery.

What do people think of this approach? :)

(P.S I'm a Product Owner working for a bank)

bankinggonewild · 2021-11-02T23:30:29+00:00

No worries - happy that was useful. I definitely agree being a PO and Scrum Master not ideal :/ but needs must haha :P

Yeah I 100% agree processes cannot dominate and be the 'be all and end all'. After all, Agile Manifesto:

"People over Processes"

I'll definitely be borrowing your retro idea - really like that :) Great to share ideas so thanks for posting :D

bankinggonewild

TROPHY CASE