3 ms·

But doesn't specialization naturally push towards the creation of stations? If your cross-functional team contains both a database engineer and a UX designer, I

But doesn't specialization naturally push towards the creation of stations? If your cross-functional team contains both a database engineer and a UX designer, I don't see how either can help with the other's job.

fireflash38 11y ago
I find it's helpful to at least be aware of what is going on with other 'specialists'. That way you can hopefully get some mental (or physical!) prep done long before it gets to you.
kyllo 11y ago
It really can help if they are actively communicating with each other--the user interface is how the data gets into the system, so if the database engineer understands the interface it can provide context for where the data comes from, what it means and how it is used, and that can inform data modeling decisions. Understanding how the data model is laid out, how much structure is needed, what fields are required/optional and what types they are etc. can also inform UI/UX design decisions. And this is an example of two roles that are at opposite ends of the frontend/backend spectrum. For roles whose work products interface directly, there's an even stronger need to collaborate. Specialization is good in that it allows people to focus on using their best skills, but it's bad if it fragments the product development team and inhibits communication and decisionmaking.
- mtviewdave 11y ago
  Certainly active communication and the prevention of siloing can help speed development and reduce defects. But the Penny Game illustrates that backlogs and queuing issues will occur even if each station is in perfect communication with all the others. So you can't eliminate queuing issues with close collaboration and rapid feedback. You can only eliminate it by eliminating dependencies and specialization, which I don't think is possible in modern software development.
  - kyllo 11y ago
    Well yes, on a basic level when you have specialization and division of labor, you will always have dependencies. But when you tighten the feedback loop and shrink the batch size of the work, you make the dependencies smaller and more granular, so the queue gets smaller and fluctuates less, and you get better flow of work through the process. Here's a simple visual that illustrates why this is the case: https://lh4.googleusercontent.com/QGyl3JPoMH1wU0pNoGIsucQCOfLu0R9MKZ4kfj3ioNBA_5gdXLVM_YWQ7kRSlKO3dxzzHGyrhMi68l8MjmYjriUyYRQKbUkVuvw2KMeHWRlSjGQ8ey__OfpC8JDTeDEosA https://lh4.googleusercontent.com/QGyl3JPoMH1wU0pNoGIsucQCOf...

fireflash38 11y ago

I find it's helpful to at least be aware of what is going on with other 'specialists'. That way you can hopefully get some mental (or physical!) prep done long before it gets to you.

kyllo 11y ago

It really can help if they are actively communicating with each other--the user interface is how the data gets into the system, so if the database engineer understands the interface it can provide context for where the data comes from, what it means and how it is used, and that can inform data modeling decisions. Understanding how the data model is laid out, how much structure is needed, what fields are required/optional and what types they are etc. can also inform UI/UX design decisions. And this is an example of two roles that are at opposite ends of the frontend/backend spectrum. For roles whose work products interface directly, there's an even stronger need to collaborate. Specialization is good in that it allows people to focus on using their best skills, but it's bad if it fragments the product development team and inhibits communication and decisionmaking.

mtviewdave 11y ago
Certainly active communication and the prevention of siloing can help speed development and reduce defects. But the Penny Game illustrates that backlogs and queuing issues will occur even if each station is in perfect communication with all the others. So you can't eliminate queuing issues with close collaboration and rapid feedback. You can only eliminate it by eliminating dependencies and specialization, which I don't think is possible in modern software development.
- kyllo 11y ago
  Well yes, on a basic level when you have specialization and division of labor, you will always have dependencies. But when you tighten the feedback loop and shrink the batch size of the work, you make the dependencies smaller and more granular, so the queue gets smaller and fluctuates less, and you get better flow of work through the process. Here's a simple visual that illustrates why this is the case: https://lh4.googleusercontent.com/QGyl3JPoMH1wU0pNoGIsucQCOfLu0R9MKZ4kfj3ioNBA_5gdXLVM_YWQ7kRSlKO3dxzzHGyrhMi68l8MjmYjriUyYRQKbUkVuvw2KMeHWRlSjGQ8ey__OfpC8JDTeDEosA https://lh4.googleusercontent.com/QGyl3JPoMH1wU0pNoGIsucQCOf...