4 ms·

The most balanced and sensible paradigm I've come across is Basecamp's Shape Up[0]. I led an engineering team building validated systems that supported GxP pro

The most balanced and sensible paradigm I've come across is Basecamp's Shape Up[0]. I led an engineering team building validated systems that supported GxP processes in life sciences and found that a Shape Up-like process produced the best balance between delivering software that could be validated[1] and speed. I only came across it after several years of trial and error, but I was amazed at how it almost exactly described what we ended up doing. A side effect is that work-life balance is amazing once you get this process working. If you know exactly how much work you need to do and when it needs to get done by for the next 4-6 weeks, then you can pace yourself much better. When you plan 6 weeks at a time, someone going out sick or taking some time off has less of an impact than when you plan 1 or 2 weeks at a time. The customers and end-users know what to expect and when they'll get it; everyone gets more predictability in the process. Yes, it takes 1-2 weeks of planning at the outset, but we used that downtime for the engineering team to catch up on tech, build some experiments, work on side projects, or do research. (No refactoring since the validated process requires us to plan and document all code changes that make it into production) I recommend it for any team that wants some sanity in the processes. [0] https://basecamp.com/shapeup https://basecamp.com/shapeup [1] Validated in this context means that every feature, function, and infrastructure component can be traced back to a specification through the full lifecycle from design to install to post-install verification and operations.

Zigurd 3y ago
There's a very practical reason why waterfall fails in most software development projects: in the waterfall model you do project planning and budgeting based on the specifications you write. I'm not arguing against the specifications other than to say that in a lot of cases in modern software development you haven't got time to write all of those specs to the proper level of detail. But then you go on to do a critical path analysis. That requires assigning people to tasks and having detailed task descriptions at a very early stage of the project. The odds of that being right are very slim. It can tell you at best whether your project is plausible. Again I have no problem with that. But once you start managing the project, the agile approach of assigning people to tasks in iteration planning meetings works a lot better than trying to stick to your painstakingly created critical path analysis. You also don't need highly detailed task descriptions and implementation plans until you get to your iteration planning meetings. Then they are crucial. But putting off that work until you need it saves a lot of time at project start.
- CharlieDigital 3y ago
  > The odds of that being right are very slim This really depends on the industry and the domain experience of the team. The deeper the domain experience, the more likely you are to get it right. It also helps to limit the scope of what you do (big part of the Shape Up process). Works well for life sciences, for example, where we're replacing a paper process with a digital process. Not so well for SV startups where first time founders are trying to figure out product-market-fit. > ...saves a lot of time at project start Often just shifting the work to a later cycle to get it right. In life sciences when supporting a GxP process, validation (which is rooted in documentation and specifications) is unavoidable. In that environment, figuring out how to move fast despite the constraints yielded a Basecamp Shape Up like process. I think every team that believes big-A Agile is The One True Way take a look at Shape Up.
  - Zigurd 3y ago
    ,> This really depends on the industry... That's correct. One of the commonest ways for agile to fail is to apply it to the wrong kind of project. If you have strong dependencies between tasks and things like lead times for hardware you will want to do project planning that can take those things into account early in the project.
  - jacobr1 3y ago
    One of the bigger issues with Scrum style agile, is that very rarely does it reach the maturity where "everything is delivered within a sprint." Even if you complete all the cards without carryover or other issues, the product isn't necessarily shippable. So in practice you some form of release planning, often quarterly to align with the business, that gets overlaid. The big insight with ShapeUp for me, was that is really is more a change in how to approach Release planning, than sprint/iteration process. You really can ship an end-to-end feature for a wide variety of software products in a 6 week timeframe, and it is short enough to give a lean focus, outcome oriented on delivery rather than just shipping a code increment. Two weeks is too tight a timeframe to meaningfully pivot larger projects, or make decision about overall feasibility. There always is another 2-weeks to expand upon your sunk costs. But again 6 weeks hits more of a sweet spot in being able to step back and make roadmap tradeoffs.
MetaWhirledPeas 3y ago
> A side effect is that work-life balance is amazing once you get this process working. If you know exactly how much work you need to do and when it needs to get done by for the next 4-6 weeks, then you can pace yourself much better. For you this may sound like heaven, but for me (possibly ADHD?) it sounds a little closer to hell. It reminds me of my school days; short assignments were fine. Large multi-week projects were a bit terrifying. So in short, you need to account for a multitude of personality types. People with shorter attention spans need shorter deadlines. People with longer attention spans need less pampering. Pick something that works for both.
- CharlieDigital 3y ago
  They're not multi-week projects per se; more like: 1. "This is a big feature we are shipping in 6 weeks" 2. "Here are the 20-40 tasks that need to be completed to implement this feature" The only difference is that we've fully planned out 6 weeks of work rather than planning 1 or 2 weeks at a time. I would summarize and say that the difference isn't in the execution; the difference is in the planning. My experience is that it's the opposite for those with short attention spans; because everything is planned out, the engineering team can then kind of walk up to the "buffet table" and pick what they want to work on since you have the full spread. Within that 6 week cycle, we would still build, iterate, and test internally. It's not one giant ticket, but still broken down into parts. At the end of the 6 week cycle, there's a very clear picture of what will be released and there's a formal validation and release period that mostly involves testing and ensuring that the product meets the defined specification.
  - MetaWhirledPeas 3y ago
    This sounds a lot like Scrum with longer-than-average sprints. Or maybe its Kanban? I've lost the patience to pay attention to the intricacies of them all. The length of the cycle is going to vary based on your product and your customer. There's a lot to be gained by delivering rapidly if you can do it, with feature flags to hide what you want to keep hidden. 6 weeks for a release is a pretty long time to wait for most projects. Personally, this is my favorite approach, and maybe you'd agree to a point: 1. Team that is focused on the one "big feature" at a time. Maintainers operate on a different team. 2. Big feature should have a planned duration that spans multiple iterations, but not too long. 6 weeks sounds reasonable. 3. Test and deliver as rapidly as you can based on your capabilities. If all your testing is automated, consider Continuous Integration at the very least. If you rely on a team of testers then come up with an iteration length that gives testers enough time to regression test a snapshot of the code to prepare a release candidate, while still allowing enough time in-between for testing new changes. The reason 3 is important is because, whenever possible, you want to avoid the terrifying mountain of risk that comes with releasing code that has not seen the light of day for months on end. Typically the longer you spend preparing a release, the longer you have everyone panicking when the deadline is approaching and this massive release has a massive backlog of bugs.

Zigurd 3y ago

There's a very practical reason why waterfall fails in most software development projects: in the waterfall model you do project planning and budgeting based on the specifications you write. I'm not arguing against the specifications other than to say that in a lot of cases in modern software development you haven't got time to write all of those specs to the proper level of detail. But then you go on to do a critical path analysis. That requires assigning people to tasks and having detailed task descriptions at a very early stage of the project. The odds of that being right are very slim. It can tell you at best whether your project is plausible. Again I have no problem with that. But once you start managing the project, the agile approach of assigning people to tasks in iteration planning meetings works a lot better than trying to stick to your painstakingly created critical path analysis. You also don't need highly detailed task descriptions and implementation plans until you get to your iteration planning meetings. Then they are crucial. But putting off that work until you need it saves a lot of time at project start.

CharlieDigital 3y ago
> The odds of that being right are very slim This really depends on the industry and the domain experience of the team. The deeper the domain experience, the more likely you are to get it right. It also helps to limit the scope of what you do (big part of the Shape Up process). Works well for life sciences, for example, where we're replacing a paper process with a digital process. Not so well for SV startups where first time founders are trying to figure out product-market-fit. > ...saves a lot of time at project start Often just shifting the work to a later cycle to get it right. In life sciences when supporting a GxP process, validation (which is rooted in documentation and specifications) is unavoidable. In that environment, figuring out how to move fast despite the constraints yielded a Basecamp Shape Up like process. I think every team that believes big-A Agile is The One True Way take a look at Shape Up.
- Zigurd 3y ago
  ,> This really depends on the industry... That's correct. One of the commonest ways for agile to fail is to apply it to the wrong kind of project. If you have strong dependencies between tasks and things like lead times for hardware you will want to do project planning that can take those things into account early in the project.
- jacobr1 3y ago
  One of the bigger issues with Scrum style agile, is that very rarely does it reach the maturity where "everything is delivered within a sprint." Even if you complete all the cards without carryover or other issues, the product isn't necessarily shippable. So in practice you some form of release planning, often quarterly to align with the business, that gets overlaid. The big insight with ShapeUp for me, was that is really is more a change in how to approach Release planning, than sprint/iteration process. You really can ship an end-to-end feature for a wide variety of software products in a 6 week timeframe, and it is short enough to give a lean focus, outcome oriented on delivery rather than just shipping a code increment. Two weeks is too tight a timeframe to meaningfully pivot larger projects, or make decision about overall feasibility. There always is another 2-weeks to expand upon your sunk costs. But again 6 weeks hits more of a sweet spot in being able to step back and make roadmap tradeoffs.

MetaWhirledPeas 3y ago

> A side effect is that work-life balance is amazing once you get this process working. If you know exactly how much work you need to do and when it needs to get done by for the next 4-6 weeks, then you can pace yourself much better. For you this may sound like heaven, but for me (possibly ADHD?) it sounds a little closer to hell. It reminds me of my school days; short assignments were fine. Large multi-week projects were a bit terrifying. So in short, you need to account for a multitude of personality types. People with shorter attention spans need shorter deadlines. People with longer attention spans need less pampering. Pick something that works for both.

CharlieDigital 3y ago
They're not multi-week projects per se; more like: 1. "This is a big feature we are shipping in 6 weeks" 2. "Here are the 20-40 tasks that need to be completed to implement this feature" The only difference is that we've fully planned out 6 weeks of work rather than planning 1 or 2 weeks at a time. I would summarize and say that the difference isn't in the execution; the difference is in the planning. My experience is that it's the opposite for those with short attention spans; because everything is planned out, the engineering team can then kind of walk up to the "buffet table" and pick what they want to work on since you have the full spread. Within that 6 week cycle, we would still build, iterate, and test internally. It's not one giant ticket, but still broken down into parts. At the end of the 6 week cycle, there's a very clear picture of what will be released and there's a formal validation and release period that mostly involves testing and ensuring that the product meets the defined specification.
- MetaWhirledPeas 3y ago
  This sounds a lot like Scrum with longer-than-average sprints. Or maybe its Kanban? I've lost the patience to pay attention to the intricacies of them all. The length of the cycle is going to vary based on your product and your customer. There's a lot to be gained by delivering rapidly if you can do it, with feature flags to hide what you want to keep hidden. 6 weeks for a release is a pretty long time to wait for most projects. Personally, this is my favorite approach, and maybe you'd agree to a point: 1. Team that is focused on the one "big feature" at a time. Maintainers operate on a different team. 2. Big feature should have a planned duration that spans multiple iterations, but not too long. 6 weeks sounds reasonable. 3. Test and deliver as rapidly as you can based on your capabilities. If all your testing is automated, consider Continuous Integration at the very least. If you rely on a team of testers then come up with an iteration length that gives testers enough time to regression test a snapshot of the code to prepare a release candidate, while still allowing enough time in-between for testing new changes. The reason 3 is important is because, whenever possible, you want to avoid the terrifying mountain of risk that comes with releasing code that has not seen the light of day for months on end. Typically the longer you spend preparing a release, the longer you have everyone panicking when the deadline is approaching and this massive release has a massive backlog of bugs.