rpmiskin

My bad, not ‘doing it wrong’, just trying to use the wrong methodology for your problem :)

sledgehammer to crack a nut.

You say that pointing is a waste of time, but also say that you don’t want something bigger than a 13. If you don’t do the pointing when do you realise the ticket is too big?

The points are purely to get an indicative size of the work, so it is clear work will be done in the next iteration (e.g. 3 weeks).

If other teams within your organisation need to know when an item is likely to be completed then accurate estimation is useful.

We’re in the midst of a ‘SAFe transformation’ from having been running in a fairly lightweight scrum-style manner for year.

There are a set of ‘good things’ that I can see from SAFe, and if you read the book and do the course there is loads about how you /should/ adapt it to work for you.

Amongst the issues is that SAFe, by its very nature, has stakeholders outside the local team and that mandates some sort of process.

Interestingly the size that Scaled Agile talk about is pretty big - a small Agile Release Train was discussed as ~100 people across ~5 teams. The full Portfolio SAFe is for multiple release trains e.g. 500+ people.

If you’re trying to enforce SAFe on something much smaller then I think you’re probably doing it wrong.

Also, if the “IT Department is trying to implement SAFe” rather than the “Company is undergoing a SAFe transformation” it has already gone wrong. You need to have your stakeholders throughout the organisation on board, and it is something of a top down thing.

The ‘correct form’ for the stand up is tricky, and probably varies on team size. For a small team (e.g. 4 devs) you probably care a lot about what the others are doing as you’ll likely be interacting with it closely (reviewing it, building on it), sometimes larger teams (e.g. 7 devs) then it might never come your way.

I’ve found that people who stick to the classic “what I did yesterday, what I’m doing today, what blockers are there” set tend to provide really short ‘bland’ updates e.g. “I was working on task foo, I’ll be doing more on foo today and possibly starting work on bar, I don’t have any blockers”. If you’re not paying attention you can miss the fact that the same update has been reported for 3 days in a row and actually there is some unexpected complexity and/or a simpler solution has been missed.

For me, the best stand ups give a little more information and can be a trigger for a follow up chat after the standup. “Yesterday I was working on task foo, today I’ll be doing a bit more because I found doing XXX is a little trickier than expected - but I’m still hoping to get onto bar, no blockers - unless my idea for XXX doesn’t work”

I’ve also found this sort of issue made worse on projects where the Project Management have decided that we shall be “Agile” and do scrum. You then end up with a non-technical PM acting as the scrum master and mandated “best practice”. This always stifles any technical discussion as it is ‘noise’ to them, despite being ‘signal’ for technical folk....