Pelayo Arbués

Recent Notes

See 103 more →

Shape-Up

Aug 25, 2023338 min read

Shape-Up

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-23 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-23 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-23 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-23 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-23 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-24 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-25 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-25 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-25 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-25 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-25 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-25 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-25 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-25 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-25 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-25 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-25 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-25 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-26 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-27 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-28 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-28 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-28 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-28 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-28 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-28 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

author: basecamp.com title: “shape-up” date: 2024-09-28 tags:

  • articles
  • literature-note

rw-book-cover

Metadata

Highlights

  • The way a team works has an enormous influence on what it can do. The process, the methods, the practices, the approach, the discipline, the trust, the communication style, the pace. The way—the how—is foundational and fundamental. (View Highlight)
  • focus on “hammering” the scope to fit within a given time budget was born under these constraints. (View Highlight)
  • in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The (View Highlight)
  • we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves. (View Highlight)
  • 14 (View Highlight)
  • appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite. (View Highlight)
  • we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. (View Highlight)
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously. (View Highlight)
  • At every step of the process we target a specific risk: the risk of not shipping on time. (View Highlight)
  • Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do? (View Highlight)
  • We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first. (View Highlight)
  • we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible. (View Highlight)
  • When we shape the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes. (View Highlight)
  • Over-specifying the design also leads to estimation errors. Counterintuitive as it may seem, the more specific the work is, the harder it can be to estimate. (View Highlight)
    • Note: This might be one of the major flaws of waterfall
  • When the scope isn’t variable, the team can’t reconsider a design decision that is turning out to cost more than it’s worth. (View Highlight)
  • projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means. (View Highlight)
  • Team members don’t have enough information to make trade-offs. They don’t know what to include or leave out (View Highlight)
  • under-specified projects naturally grow out of control because there’s no boundary to define what’s out of scope. (View Highlight)
  • Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits 24 (View Highlight)
  • everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge. (View Highlight)
  • Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. (View Highlight)
  • shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out (View Highlight)
  • Shaping is a closed-door, creative process. You might be alone sketching on paper or in front of a whiteboard with a close collaborator. There’ll be rough diagrams in front of you that nobody outside the room would be able to interpret. When working with a collaborator, you move fast, speak frankly and jump from one promising position to another. It’s that kind of private, rough, early work. (View Highlight)
  • You can’t really schedule shaping work because, by its very nature, unshaped work is risky and unknown. For that reason we have two separate tracks: one for shaping, one for building. During any six week cycle, the teams are building work that’s been previously shaped and the shapers are working on what the teams might potentially build in a future cycle. Work on the shaping track is kept private and not shared with the wider team until the commitment 26 (View Highlight)
  • has been made to bet on it. That gives the shapers the option to put work-in-progress on the shelf or drop it when it’s not working out. (View Highlight)

Graph View

Backlinks

  • No backlinks found

Now Reading

See 1138 more →