14 ms·

Plan the Sprint, Not the Project

89 points by mcrittenden 6y ago

sushshshsh 6y ago
Continuous delivery, continuous payments ^.^
nicoburns 6y ago
I don't think it's good to abandon up-front planning entirely. It's important to know what you're aiming for and to have a plan for getting there. The key thing about an agile approach is to regularly review the plan and be open to changing it as and when new information comes in.
- tremon 6y ago
  It depends on the level of detail in the plan. The article says to delay the plan, not to skip it. The goal of that is to avoid fleshing out the details of parts that are not relevant to the current focus (with "focus" being defined as the scope of the current sprint). Of course, you need to know the direction of the project. But spending time on details that you cannot directly validate with implementation, risks both wasting time because of invalid assumptions, and risks wasting time because the requirements may change when you get around to implementing it. Remember that "planning a sprint" gets very deep very quickly. It's not just about setting direction, it's about deciding display names, storage types and UX interactions. The point of the article is that that level of planning should not be done months in advance.
  - cestith 6y ago
    Your sprint planning is deeper than sprint planning some other places. Some places that at least claim to be doing Scrum will groom the backlog in one meeting, then choose which stories go on the sprint in another. Anything that needs agreement among developers is then tackled in pair programming or fairly ad-hoc "hack sessions". Implementation details, including details of code interfaces, user interfaces, and system interfaces, are left up to the contributor unless there's a need to align effort before that story is done.
- jonpurdy 6y ago
  Totally correct. This article is on the "totally idealistic" side, and I think it's important to know what is ideal as a benchmark when working in non-ideal situations. Executives and clients like to see timelines and total project estimates. I wrote an article* about this. The idea is that you do some rough planning, applying the principles of Agile story point estimation, and extrapolating a rough/relative timeline. Relative timelines with non-specific dates are useful for getting an idea of the scope and possible time of a project. Helps determine what should be built first, prerequisites, and what other teams might need to be involved (and at what stage). Also useful to get the product managers or executives thinking a bit more deeply about the project and perhaps reconsidering it, or reducing scope if it looks like it will be larger or take longer than expected. Once a project is kicked off, after a few sprints the initial plan can be updated based on the actual velocity of the team. * https://jonpurdy.com/pm-framework/how-to-quickly-plan-and-estimate-an-mvp/ https://jonpurdy.com/pm-framework/how-to-quickly-plan-and-es...
  - maitredusoi 6y ago
    > Executives and clients like to see timelines Do they really need them? ;)
    - marcinzm 6y ago
      They need them because they all have their dependencies that they need to manage separate from this project. A client may need to plan training, transitions, budgets, deprecation of old systems, etc.
    - bluGill 6y ago
      Yes. They need to not sell the next version too soon, but start selling soon enough to develop hype. They need to decide if they should invest in updating the previous solution one more time while waiting... They need to decide if the whole is worth the cost or should they develop a different project instead.
    - jonpurdy 6y ago
      Others above me have mentioned the reasons why they need them. But I'll reiterate my emphasis on rough/relative timelines. Exact dates are impossible and the farther away a milestone is, the hazier the date is. As an example, a milestone a month away could be +/- a week, but a milestone a year away could be +/- three months.
douglaswlance 6y ago
This is how you end up with poorly architected code that will be so difficult to change that development will eventually slow down, stop, or begin going backwards.
- lumost 6y ago
  +1 to this, eventually the sprint tasks are so minor as to not have any impact on the business - but they still take days.
- tchaffee 6y ago
  Not in my experience. If you are agile, you can fix the architecture as needed. You end up with poorly architected code by deciding to continue building on top of something when it is no longer suited to purpose. That can also happen as a result of big investments in planning. That investment makes it very hard to rationalize architecture changes when the requirements change mid project. Which they very often do. No amount of planning protects you from the unpredictable.
LoSboccacc 6y ago
this may work for internal teams building internal tools, but there's very little chance to find an enlightened client that will sign a scopeless development contract. and it sounds awfully close to being body rental, with all that it entails.
- Stinkosaurus 6y ago
  I’m on an internal team building internal tools and I think the advice this article gives is absolutely terrible.
silasb 6y ago
What do you think about ShapeUp?
- maitredusoi 6y ago
  Hey, thanks, didn't saw it before. For who may be concerned : https://basecamp.com/shapeup/shape-up.pdf https://basecamp.com/shapeup/shape-up.pdf
  - maitredusoi 6y ago
    ShapeUp TLDR; >> Backlogs are big time wasters too. The time spent constantly reviewing, grooming andorganizing old ideas prevents everyone from moving forward on the timely projects that really matter right now. <<
- AgloeDreams 6y ago
  I was wondering this as well. This all seems like the complete exact inverse of shaping in some ways and reenforces some others. Generally for small, extremely skilled teams, the Shape Up methods are hyper efficient and can focus on a product/engineering goal, notably it forces management to define deliverables in clear and specific terms that outline a developer's jobs to do and semi-long term goals. This allows the dev to work on building something in whole rather than parts but with defined time and outcome goals. (~6 Weeks in the Shape Up Guidelines). An interesting Shape Up Guideline, (also seen here) is the idea to avoid excessive long term planning or backlogs. Agile is shown as God in this post but..why is Agile so good according to the author? The main advantages is the ability to course correct fast and be reactive but if you are making good work, Agile blinds you from seeing the whole product and causes bad, segmented, low-focus mistakes. If you are TOO agile you may build a DB/API/Logic/Data structure that is too narrow and limiting of the eventual goal. Personally the real danger of this thought process is that it limits developers from understanding the whole of what they may be building. That's downright draining, makes every sprint seem like going to a run to nowhere. This method and plan seems just like an excuse to let management do less and define and shape work to be done less so that you can avoid the dangers of 'Waterfall'.
skellington 6y ago
Ignore this person's advice. It is objectively wrong. How would you build a rocket if you only thought about the next 2-4 weeks? How would you scope the size of any given project if you didn't think about it in totality? Successful development is always a balance of waterfall and sprints except maybe when you're in maintenance mode for long living legacy projects. Waterfall = strategy Sprint = tactics
- Jtsummers 6y ago
  Waterfall is shit, don't think waterfall. Better is to think about things like work breakdown structures paired with an iterative schedule (aka, sprints). Your WBS establishes the things that you know now, the things that can be done in parallel, and the things that depend on other actions. Your WBS also gives you a rough schedule (but do not take it as gospel because you aren't a prophet). Based on this, you can start prioritizing the work that goes into the iterations. Periodically (with each iteration or after several) you revisit the WBS and determine if what you're doing is keeping you on track, or if it's even still the right structure.
- softwarefounder 6y ago
  Yep - the hilarious thing is even the most Agile/Sprint heavy consulting companies usually have to succumb to some Waterfall concept in order to provide an estimate or meet a fixed bid.
  - tchaffee 6y ago
    Because they aren't good at selling agile. Why do people ask for estimates or fixed bids? It's to manage risk. And how often do projects not go over estimated budget? Even fixed bids are poor at managing risk. Lots of consulting companies will walk away from a fixed bid contract after months of work at the point they realize they will lose money on it. And honestly, what's the quality of work once the contract is no longer profitable? We've all seen it. Everything is a quick hack at that point in a desperate effort to achieve the minimum that could be defensible in court. A fixed bid project means the consulting company and the client have opposing interests: the consulting company wants to get it done as cheaply as possible and will make every shortcut they can get away with. And the client wants every last bit of quality they can squeeze out of the contract for that price. No wonder it so often ends in dissatisfaction for both sides. What are the options for the client when the consultant says "sorry we didn't actually finish and we are out of money"? They either pay more or have to be willing to sue the consulting company. Most companies suck it up and pay more. This is so endemic to the industry that most companies put extra in the budget for software project overruns no matter how tight the fixed bid contract is. So one way to sell agile is to help clients understand how it can help manage risk better than a fixed bid contract or always inaccurate estimates. And how it can be used so that the interests of the consulting company and the client are better aligned.
rubyn00bie 6y ago
Awful advice. This is how you build terrible systems and avoid having to ever look at yourself for building useless crap. You're never looking anywhere but your feet expecting not to run into a wall. Yes, you probably shouldn't build something massive without ever getting feedback, that has nothing to do with sprint vs project planning. People in this industry need to let the worlds "lean" and "agile" just die the death they deserve because they mean literally nothing at this point. It's nothing but lip service for SEO and junior managers.
avojak 6y ago
> Don’t create tickets for things you won’t work on for months, if ever. Yikes. Dropping tickets in the backlog for ideas that pop into my head is a great way to make sure they're not forgotten! The team may decide later that it can be closed, but it opens the door for a conversation and helps collect ideas.
- deleted 6y ago
  [deleted]
- pc86 6y ago
  Yeah this suggestion seems like addressing a symptom - a backlog full of useless items - instead of addressing the disease - not having regular backlog grooming sessions where outdated/irrelevant items are either updated/fixed or removed.
- majormajor 6y ago
  The alternative to this that I use is "don't precisely estimate tickets more than a month out" because if something has 6 other tickets between now and it, things will probably change by then, so a precise fully-fleshed-out estimate will probably just wait time and not be any more valid than the "about a week" one anyway.
- almostdeadguy 6y ago
  Months down the line your ideas might not even be relevant anymore. On my team, if you put stuff in the backlog, you're responsible for maintaining it. If you're not prepared to accept that responsibility, it belongs in a notebook or a word doc, not the backlog.
- deleted 6y ago
  [deleted]
sailfast 6y ago
This might be good guidance to avoid getting too deep in the weeds and avoid starting work. Might even avoid the whole "waterfall with sprint" trap, but I'd argue it's quite important for the entire team to have an idea of where they are going, generally before you start work. Agile Roadmapping is a thing that works. Feature prioritization, generally, helps to get the highest value things out the door first, etc. The team doesn't necessarily require those waterfally milestones - it could be as simple as a value delivery statement ("Fastest shopping cart west of the Mississippi" or something) - it doesn't have to be a whole big deal with specifics, but without it i'm not sure how you determine the sprint goals, let alone what the specific technical tasks or stories are going to be without that shared context. Lastly, I'd definitely recommend some sort of longer-term roadmapping exercise up front to determine what the high risk things are so you can solve them first, and test the big hypotheses quickly. That would be a nice lean thing to do. Plan the sprint, sure. Be militant about it if you want. "Shut up and plan the sprint!" But the sprint is not the goal. Delivering increments of value is the goal. The product owner looking at the sprint goal needs to know what they're trying build, and a longer vision can help. I'm not sure the author meant to sound so short-sighted and maybe was expressing frustration around customers getting so wrapped up in the "plan" that they end up waterfalling / micro-managing to death, so I get the point, but there's a way to do this that doesn't sacrifice the plan, too. They probably know that.
maitredusoi 6y ago
I kind of agree with this advice, because, I am using it at present, and we are really moving fast. The most valuable thing is your ideas but only in the present. Ideas are living things that unsmart with time... The more you shape things, the less freedom you will give to yourself about the future. Ideas are moving things in the head and should be kept like this. Stick to just one month planning ahead is largely enought. Like best code is no code at all, over-planning is just wasting time.
jmull 6y ago
It is useful and efficient to defer making decisions until you have to. But it's critical to avoid waiting too long to make decisions. Because that means the decision was to make no decision, and that has only a random chance to be the right one for you. Planning is a big part of how you have the information you need to know when to make a decision and when to defer it. Plenty of work be organized to fit into ~two-week, focused sprints, and can be done efficiently that way. Use your planning to figure out what should and should not be tackled that way. There's also work where it makes no sense at all to do while looking ahead at most only two weeks. For instance, if you have a good experienced architect, a small amount of time spent on a high-level arcitecture will pay you back on even a slightly successful project. Not to mention it will increase your agility. E.g., don't design a sophisticated privilege mechanism until you know you need it. But if there's a reasonable chance a privilege mechanism will be important in the future, know where one would fit in in a way that wouldn't require a substantial rewrite. Now you'll be able to slot in a simple privilege mechanism, if/when you need one, and later replace/evolve that with a sophisticated one, if needed, all quickly and without substantial rewrites.
- dijit 6y ago
  I worked on two very large software projects (AAA games count, right?) and failure to make decisions in a timely manner was one of the largest factors in how much the project suffered, both staff and the product. What I mean by that is, the project which did not decide things on time and tried to save the decision until they knew everything suffered much more than the project which decided in a timely manner and re-evaluated the decision in the rare instance that they were wrong. It was greatly inefficient to have people sitting around not knowing if what they’re working on will even be used because they’re touching something that hadn’t been fully decided on yet, but was required for them to deliver on something else which _had_ been decided. It is sometimes better to decide, iterate and reevaluate. Instead of attempting to defer a decision.
  - maerF0x0 6y ago
    Analysis paralysis (refusing to make a decision until more research is done, to the detriment of a project) is a different error than delaying a decision until beyond the last viable moment.
virgilp 6y ago
Alternatively: https://typicalprogrammer.com/why-dont-software-development-methodologies-work https://typicalprogrammer.com/why-dont-software-development-... and the referenced article, https://archive.is/Rjqh0 https://archive.is/Rjqh0 TLDR: methodology won't fix your project.
Stinkosaurus 6y ago
I’ve seen a few articles posted recently about people bucking at jira, thorough upfront planning, etc. and saying we’re all doing it wrong. The projects I haven’t been rigorous with designs and project execution are the projects that went wrong. I always find myself curious about the author and how they arrived there. Are they junior? Have they worked on multiple teams and/or large projects before? Are their managers terrible?
poof_he_is_gone 6y ago
I think many teams are using a mini-waterfall approach in the guise of agile. If that is how your team approaches things, why not embrace it?
jordache 6y ago
if you are only planning 2 sprints ahead, what if you need to build a feature which requires a lot of requirements gather, user research, even before materializing into tangible stories that developers can execute? If you fail to look beyond that myopic vision, then when a tru need materializes, it may be too late to react.
diiq 6y ago
The agile manifesto is so terse and carefully written -- every word is there for a reason -- and so many people ignore the words they find inconvenient. "Responding to change over following a plan" specifically says "over", not "instead of!" They even say it twice, to avoid misunderstanding: "That is, while there is value in the items on the right, we value the items on the left more." In a document that's only a few sentences long, to repeat a meaning is a little like shouting. Don't value your plan more than your ability to respond to change. But do still have a plan! How will you know if you're responding to change without one?
- UK-Al05 6y ago
  You have a general roadmap rather than fixed stories planned out weeks ahead
mumblemumble 6y ago
This seems like it's really narrowly focused on the software developers' part of an agile project's lifecycle. And I agree, within that scope, you should absolutely shut up and plan the sprint. Product strategists, though, can't afford to be so shortsighted. And most companies don't (and maybe shouldn't) have such a clear separation of roles. I've found that, when your job involves wearing multiple hats, the trick is to pay attention to what hat you're wearing at any given moment. Don't let them all get muddled up. When it all blends together, then the smallest unit available to you to boil is the whole ocean.
jcstauffer 6y ago
This article falls prey to a very common pattern of defining waterfall as "anything that doesn't meet my narrow definition of agile". Since everyone knows that waterfall is a fiction that doesn't work, my opinion is correct. Developing a plan is not waterfall. Designing an Architecture is not waterfall. Agile is about adapting to change as it occurs - how do you know if there is any change if you didn't start with a plan? Good plans and designs account for risks and unknowns and anticipate (certain types) of changes and delay locking into assumptions until necessary. But not having a plan or design is not agile - it's failure.
- tchaffee 6y ago
  > how do you know if there is any change if you didn't start with a plan? Easy. The designs change. The requirements change. A plan is not a design. A plan is not the requirements. A plan is a step by step description of how you are going to implement the designs and requirements, and in what order. And if the designs or requirements change enough, you now have to throw out that part of your plan.
  - lenkite 6y ago
    Obligatory Eisenhower quote: “In preparing for battle I have always found that plans are useless, but planning is indispensable.”
  - kelnos 6y ago
    > A plan is a step by step description of how you are going to implement the designs and requirements, and in what order. I think you have a very narrow definition of "plan" that does not correspond to how most people use it.
    - tchaffee 6y ago
      Could you give some sources where plan means something different in the context of software development methodologies (the topic in question) and that most people in software engineering use that different meaning? More importantly, is there a definition of "plan" in the context of software development where my claim fails? The claim that if requirements or designs change enough, some parts of your plan have to be thrown out? The meaning I used is also a primary definition and often enough the first definition you'll find in dictionaries. [1] [2] [3] [1] https://www.wordnik.com/words/plan https://www.wordnik.com/words/plan [2] https://www.thefreedictionary.com/plan https://www.thefreedictionary.com/plan [3] https://dictionary.cambridge.org/us/dictionary/english/plan https://dictionary.cambridge.org/us/dictionary/english/plan
Jtsummers 6y ago
A plan is not a decision. Creating a plan is not tantamount to deciding too early, it's just a good idea. Committing to the plan (especially a long range one) with no intent to deviate is just stupid, and is the critical flaw of Waterfall. Agile is about responsiveness. In order to be responsive you need tight feedback loops (a reason the idea of sprints and scrum are ok). But are you responding if you don't have a plan? You aren't responding, you're reacting. Make the plan, but don't make a commitment too far out (commitments are kinds of decisions). Respond to changing circumstances and don't let yourself get caught in an action-reaction loop, because you can't react fast enough. At some point you have to think and respond. Also, "decide as late as possible" is better read as "decide at the last responsible moment". If I know that I can get someone hired in two weeks, I can, in the first phrasing, wait until 2 weeks before someone retires to start that process. But it's not responsible. The last responsible moment is probably 2-4 months (at least) before the retirement so people can get trained up and moved around.
bdcravens 6y ago
Does this mean we should abandon expectations for announced features to be ready in our favorite mobile or desktop operating system?
james_s_tayler 6y ago
What you actually need is pragmatism and not dogma. I have a hard deadline external to the company by which time the project, and it is a project, needs to be done of else the company can't sign up new customers. It would be pretty irresponsible of me to only focus on the next two weeks until it was done as I'd have no way of really knowing how close or far it is to completion, how we're tracking and if we need to make adjustments. We did a rough plan. We worked to it. We evaluated how we were tracking and we shifted things in sprints around accordingly. The benefit of agile is introducing short feedback loops that provide information you should be acting on. Good project management also provides benefits. Take the benefits from both, or leave one set of benefits on the table.
csours 6y ago
How is your work funded? If you work in a cost center, any development methodology you use will look like waterfall. If you work on a software product, you may be able to work in a more agile way.
footballnate29 6y ago
not sure this is the best approach... everyone works differently and has various habits. i think it could work for some people but not me dude.
codemac 6y ago
Software estimation is something you can get better at if you practice. Throwing your hands in the air because you or you're team is unskilled in the behavior is just unprofessional.
- tchaffee 6y ago
  Over 60% of software projects go over budget, and often by a lot. What's unprofessional is giving estimates for anything that is not small enough to get done in a couple of weeks. You should also understand why someone asks for estimates. They are trying to manage risk. There are far better ways of managing risk than "Brad said it would take three months". Start out by calling it what it really is. It's not estimating. The end goal is risk management.
  - codemac 6y ago
    > Over 60% of software projects go over budget, and often by a lot. That's so few! Most companies fold, most construction projects go over budget too. I don't see anyone saying we shouldn't try to get good at budgeting construction, or estimating & planning a project before starting. We're not just managing the risk of failure, we're managing days & dollars! I don't understand why software engineering is the one form of engineering we don't think we need to be able to plan.
    - tchaffee 6y ago
      If you are building something you have built before: a bridge for example, then by all means use your prior experience to budget and plan. The majority of what software engineers build is new territory. Estimating and planning are an attempt to manage risk. And a really bad way of managing risk when you've never built that thing before. Actually starting to build the new thing in question will give you far more useful information about possible time and budget than any amount of planning. And you still won't get it very right. We need to stop pretending that building completly new things is actually possible to estimate. We cannot predict the future and trying to do so is unprofessional.
Roboprog 6y ago
Upvoting this more for the discussion than the article. There are a lot of relevant opposing forces in this discussion. Reasonable people can disagree about where in the middle to meet.
kelnos 6y ago
Could not disagree more. It's a disingenuous rhetorical device to say "anything I disagree with is waterfall and therefore wrong". Planning is necessary and useful. The detail of that plan depends on how far out you're going. The next sprint's plan should be very detailed. The next year's plan should be a rough sketch. The next quarter's plan should be somewhere in between. And regardless of the level of detail, those plans can still change if they need to. I've run into enough garbage code and garbage systems to see what happens when people don't plan enough up front. No thanks. It's odd that this bit from the Agile Manifesto is used in part as justification: > Responding to change over following a plan. I don't read that as "don't plan"; I read that as "plan, but expect your plan to change over time".
chrisweekly 6y ago
Related quote: "Plans are worthless, but planning is indispensable." I can't recall where I first encountered this gem, but it resonates.
inerte 6y ago
These discussions are kinda pointless if we don't have a baseline agreement of what's a project or a plan. Is "we will build a CRM" a plan? Is "we will build a mobile CRM app" a twice as detailed plan than the one before?
t0mbstone 6y ago
So much terrible advice in this article, I don't even know where to begin. I guess I'll just flag it as misinformation?
talaketu 6y ago
A project is a plan. ("forward throw")
jlarocco 6y ago
This is 100% anecdote, but IME agile doesn't work well enough to warrant "waterfall shaming" like this. So far, in 25 years of software development, the best track record I've personally seen for on time and on budget was a big defense contractor that had a bunch of senior engineers and a relatively old fashioned waterfall process with some "extreme programming" and agile practices thrown in. It was documentation heavy and a hassle to think things through up front, but it reduced surprises later on, and the rigid documentation and process made it easy for different people to take over work at different stages of the workflow (requirements -> design -> coding -> testing) for each feature. It wasn't perfect, but it was predictable, and I never saw them toss features out at the last minute or deliver a half-assed release with a bunch of minor changes. And I'm sure the response to this will be a dozen people telling me all the companies I've worked for have done agile wrong, and then everybody will have a unique idea on how they should've done it instead... Agile might work great for CRUD websites, but it doesn't seem to work very well for other types of projects, and choosing something else seems reasonable. I guess my point is, even if these projects aren't "real" agile, I don't know if it's a real problem. The goal isn't to be agile, it's to get software developed.
hcarvalhoalves 6y ago
I agree with the author that ideally, you plan only the next sprint. Unfortunately, I'm afraid this doesn't survive the real world, unless you're a small consultancy w/ a great relationship w/ your client, or you're doing work on your own. A company that is any larger cannot afford to rely only on collaboration, it's impossible to have entire teams collaborate w/ each other since the communication overhead explodes [1]. I don't think you can make everybody converge down the line without some planning ahead and definition of some contracts. Another situation is if you have any kind of external deadline (e.g. regulated companies). You can't answer with "we'll figure it out, trust me", you need a plan - even if you happen to have to change it. The point of the Agile Manifesto was responding to change OVER following a plan - not that you shouldn't have a plan in the first place. [1] https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law
jeffdoolittle 6y ago
It's time to move on from Agile. https://jeffdoolittle.com/2020/05/22/dont-disrupt-agile-drop-it/ https://jeffdoolittle.com/2020/05/22/dont-disrupt-agile-drop...
pjmlp 6y ago
Sure, when time and money don't matter. If they matter, most customers will want their money back when 1.0 gets delivered, regardless of what was said during demos.

89 points by mcrittenden 6y ago

Continuous delivery, continuous payments ^.^

I don't think it's good to abandon up-front planning entirely. It's important to know what you're aiming for and to have a plan for getting there. The key thing about an agile approach is to regularly review the plan and be open to changing it as and when new information comes in.

tremon 6y ago
It depends on the level of detail in the plan. The article says to delay the plan, not to skip it. The goal of that is to avoid fleshing out the details of parts that are not relevant to the current focus (with "focus" being defined as the scope of the current sprint). Of course, you need to know the direction of the project. But spending time on details that you cannot directly validate with implementation, risks both wasting time because of invalid assumptions, and risks wasting time because the requirements may change when you get around to implementing it. Remember that "planning a sprint" gets very deep very quickly. It's not just about setting direction, it's about deciding display names, storage types and UX interactions. The point of the article is that that level of planning should not be done months in advance.
- cestith 6y ago
  Your sprint planning is deeper than sprint planning some other places. Some places that at least claim to be doing Scrum will groom the backlog in one meeting, then choose which stories go on the sprint in another. Anything that needs agreement among developers is then tackled in pair programming or fairly ad-hoc "hack sessions". Implementation details, including details of code interfaces, user interfaces, and system interfaces, are left up to the contributor unless there's a need to align effort before that story is done.
jonpurdy 6y ago
Totally correct. This article is on the "totally idealistic" side, and I think it's important to know what is ideal as a benchmark when working in non-ideal situations. Executives and clients like to see timelines and total project estimates. I wrote an article* about this. The idea is that you do some rough planning, applying the principles of Agile story point estimation, and extrapolating a rough/relative timeline. Relative timelines with non-specific dates are useful for getting an idea of the scope and possible time of a project. Helps determine what should be built first, prerequisites, and what other teams might need to be involved (and at what stage). Also useful to get the product managers or executives thinking a bit more deeply about the project and perhaps reconsidering it, or reducing scope if it looks like it will be larger or take longer than expected. Once a project is kicked off, after a few sprints the initial plan can be updated based on the actual velocity of the team. * https://jonpurdy.com/pm-framework/how-to-quickly-plan-and-estimate-an-mvp/ https://jonpurdy.com/pm-framework/how-to-quickly-plan-and-es...
- maitredusoi 6y ago
  > Executives and clients like to see timelines Do they really need them? ;)
  - marcinzm 6y ago
    They need them because they all have their dependencies that they need to manage separate from this project. A client may need to plan training, transitions, budgets, deprecation of old systems, etc.
  - bluGill 6y ago
    Yes. They need to not sell the next version too soon, but start selling soon enough to develop hype. They need to decide if they should invest in updating the previous solution one more time while waiting... They need to decide if the whole is worth the cost or should they develop a different project instead.
  - jonpurdy 6y ago
    Others above me have mentioned the reasons why they need them. But I'll reiterate my emphasis on rough/relative timelines. Exact dates are impossible and the farther away a milestone is, the hazier the date is. As an example, a milestone a month away could be +/- a week, but a milestone a year away could be +/- three months.

douglaswlance 6y ago

This is how you end up with poorly architected code that will be so difficult to change that development will eventually slow down, stop, or begin going backwards.

lumost 6y ago
+1 to this, eventually the sprint tasks are so minor as to not have any impact on the business - but they still take days.
tchaffee 6y ago
Not in my experience. If you are agile, you can fix the architecture as needed. You end up with poorly architected code by deciding to continue building on top of something when it is no longer suited to purpose. That can also happen as a result of big investments in planning. That investment makes it very hard to rationalize architecture changes when the requirements change mid project. Which they very often do. No amount of planning protects you from the unpredictable.

LoSboccacc 6y ago

this may work for internal teams building internal tools, but there's very little chance to find an enlightened client that will sign a scopeless development contract. and it sounds awfully close to being body rental, with all that it entails.

Stinkosaurus 6y ago
I’m on an internal team building internal tools and I think the advice this article gives is absolutely terrible.

silasb 6y ago

What do you think about ShapeUp?

maitredusoi 6y ago
Hey, thanks, didn't saw it before. For who may be concerned : https://basecamp.com/shapeup/shape-up.pdf https://basecamp.com/shapeup/shape-up.pdf
- maitredusoi 6y ago
  ShapeUp TLDR; >> Backlogs are big time wasters too. The time spent constantly reviewing, grooming andorganizing old ideas prevents everyone from moving forward on the timely projects that really matter right now. <<
AgloeDreams 6y ago
I was wondering this as well. This all seems like the complete exact inverse of shaping in some ways and reenforces some others. Generally for small, extremely skilled teams, the Shape Up methods are hyper efficient and can focus on a product/engineering goal, notably it forces management to define deliverables in clear and specific terms that outline a developer's jobs to do and semi-long term goals. This allows the dev to work on building something in whole rather than parts but with defined time and outcome goals. (~6 Weeks in the Shape Up Guidelines). An interesting Shape Up Guideline, (also seen here) is the idea to avoid excessive long term planning or backlogs. Agile is shown as God in this post but..why is Agile so good according to the author? The main advantages is the ability to course correct fast and be reactive but if you are making good work, Agile blinds you from seeing the whole product and causes bad, segmented, low-focus mistakes. If you are TOO agile you may build a DB/API/Logic/Data structure that is too narrow and limiting of the eventual goal. Personally the real danger of this thought process is that it limits developers from understanding the whole of what they may be building. That's downright draining, makes every sprint seem like going to a run to nowhere. This method and plan seems just like an excuse to let management do less and define and shape work to be done less so that you can avoid the dangers of 'Waterfall'.

skellington 6y ago

Ignore this person's advice. It is objectively wrong. How would you build a rocket if you only thought about the next 2-4 weeks? How would you scope the size of any given project if you didn't think about it in totality? Successful development is always a balance of waterfall and sprints except maybe when you're in maintenance mode for long living legacy projects. Waterfall = strategy Sprint = tactics

Jtsummers 6y ago
Waterfall is shit, don't think waterfall. Better is to think about things like work breakdown structures paired with an iterative schedule (aka, sprints). Your WBS establishes the things that you know now, the things that can be done in parallel, and the things that depend on other actions. Your WBS also gives you a rough schedule (but do not take it as gospel because you aren't a prophet). Based on this, you can start prioritizing the work that goes into the iterations. Periodically (with each iteration or after several) you revisit the WBS and determine if what you're doing is keeping you on track, or if it's even still the right structure.
softwarefounder 6y ago
Yep - the hilarious thing is even the most Agile/Sprint heavy consulting companies usually have to succumb to some Waterfall concept in order to provide an estimate or meet a fixed bid.
- tchaffee 6y ago
  Because they aren't good at selling agile. Why do people ask for estimates or fixed bids? It's to manage risk. And how often do projects not go over estimated budget? Even fixed bids are poor at managing risk. Lots of consulting companies will walk away from a fixed bid contract after months of work at the point they realize they will lose money on it. And honestly, what's the quality of work once the contract is no longer profitable? We've all seen it. Everything is a quick hack at that point in a desperate effort to achieve the minimum that could be defensible in court. A fixed bid project means the consulting company and the client have opposing interests: the consulting company wants to get it done as cheaply as possible and will make every shortcut they can get away with. And the client wants every last bit of quality they can squeeze out of the contract for that price. No wonder it so often ends in dissatisfaction for both sides. What are the options for the client when the consultant says "sorry we didn't actually finish and we are out of money"? They either pay more or have to be willing to sue the consulting company. Most companies suck it up and pay more. This is so endemic to the industry that most companies put extra in the budget for software project overruns no matter how tight the fixed bid contract is. So one way to sell agile is to help clients understand how it can help manage risk better than a fixed bid contract or always inaccurate estimates. And how it can be used so that the interests of the consulting company and the client are better aligned.

rubyn00bie 6y ago

Awful advice. This is how you build terrible systems and avoid having to ever look at yourself for building useless crap. You're never looking anywhere but your feet expecting not to run into a wall. Yes, you probably shouldn't build something massive without ever getting feedback, that has nothing to do with sprint vs project planning. People in this industry need to let the worlds "lean" and "agile" just die the death they deserve because they mean literally nothing at this point. It's nothing but lip service for SEO and junior managers.

avojak 6y ago

> Don’t create tickets for things you won’t work on for months, if ever. Yikes. Dropping tickets in the backlog for ideas that pop into my head is a great way to make sure they're not forgotten! The team may decide later that it can be closed, but it opens the door for a conversation and helps collect ideas.

deleted 6y ago
[deleted]
pc86 6y ago
Yeah this suggestion seems like addressing a symptom - a backlog full of useless items - instead of addressing the disease - not having regular backlog grooming sessions where outdated/irrelevant items are either updated/fixed or removed.
majormajor 6y ago
The alternative to this that I use is "don't precisely estimate tickets more than a month out" because if something has 6 other tickets between now and it, things will probably change by then, so a precise fully-fleshed-out estimate will probably just wait time and not be any more valid than the "about a week" one anyway.
almostdeadguy 6y ago
Months down the line your ideas might not even be relevant anymore. On my team, if you put stuff in the backlog, you're responsible for maintaining it. If you're not prepared to accept that responsibility, it belongs in a notebook or a word doc, not the backlog.
deleted 6y ago
[deleted]

sailfast 6y ago

This might be good guidance to avoid getting too deep in the weeds and avoid starting work. Might even avoid the whole "waterfall with sprint" trap, but I'd argue it's quite important for the entire team to have an idea of where they are going, generally before you start work. Agile Roadmapping is a thing that works. Feature prioritization, generally, helps to get the highest value things out the door first, etc. The team doesn't necessarily require those waterfally milestones - it could be as simple as a value delivery statement ("Fastest shopping cart west of the Mississippi" or something) - it doesn't have to be a whole big deal with specifics, but without it i'm not sure how you determine the sprint goals, let alone what the specific technical tasks or stories are going to be without that shared context. Lastly, I'd definitely recommend some sort of longer-term roadmapping exercise up front to determine what the high risk things are so you can solve them first, and test the big hypotheses quickly. That would be a nice lean thing to do. Plan the sprint, sure. Be militant about it if you want. "Shut up and plan the sprint!" But the sprint is not the goal. Delivering increments of value is the goal. The product owner looking at the sprint goal needs to know what they're trying build, and a longer vision can help. I'm not sure the author meant to sound so short-sighted and maybe was expressing frustration around customers getting so wrapped up in the "plan" that they end up waterfalling / micro-managing to death, so I get the point, but there's a way to do this that doesn't sacrifice the plan, too. They probably know that.

maitredusoi 6y ago

I kind of agree with this advice, because, I am using it at present, and we are really moving fast. The most valuable thing is your ideas but only in the present. Ideas are living things that unsmart with time... The more you shape things, the less freedom you will give to yourself about the future. Ideas are moving things in the head and should be kept like this. Stick to just one month planning ahead is largely enought. Like best code is no code at all, over-planning is just wasting time.

jmull 6y ago

It is useful and efficient to defer making decisions until you have to. But it's critical to avoid waiting too long to make decisions. Because that means the decision was to make no decision, and that has only a random chance to be the right one for you. Planning is a big part of how you have the information you need to know when to make a decision and when to defer it. Plenty of work be organized to fit into ~two-week, focused sprints, and can be done efficiently that way. Use your planning to figure out what should and should not be tackled that way. There's also work where it makes no sense at all to do while looking ahead at most only two weeks. For instance, if you have a good experienced architect, a small amount of time spent on a high-level arcitecture will pay you back on even a slightly successful project. Not to mention it will increase your agility. E.g., don't design a sophisticated privilege mechanism until you know you need it. But if there's a reasonable chance a privilege mechanism will be important in the future, know where one would fit in in a way that wouldn't require a substantial rewrite. Now you'll be able to slot in a simple privilege mechanism, if/when you need one, and later replace/evolve that with a sophisticated one, if needed, all quickly and without substantial rewrites.

dijit 6y ago
I worked on two very large software projects (AAA games count, right?) and failure to make decisions in a timely manner was one of the largest factors in how much the project suffered, both staff and the product. What I mean by that is, the project which did not decide things on time and tried to save the decision until they knew everything suffered much more than the project which decided in a timely manner and re-evaluated the decision in the rare instance that they were wrong. It was greatly inefficient to have people sitting around not knowing if what they’re working on will even be used because they’re touching something that hadn’t been fully decided on yet, but was required for them to deliver on something else which _had_ been decided. It is sometimes better to decide, iterate and reevaluate. Instead of attempting to defer a decision.
- maerF0x0 6y ago
  Analysis paralysis (refusing to make a decision until more research is done, to the detriment of a project) is a different error than delaying a decision until beyond the last viable moment.

virgilp 6y ago

Alternatively: https://typicalprogrammer.com/why-dont-software-development-methodologies-work https://typicalprogrammer.com/why-dont-software-development-... and the referenced article, https://archive.is/Rjqh0 https://archive.is/Rjqh0 TLDR: methodology won't fix your project.

Stinkosaurus 6y ago

I’ve seen a few articles posted recently about people bucking at jira, thorough upfront planning, etc. and saying we’re all doing it wrong. The projects I haven’t been rigorous with designs and project execution are the projects that went wrong. I always find myself curious about the author and how they arrived there. Are they junior? Have they worked on multiple teams and/or large projects before? Are their managers terrible?

poof_he_is_gone 6y ago

I think many teams are using a mini-waterfall approach in the guise of agile. If that is how your team approaches things, why not embrace it?

jordache 6y ago

if you are only planning 2 sprints ahead, what if you need to build a feature which requires a lot of requirements gather, user research, even before materializing into tangible stories that developers can execute? If you fail to look beyond that myopic vision, then when a tru need materializes, it may be too late to react.

diiq 6y ago

The agile manifesto is so terse and carefully written -- every word is there for a reason -- and so many people ignore the words they find inconvenient. "Responding to change over following a plan" specifically says "over", not "instead of!" They even say it twice, to avoid misunderstanding: "That is, while there is value in the items on the right, we value the items on the left more." In a document that's only a few sentences long, to repeat a meaning is a little like shouting. Don't value your plan more than your ability to respond to change. But do still have a plan! How will you know if you're responding to change without one?

UK-Al05 6y ago
You have a general roadmap rather than fixed stories planned out weeks ahead

mumblemumble 6y ago

This seems like it's really narrowly focused on the software developers' part of an agile project's lifecycle. And I agree, within that scope, you should absolutely shut up and plan the sprint. Product strategists, though, can't afford to be so shortsighted. And most companies don't (and maybe shouldn't) have such a clear separation of roles. I've found that, when your job involves wearing multiple hats, the trick is to pay attention to what hat you're wearing at any given moment. Don't let them all get muddled up. When it all blends together, then the smallest unit available to you to boil is the whole ocean.

jcstauffer 6y ago

This article falls prey to a very common pattern of defining waterfall as "anything that doesn't meet my narrow definition of agile". Since everyone knows that waterfall is a fiction that doesn't work, my opinion is correct. Developing a plan is not waterfall. Designing an Architecture is not waterfall. Agile is about adapting to change as it occurs - how do you know if there is any change if you didn't start with a plan? Good plans and designs account for risks and unknowns and anticipate (certain types) of changes and delay locking into assumptions until necessary. But not having a plan or design is not agile - it's failure.

tchaffee 6y ago
> how do you know if there is any change if you didn't start with a plan? Easy. The designs change. The requirements change. A plan is not a design. A plan is not the requirements. A plan is a step by step description of how you are going to implement the designs and requirements, and in what order. And if the designs or requirements change enough, you now have to throw out that part of your plan.
- lenkite 6y ago
  Obligatory Eisenhower quote: “In preparing for battle I have always found that plans are useless, but planning is indispensable.”
- kelnos 6y ago
  > A plan is a step by step description of how you are going to implement the designs and requirements, and in what order. I think you have a very narrow definition of "plan" that does not correspond to how most people use it.
  - tchaffee 6y ago
    Could you give some sources where plan means something different in the context of software development methodologies (the topic in question) and that most people in software engineering use that different meaning? More importantly, is there a definition of "plan" in the context of software development where my claim fails? The claim that if requirements or designs change enough, some parts of your plan have to be thrown out? The meaning I used is also a primary definition and often enough the first definition you'll find in dictionaries. [1] [2] [3] [1] https://www.wordnik.com/words/plan https://www.wordnik.com/words/plan [2] https://www.thefreedictionary.com/plan https://www.thefreedictionary.com/plan [3] https://dictionary.cambridge.org/us/dictionary/english/plan https://dictionary.cambridge.org/us/dictionary/english/plan

Jtsummers 6y ago

A plan is not a decision. Creating a plan is not tantamount to deciding too early, it's just a good idea. Committing to the plan (especially a long range one) with no intent to deviate is just stupid, and is the critical flaw of Waterfall. Agile is about responsiveness. In order to be responsive you need tight feedback loops (a reason the idea of sprints and scrum are ok). But are you responding if you don't have a plan? You aren't responding, you're reacting. Make the plan, but don't make a commitment too far out (commitments are kinds of decisions). Respond to changing circumstances and don't let yourself get caught in an action-reaction loop, because you can't react fast enough. At some point you have to think and respond. Also, "decide as late as possible" is better read as "decide at the last responsible moment". If I know that I can get someone hired in two weeks, I can, in the first phrasing, wait until 2 weeks before someone retires to start that process. But it's not responsible. The last responsible moment is probably 2-4 months (at least) before the retirement so people can get trained up and moved around.

bdcravens 6y ago

Does this mean we should abandon expectations for announced features to be ready in our favorite mobile or desktop operating system?

james_s_tayler 6y ago

What you actually need is pragmatism and not dogma. I have a hard deadline external to the company by which time the project, and it is a project, needs to be done of else the company can't sign up new customers. It would be pretty irresponsible of me to only focus on the next two weeks until it was done as I'd have no way of really knowing how close or far it is to completion, how we're tracking and if we need to make adjustments. We did a rough plan. We worked to it. We evaluated how we were tracking and we shifted things in sprints around accordingly. The benefit of agile is introducing short feedback loops that provide information you should be acting on. Good project management also provides benefits. Take the benefits from both, or leave one set of benefits on the table.

csours 6y ago

How is your work funded? If you work in a cost center, any development methodology you use will look like waterfall. If you work on a software product, you may be able to work in a more agile way.

footballnate29 6y ago

not sure this is the best approach... everyone works differently and has various habits. i think it could work for some people but not me dude.

codemac 6y ago

Software estimation is something you can get better at if you practice. Throwing your hands in the air because you or you're team is unskilled in the behavior is just unprofessional.

tchaffee 6y ago
Over 60% of software projects go over budget, and often by a lot. What's unprofessional is giving estimates for anything that is not small enough to get done in a couple of weeks. You should also understand why someone asks for estimates. They are trying to manage risk. There are far better ways of managing risk than "Brad said it would take three months". Start out by calling it what it really is. It's not estimating. The end goal is risk management.
- codemac 6y ago
  > Over 60% of software projects go over budget, and often by a lot. That's so few! Most companies fold, most construction projects go over budget too. I don't see anyone saying we shouldn't try to get good at budgeting construction, or estimating & planning a project before starting. We're not just managing the risk of failure, we're managing days & dollars! I don't understand why software engineering is the one form of engineering we don't think we need to be able to plan.
  - tchaffee 6y ago
    If you are building something you have built before: a bridge for example, then by all means use your prior experience to budget and plan. The majority of what software engineers build is new territory. Estimating and planning are an attempt to manage risk. And a really bad way of managing risk when you've never built that thing before. Actually starting to build the new thing in question will give you far more useful information about possible time and budget than any amount of planning. And you still won't get it very right. We need to stop pretending that building completly new things is actually possible to estimate. We cannot predict the future and trying to do so is unprofessional.

Roboprog 6y ago

Upvoting this more for the discussion than the article. There are a lot of relevant opposing forces in this discussion. Reasonable people can disagree about where in the middle to meet.

kelnos 6y ago

Could not disagree more. It's a disingenuous rhetorical device to say "anything I disagree with is waterfall and therefore wrong". Planning is necessary and useful. The detail of that plan depends on how far out you're going. The next sprint's plan should be very detailed. The next year's plan should be a rough sketch. The next quarter's plan should be somewhere in between. And regardless of the level of detail, those plans can still change if they need to. I've run into enough garbage code and garbage systems to see what happens when people don't plan enough up front. No thanks. It's odd that this bit from the Agile Manifesto is used in part as justification: > Responding to change over following a plan. I don't read that as "don't plan"; I read that as "plan, but expect your plan to change over time".

chrisweekly 6y ago

Related quote: "Plans are worthless, but planning is indispensable." I can't recall where I first encountered this gem, but it resonates.

inerte 6y ago

These discussions are kinda pointless if we don't have a baseline agreement of what's a project or a plan. Is "we will build a CRM" a plan? Is "we will build a mobile CRM app" a twice as detailed plan than the one before?

t0mbstone 6y ago

So much terrible advice in this article, I don't even know where to begin. I guess I'll just flag it as misinformation?

talaketu 6y ago

A project is a plan. ("forward throw")

jlarocco 6y ago

This is 100% anecdote, but IME agile doesn't work well enough to warrant "waterfall shaming" like this. So far, in 25 years of software development, the best track record I've personally seen for on time and on budget was a big defense contractor that had a bunch of senior engineers and a relatively old fashioned waterfall process with some "extreme programming" and agile practices thrown in. It was documentation heavy and a hassle to think things through up front, but it reduced surprises later on, and the rigid documentation and process made it easy for different people to take over work at different stages of the workflow (requirements -> design -> coding -> testing) for each feature. It wasn't perfect, but it was predictable, and I never saw them toss features out at the last minute or deliver a half-assed release with a bunch of minor changes. And I'm sure the response to this will be a dozen people telling me all the companies I've worked for have done agile wrong, and then everybody will have a unique idea on how they should've done it instead... Agile might work great for CRUD websites, but it doesn't seem to work very well for other types of projects, and choosing something else seems reasonable. I guess my point is, even if these projects aren't "real" agile, I don't know if it's a real problem. The goal isn't to be agile, it's to get software developed.

hcarvalhoalves 6y ago

I agree with the author that ideally, you plan only the next sprint. Unfortunately, I'm afraid this doesn't survive the real world, unless you're a small consultancy w/ a great relationship w/ your client, or you're doing work on your own. A company that is any larger cannot afford to rely only on collaboration, it's impossible to have entire teams collaborate w/ each other since the communication overhead explodes [1]. I don't think you can make everybody converge down the line without some planning ahead and definition of some contracts. Another situation is if you have any kind of external deadline (e.g. regulated companies). You can't answer with "we'll figure it out, trust me", you need a plan - even if you happen to have to change it. The point of the Agile Manifesto was responding to change OVER following a plan - not that you shouldn't have a plan in the first place. [1] https://en.wikipedia.org/wiki/Brooks%27s_law https://en.wikipedia.org/wiki/Brooks%27s_law

jeffdoolittle 6y ago

It's time to move on from Agile. https://jeffdoolittle.com/2020/05/22/dont-disrupt-agile-drop-it/ https://jeffdoolittle.com/2020/05/22/dont-disrupt-agile-drop...

pjmlp 6y ago

Sure, when time and money don't matter. If they matter, most customers will want their money back when 1.0 gets delivered, regardless of what was said during demos.