One of the biggest problems with sprints is they’re organizationally orthogonal to CI/CD. Kanban is a much better process for an organization who’s goal is to continually deliver business value to stake holders. And it’s been my experience that pragmatic Scrum teams that just roll over unfinished work are essentially using Kanban.
I don’t believe in sprints
321–330 of 459 posts
Re: I don’t believe in sprints
#322If you think Scrum is the "universal method for making software", you clearly haven't worked outside of applications software...
Re: I don’t believe in sprints
#323Earlier quoted context omitted.
Yes, sprints on paper are what you describe, but in reality, they rarely ensure deliveries or predictability, they even tend to hinder productivity as they narrow the body of work of a whole team. Think about it, after a week, what is usually the distribution of work of your team? For me, it was always very unbalanced, where people where working overtime and others (best case scenario) would be looking for some work…
I guess all will agree that every successful product is an outcome on number of iterations and to perform progressive iterations there has to be a way / tool which can be one language across the board. That's why these tools such as Sprint exists. And I am sure if you are a good manager ( a future self ), you would sure not giving yourself a suggestion of using "post-its, emails, spreadsheets, large whiteboards , han…
I'm a manager, and post-its, tv screen in the room, extremely large whiteboards (all 3 walls) and spreadsheets have been my secret weapons for a long time... that and going on a long walks with my engineers 1-on-1 to discuss ideas and problems.
Tools and methodologies are guardrails, use them at the beginning as you learn the craft, get ride of them as you grow and always put meaningful conversation above all
Re: I don’t believe in sprints
#324> software engineering has accepted as its charter "How to program if you cannot."
Looks like this Edsger Dijkstra's phrase never gets old :)
Re: I don’t believe in sprints
#325My Project Manager's Response: "Nice rant. Sounds like he works with mystical unicorn teams."
Re: I don’t believe in sprints
#326Earlier quoted context omitted.
In the same way that few ReST implementations are truly ReSTful, few agile implementations are truly agile. The Agile Manifesto came into style, then predictably a cottage industry of small companies grew up around it, with the business model of charging Fortune 500s huge amounts of money to train their Engineering departments. I've sat through such training before, and I can say without doubt that the day our compan…
I tend to think of communism as a comparison. Aren't proponents of "agile" similar to those saying "we've never had real communism"? Both have manifestos. I think there are certain systems that make sense and can be executed properly but human nature eventually mucks it up.
No one's saying we've never had real agile.
Philosophically, agile is more like democracy/capitalism: it decentralises control to teams, where the information and expertise are. Failures in agile are things like "I didn't like using story points".
Waterfall is more like communism: it centralises control away from the people doing the work. Failures in waterfall are things like "we spent millions and got nothing out of it".
Re: I don’t believe in sprints
#327For a more cogent and compelling analysis, I recommend Florian Haas' Fragile Development talk.
Re: I don’t believe in sprints
#328There are a lot of comments in here that imply sprints are a necessary evil if you want predictable delivery. I call bullshit.
We don't do sprints. We don't do Scrum. We don't do story points. We have predictable, reliable software delivery on multiple products with an ever growing product development team of 65 people. It's all about measurement and mindful planning.
We are strict about structuring epics vs. stories vs. tasks, and make the largest deliverable an epic. Epics set the scope of what we want to achieve. Then we describe user behaviors / experience we want to enable in terms of stories. The engineering, deployment, and design activities needed to enable those behaviors / UX are structured as tasks.
We say when we want to be done with the epic and try to determine if the scope we have outlined for the epic is reasonable given the self-imposed deadline. Then we measure the growth of tasks in epics week to week. Tasks are expected to grow fast in the first 20% of a project and then start to taper off as more and more of the engineering takes shape.
If we're not following that curve, we hold a retro. If we add stories or change the scope of the epic, we hold a retro. We adjust scope downwards or we change the estimate. We communicate the changes to estimates out to customer-facing teams early in these cases.
The last large-scope new feature we built on our product was scheduled to take 4 months. They were behind by less than 2 weeks, and half the team were rookies. Oh, and no-one was asked to burn the candle at both ends to get us there. No saturdays. No 10pm conference calls between engineering managers and the dev team.
There are better ways to do reliable, predictable software planning than sprints.
Re: I don’t believe in sprints
#329"Sprints" are a very bad name, giving the impression that the team is always running, which is a bad for morale and quality. In reality, they are just "cycles". I see them like CPU cycles, but for a team. They are a heartbeat keeping team members in sync. It's all about answering what's my next task when I'm done with the current one. If you I work alone, or in a very small team, with no external stakeholder, then I…
> "Sprints" are a very bad name, giving the impression that the team is always running, which is a bad for morale and quality. In reality, they are just "cycles". Agree. Actually, my first experience with Agile used the term "iteration" instead of "sprint" which I thought made much more sense. Everywhere else I've been has used the word "sprint". I suppose a "sprint" does includes three parts: start, run, stop; paral…
Yes, "iteration" is another good alternative. Good point on the start/run/stop semantic, but like you wrote, I guess most people associate sprint with speed more than starting/stopping :)
Re: I don’t believe in sprints
#330Earlier quoted context omitted.
How bout, plan enough then just build the thing until we agree its usable and correct. What the hell is the point of the short time framed boundaries? I'm not a fucking horse I don't need cadence OR blinders.
That can be seen as a large enough sprint that encompasses "the thing". If, like in the scenario I was describing, the team lacks good planners, lead devs and people with the "big picture", what you are describing is a recipe for disaster. What will happen is that at the end of the long stretch, they won't have achieved much or worse, built the wrong thing. When done well, any iterative method is meant to provide ear…
If developers x, y are developing UI and API endpoints and developer z is developing backend to a 10k+ page spec, 2 week sprints need not apply to developer z.