11–20 of 32 posts
I know these have their place in complex projects, but I'm often intrigued when people don't just apply the natural human instinct of talking about something and doing what needs to be done. There almost seems to be a fetishistic obsession with referencing some magical method honed by masters of the craft.
In addition to the roughly standard 2-week scrum teams I work with, I am also working on launching a from-scratch project with two developers, and our process is roughly: 1. I keep a backlog of new features that are needed. 2. The backlog items vary in completeness/specificity from "mostly there" to "a sentence or two description". Some of the items are large and need to be subdivided. 3. At any given time, the devs…
That is the only way I have worked across 3 employers. I hope I never have to work in arbitrary time-boxed 'sprint' units or something. I never understood the appeal outside of pretty specific circumstances.
You can get feedback without sprints. But they make it easier, and encourage getting something in front of a user fast.
Earlier quoted context omitted.
That is the only way I have worked across 3 employers. I hope I never have to work in arbitrary time-boxed 'sprint' units or something. I never understood the appeal outside of pretty specific circumstances.
Sprints should give natural points to present to the end-user. Presenting to the end user is essential to getting feedback, and getting feedback is essential to building something the end user will actually use. You can get feedback without sprints. But they make it easier, and encourage getting something in front of a user fast.
At best it led to a stakeholder demo where some business people would look at a form or something, ask some minor questions, then a new cycle would begin (with its context switching, planning stress and perverse JIRA games - all the negatives of Scrum).
I don't think many companies use such regular user feedback in their development process.
Perhaps it's that they don't need to? I actually think a lot of company dysfunction happens when the "official" system purports one set of goals (user feedback, regular pivots) but the "real" system purports others (executive driven initiatives, long sales cycles)
If your pivot frequency < 2 weeks, sprint length is not the problem.
It allows devs to be creative, do what needs to be done, and ship a real feature. All without any product managers, and zero meetings.
Corporate companies could never imagine not counting all their beans, but man it is so freeing if you have the option.
Earlier quoted context omitted.
When you have more than a few people, “talking about things and doing what needs to be done” breaks down. You can end up in analysis paralysis (endless talking), wild west (everybody doing their own thing and not doing things that work together), wild hares (doing things that aren’t important) or even all three.
I'm a newb PM and at the moment I feel like I have all three... It's hard to coordinate when developers are all headstrong seniors with big agendas. The best I can do at the moment is nudge some of them, occasionally, into doing some of the work I need, while hoping their goose-chasing eventually produces something I can sell to my bosses.
The best ones I have worked with are competent, they dont make me do their work, they keep their promises, they dont waste my time, they see organizational issues and take point on them, and they generally were unflappable in targeting organizational discomfort about tackling an issue or talking to so and so.
This is really hard for someone jr to the space, but humility in the face of everyone's priorities is a great start.