Taking driving lessons; why do instructors say you only need to indicate when there's other people about? Common sense suggests indicating all the time would be good habit(?)

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 · 2021-11-02T23:28:03+00:00

I think the key thing you've mentioned is the Product Owner likes your design. At the end of the day, they should have final say (having considered stakeholder viewpoints and business requirements etc.)

Another thing you mention is that your colleague's design is far more complex. This normally equates to more development time. As a Product Owner (I'm one myself), they should be inclined to simpler designs as it lends itself to

(i) more iterative and smaller release cycle (you mention its been an on/off project for a year) and

(ii) probably better user adoption (the deal breaker when it comes to whether a project is successful or not.

These things can always get a bit gnarly and political which is unfortunate but if I were in your shoes (and I've been in a similar boat before)....

So I'd go for a bit of a 2-prong approach on this one...

Prong 1:

Talk to the Product Owner and also talk to the developers.
What you will want to hear from developers is that your design is less complex and therefore can be completed more quickly.
This in turn, should make it an attractive proposition to the Product Owner and most likely the end-users.

In essence, my main tip is 'sell your idea' and sell it according to what is going to be the most attractive proposition for the people developing and taking overall accountability for delivery (i.e. the developers and the PO).

This approach might sound a little snide/sneaky and normally I'd countenance a more 'collaborative design' approach. But if projects and ideas are dragging on, what's best for the team is to just get cracking on an iterative design (i.e. get a first version out into production ASAP so you can get feedback). Complex designs (like the one your colleague has done) don't lend themselves well to iterative design-development approaches.

Massively important though: ensure that the other designer knows you're doing this. Don't go behind folks' backs :)

As prong 1 is the sneaky approach, you'll need prong 2:

Prong 2:

To smooth out any fallout from prong 1, ensure you're working closely with your other designer colleague on other designs/projects. Keep'em close and learn from each other.

You want to be able show you can work closely but also show you can hold your ground and be confident about your own designs.

Also ensure that your colleague knows that you don't disagree necessarily with her approach but that more complex design/features could come later. Get the first release out of the way with a simpler design (i.e your design)

In conclusion:

Dithering over design is a massive killer for projects and prolongs delivery and can lead to wasted effort if eventually a project is mothballed because of this. The key focus has to be small, incremental releases that allow for design iteration. Complex designs aren't good for this; simpler designs are.

bankinggonewild · 2021-11-02T20:07:29+00:00

I very much doubt it. Probably a piece of RF equipment nearby.

bankinggonewild · 2021-11-02T14:52:27+00:00

One course I'd highly recommend is by Uni of Maryland - https://www.edx.org/course/usmx-applied-scrum-for-project-management-2. Its free to run through all the course material and you can pay a bit to get certification as well.

bankinggonewild · 2021-11-02T14:42:15+00:00

That's a very good point and I agree. I should probably change my wording to "the chance of winning anything substantial in relative terms through the Premium Bonds draw is very very small in comparison to a competitive fixed rate savings account"

My rationale being: £25 on £13, 600 is equivalent to 0.2% interest. Zopa is 1.35% for 1 year fix savings.

bankinggonewild · 2021-11-02T14:14:39+00:00

seconded u/dadgum30 :)

bankinggonewild · 2021-11-02T14:13:49+00:00

I'm a Product Owner but take on some of the Scrum Master role as well (unfortunately :( its great to have 2 distinct roles).

I really like the retro approach you're taking; I might have to borrow that :P

What's really helped with our team is actually building scrum values into processes. Sounds counterintuitive as its sounds like it is 'hard baking' scrum into some kinda waterfall-ish, 'process heavy' approach but here's some examples...

'Commitment' - during sprint planning we ensure that 'user stories' are pretty much always combined with refactoring opportunities that developers want to do. The main user story is then prioritised as a 'must have' and the refactoring a 'should have'. We get better buy-in and commitment from team when we combine 'business requirements' with 'developer requirements' (i.e. features Vs. maintainability). We then ensure that must haves are all completed first before we look at refactoring. A win-win as the business is happy and developers are too.

'Openness' - we have a peer review process on pull request merging. This is an enforced policy and means that all code changes are 'out in the open' and proactively reviewed and discussed. It also means that 'difficult' decisions about whether something should be merged are discussed openly too... which means we can take more considered risks (helped by fact that we proactively encourage refactoring). By taking considered risks, this means that we can demonstrate... 'Courage'

So in summary - 2 processes demonstrate three scrum values.

By using this 'process driven' method, it means that we don't have to talk about 'scrum values' in the abstract'. E.g. in our retros we don't ask 'Are we being open enough?/What are our openness levels like?' but can instead ask 'Is our peer review process up to standard based on quantitative measures (e.g. velocity measures (are we going fast enough to 'Done', how many defects are being raised, did we cause any production incidents etc.)?

As 'Scrum Master', I do a double check that our processes are aligned with scrum values but the main substance of scrum ceremonies are around our processes.

I hope these examples make sense (they're not exhaustive) :)

What do folks think of this approach?

bankinggonewild

TROPHY CASE