221–230 of 459 posts
I've worked with two-week and one-week sprints, and generally found them very helpful, but more helpful with better PMs.
There are some general guidelines, there is some amount of this that can be taught (not enough to sell a course or certificate), but mostly project management outcomes are dominated by the terms of understanding the domain in detail and the people involved as holistic human beings.
Paul Graham said that the management of hackers for someone who isn’t a hacker can be summed up as “give up”.
Don’t shoot the messenger please, but I agree with pg.
I've been bemused watching the rise of agile over the last (10?) years since my background is in building software for large/multinational non-tech companies. They have VPs and accounting departments with budgets and they want to know exactly how much they're spending before they spend the first dollar. Whether or not they should, they don't see the uncertainties in estimating software development as their problem. M…
1. Much less time spent trying to chase requirements that are technically infeasible within the budget and rough timescales. This on its own normally more than makes up for iterating and throwing away proof of concept implementations of features.
2. Much better visibility of progress. Because you are delivering something tangible that stakeholders can see and feel all the way through the development process, you get better feedback from your stakeholders, better buy-in from your sponsors, and fewer canceled projects.
3. Where projects are canceled, they tend to be canceled early where they are clearly not working, before millions has been spent.
The need for requirements doesn't go away with agile. If you start a project with no requirements, it will almost certainly fail. However the iterative process allows you to refine the requirements as you go, and the early and frequent feedback from your stakeholders makes the requirements better. It's easier to add or remove a requirement if you can see the software doing something wrong or not doing something it should do, rather than trying to figure it out on paper ahead of time.
Earlier quoted context omitted.
And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the "big picture" of how everything should fit together in the end (if they were ever aware of it). And when all of those small tasks are done, you notice that the sum of all those parts is not what you set out to build initially, and you need more time to shape it into something that resembles what…
What would be the alternative without sprints? What specifically about not using sprints would help the team if they lack good planners and people capable of seeing the big picture? Isn't such a team screwed regardless of how they allot work?
Worked on a small group (2-3 people?) and .. 'agile-2-week-sprint-estimate-tickets-with-points' wasn't working well. This is 'startup/mvp' area, and we migrated to just a simpler task board. Owner moves tickets up and down in a "to do" queue, and someone (usually me) takes current 'to do' tickets, and does them and releases. The '2 week' time box wasn't really helping anything - we can 'release' multiple times per week.
For larger teams working on established product, there's more value to the '2-week-sprint-give-points-to-tickets' approach that's more popular. Worked in a group a few years ago like that, and... while there were some issues, they weren't specific to sprints or agile, more just growing pains of that company.
Earlier quoted context omitted.
In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out. Also all the sprint planning and retrospective took basically 30% of our time.
I find it challenging to estimate my own time in tasks. Part of every task is figuring out how to actually do the thing you are wanting to do, and sometimes that takes 5 minutes and sometimes much longer. So I am terrible at estimating my own time, and even worse at estimating someone else’s. It doesn’t add pressure to a person if you give them a time goal they know is basically arbitrary.
This is what scrum (done well) helps with. Unless the software was horribly written, it’s usually easy to estimate effort for very modest, well-defined changes.
Take a large enhancement or overhaul, however, and estimates will be wildly off and it’s because of the iceberg effect of unknowns.
What scrum forces the inexperienced teams to do is start breaking down, plan and incrementally chip away at a ill-defined, large request by turning it into many smaller and better understood deliverables.
It’s what very good teams do, though they do it without the need for formality.
This is nothing but a bad strawman from start to finish. Sprints are not made to help organize things, they're a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability. This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and…
I’d go further, sprints are defensive for devs. Don’t bother me or tell me to do something new during a sprint. I’m doing the work I said I’d do, leave me alone until the sprint is overs.
There are some great, as in large, problems with software development, as a result of having multiple parts developed by different groups, or even by one person at different times. The parts have to work together.
It is easy, and I have seen this happen in multi-million dollars companies (plural) for groups to go off, develop their parts and for the parts not to work together. Boom. A sprint is designed to ensure that detecting this failure happens early rather than late.
Can you have a sprint that does not help this situation? Yes. And if you do then the sprint is just foofaraw.
The other problem is that it is easy and somewhat natural to write 90% of the code. Which does nothing. 90% of the code is meaningless. What works is the issue. No one needs or wants code. They need or want functionality. I have written some really really cool code that does nothing. It was 90% of something, but unfortunately had to be rewritten in order to be functional.
The second use of a sprint is to show functionality. A sprint to have 92% code completed is nothing. Can you show (to me or yourself) that 90% of the functionality is there? The difference between 90% of the backend API's being functional (and being able to prove it) and 90% of the backend code being written is monumental.
There is a final use of sprints. As a manager you can appear to know what you are doing by organizing sprints, when in reality you have no clue whatsoever as to what you are doing.
If you want to be a good programmer, you will use sprints with yourself. I'm a sole developer and when I use sprints by myself I am much more productive. Much. [updated for spelling and clarity]
Rich Hickey has a great joke about sprints, paraphrasing: So how do we run a marathon? That's right, we run a 200m wind sprint! Then another sprint, and another, and pretty soon... Of course no one does this, you'd die! We don't do this in software either, for the same reason. But when we talk about 'sprints' this is what we tell ourselves we're doing.
I thought "sprint" was dumb at first, for exactly this reason, it's not a sprint if it's week after week. But over time it's just become jargonized, a term of art for me. It's just a unit of organization.
The most boring choice would be "section", and boring might be good here.
We could borrow from military strategy, not for the first time, and call it a "maneuver". More sporty, and pointing to the repeating nature, would be "round".
I wish the word "sprint" could be used for "this will call for an unsustainable amount of effort. we will be calling in dinner a few times. this isn't normal, and can't be normal, and everyone gets to rest after, but it's something we have to do".
Instead it's just a way of saying two weeks.
Rich Hickey has a great joke about sprints, paraphrasing: So how do we run a marathon? That's right, we run a 200m wind sprint! Then another sprint, and another, and pretty soon... Of course no one does this, you'd die! We don't do this in software either, for the same reason. But when we talk about 'sprints' this is what we tell ourselves we're doing.