When I hear agile and SCRUM I just want to puke. Luckily I've been agile free for all my programming life.
Need a job board for dev jobs that don't do scrum, seems pervasive.
This really should be a thing.
Less is more agile
81–90 of 174 posts
Re: Less is more agile
#82> And at the end of it, the estimate has to be thrown out anyway because the devs who picked up the story didn’t have the same experience as the devs estimating.
I thought the "rule" was a single core team, not multiple sub-teams of devs.
If devs with less experience are also at the planning poking table to voice their concerns; the more experienced devs can take that feedback on board to come to a consensus estimate.
Individual tasks may be over or under depending on which dev picks it up but the idea is to get the average as close as possible to being accurate.
Re: Less is more agile
#83> It is not the technology that matters, it’s interacting with people. The better engineers can communicate, the better a team will perform.
This pretty neatly summarizes my ~25 years of experience in the industry! With the additional observation that most developers and managers are not aware of this phenomenon... :(
Re: Less is more agile
#84Everybody else does it, we have to do it, don't question anything even though you think it's not really that important or even detrimental. It's emperor's new clothing all the way down.
I agree it's helpful that there's a common theme on how "we" do things, but the point about making it organic is spot on. Nobody does things so they do scrum. The goal is to deliver something useful, how that gets done might be very different in different contexts. So mold it to how you do things.
Re: Less is more agile
#85Nice enough article, but I don't know where the author found such a poor definition for the word "ceremony".
A ceremony ain't just going through motions, it is going through motions to reconnect with elders, identity, re-confirm to all the position of some in the local structure of power, show symbolic values.
As such, that word is the most precise one in the Faux-Agile lingo, and clearly shows the purposes have nothing to do with delivering better software faster...
Re: Less is more agile
#86Earlier quoted context omitted.
Not op but I’ve worked in Agile™ shops, places that are agile, and waterfall-y enterprise stuff. The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. Pointing doesn’t matter, extensive grooming doesn’t matter, extensive planning doesn’t matter, sprints don’t matter, etc. Grooming your work does matter but 30 minutes is enough for a high performing te…
> The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. The best project I ever worked on: one developer (me), one project manager on our side, one QA/test person at the client, and one manager at the client who was what we'd call a product owner on a scrum team. No ceremonies, no pointing, very little backlog grooming. Shared Bitbucket repo for issue…
So much easier with small teams. Scaling to say 1500 people is hard. Then you need some kind of hierarchy and explicitly architecture. My biggest problem with agile is that people think it replaces architecture with ad-hoc decisions. Threading in design work as spikes and regular stories needs about the same discipline as "processes".
Re: Less is more agile
#87Earlier quoted context omitted.
Obviously not all projects are the same, there are certainly pieces of software that would be disastrous to do that with, I'm just speaking generally. For reference, my (very not-startup) team is ~20 engrs in 3 teams responsible for ~30 services and we deploy stuff ~25x/wk. Also a 'crunch' around the end of a sprint sounds like mini-waterfalls.
How do you avoid mini waterfalls? At some level of granularity you are doing one thing you committed to at a time. If someone else needs to check it thats a handover. How I have seen sprints done is you commit to X Y Z, have a definition of done like “is in production” and then developer works on X, gets X code reviewed and so on. If the aim is that the right amount of work is in each sprint then naturally the last d…
Just do away with sprint commitments. Pull a new story off the backlog each time someone needs a task, and count how much you accomplished at the end of the sprint instead of guessing at the beginning.
Re: Less is more agile
#88Earlier quoted context omitted.
How do you avoid mini waterfalls? At some level of granularity you are doing one thing you committed to at a time. If someone else needs to check it thats a handover. How I have seen sprints done is you commit to X Y Z, have a definition of done like “is in production” and then developer works on X, gets X code reviewed and so on. If the aim is that the right amount of work is in each sprint then naturally the last d…
Just do away with sprint commitments. Pull a new story off the backlog each time someone needs a task, and count how much you accomplished at the end of the sprint instead of guessing at the beginning.
That sounds sensible to me! Thanks. Nice to get these perspectives as I have never heard a colleague say that before.
I guess you can then get rid of the 2 weeks? Because you can measure velocity as a continuous rolling average. Retros could be continuous too and standups already are. Grooming is easy to make continuous too.
Re: Less is more agile
#89The problem with this kind of article is that it doesn't recognise that software is built in different contexts. "Don't estimate" may be fine if your product is an SAAS that gets updated incrementally. It won't cut it if your clients question is "we've booked the O2 arena for April 2023. Can you build this by then?"
Re: Less is more agile
#90The problem with this kind of article is that it doesn't recognise that software is built in different contexts. "Don't estimate" may be fine if your product is an SAAS that gets updated incrementally. It won't cut it if your clients question is "we've booked the O2 arena for April 2023. Can you build this by then?"
The problem is these clients have no idea what they are doing, they should be working out if something will be ready before booking.
If they are coming to you telling you the deadline and asking if you can meet it you know your going to have problems with them. Invariably they won't have a backup for when its not done on time for whatever reason.