4 ms·
I would love for you to expand a bit on what you think is missing beyond: - It's for cross discipline teams to be able to unblock each other, communicate and f
by Folcon 2y ago
I would love for you to expand a bit on what you think is missing beyond:
- It's for cross discipline teams to be able to unblock each other, communicate and feedback progress and updates.
Do you see the teams as temporary? Or longer term?
How large or small a team size are you thinking?
For example would your approach be:
- Build a team to tackle a feature or solve a specific area
Just curious to get a bit more understanding about what your envisioning =)...
- dijit 2y agoExactly, construct a team to tackle a large enough problem, disband the team once the challenge is met. Hopefully the challenge statement concludes that sufficient documentation of the outcome is created. But, I really don’t have all the answers, I just think cutting across disciplines is fruitless when you put 10 devs in a room and they work on 10 completely different things, which is how Agile is practiced where I have worked.
- cassianoleal 2y agoThat can work in some environments, depending on expected support model. A lot of organisations are doing product (vs project) development though, and personally I find it superior. Teams that are responsible for running and operating the product they built are generally more incentivised to produce quality software. Nobody likes to be interrupted in the middle of a technical session or, even worse, in the middle of the night, because their application crashed - so they learn to build resilience in. They start optimising for operability, maintainability and extensibility - since they will be the ones operating, maintaining and extending. The above is not the solution to all software delivery issues, and is not something that works everywhere, every time. Where it does, it produces better outcomes.