DEV Community

Discussion on: How we organize our software development process

Collapse
 
recursivefaults profile image
Ryan Latta

Something that I think is pretty interesting in this article that you're describing is the shift from the process at AirBnB is optimizing for individual developers to optimizing for teams and priority.

There's a lot of deeply unintuitive things about teams and such that I think you all are seeing. Really great teams are far better than the sum of their parts. So if we optimize individual performance, we lose that. On the other hand if we emphasize teams and more or less ignore individuals then we worry we aren't effecient.

While it wasn't in the article, connecting teams back to the desired goals and results behind their work is one of those things that unlocks a lot of their ingenuity and ability to complement each other's weakness. When they know the target, they can come up with alternatives that incorporate the best of the group instead of a single specialization.

Anyway, this is a topic near and dear to me. Thanks for sharing.

Collapse
 
dangerous profile image
Tommy DANGerous

"While it wasn't in the article, connecting teams back to the desired goals and results behind their work is one of those things that unlocks a lot of their ingenuity and ability to complement each other's weakness. When they know the target, they can come up with alternatives that incorporate the best of the group instead of a single specialization"

Can you share more about this? I’d love to learn! What are some tactics you do to "connecting teams back to the desired goals and results behind their work"?

Collapse
 
recursivefaults profile image
Ryan Latta

There's quite a lot of techniques to do it, but a few that tend to be pretty easy to get started with are:

  • Sprint Goals
  • Product Vision
  • Impact Maps

Sprint Goals are pretty simply a few statements about what the REAL purpose of a sprint is. Too many teams are trapped in just delivering scope, so when we are clear about WHY, now teams can actually come up with options and adjust.

Product vision is pretty well beat to death in every book on agile development, but it get skipped a bit, or is left behind in some powerpoint deck. The idea is to come up with a compelling vision or mission that represents the product and continually bring it up in conversations about upcoming work. Continually reorient back towards it.

Impact mapping is one of my more favored scoping techniques and it starts with a vision, then goals, then gets to scope. That means everything we do is directly tied to a measurable goal that moves us to a vision. This means conversations about what we're doing and why are fluid and we don't wind up debating a lot of pet features.

There're more ways to do this like discovery workshops and the like, but those are typically not close to development activities.

Thread Thread
 
dangerous profile image
Tommy DANGerous

"continually bring it up in conversations about upcoming work. Continually reorient back towards it." - Love it