Question on Scrum Dev Teams (Nexus)
Hi all,
I was tasked to be a PO for company system improvements. Basically our Scrum project was brought about by a Lean project which aims to create a web-based data and work management tool that would replace 3 applications we're using to cut costs (think SAP meets JIRA). I took the risk of being a PO since it will help me in taking my assessments in the long run and ask more questions on top of reading the scrum guide as I immerse myself in the project.
The software we designed will have many features. As I mentioned, it will incorporate 3 applications we've been using. The top management didn't give us a hard deadline but finishing it at the soonest feasible time will always be better (but not at the expense of quality of course!).
The questions are:
The idea I have in mind is to set-up the work as a nexus. There will be teams working on each feature then we stitch everything up. Has anyone tried this? If so, how were you able standardize code structure? Should you, as PO intervene if there are deviations in your suggested format? And as PO, can you even suggest a format?
Note: I've worked in a previous company before where dev teams just coded whatever they wanted and we had trouble in troubleshooting. It took us quite a long while to fix things because we had to figure out how the previous dev teams worked on their codes. What happened was, a disgruntled staff went on a hacking spree before he left the company (knowing beforehand the infrastructure was faulty) and as a new dev person way back, we were cleaning up his mess. Bottomline: I don't want the same thing to happen.
Since we're not time bound, I'm also thinking of just using just one group. It will ensure that there's a uniform code structure but it will take time to finish.
Hi,
If you want to execute Nexus in your environment, please consider phrase i mentioned before.
It notices that the difficulties faced by each company exploring to develop product are different and unique. As such any technique that look for answering questions that it does not know before, and so not able to concern to answer, is likely to become extremely complex in itself and ultimately doomed to fail. The problems at scale are even bigger and your direction even more unique. Nexus framework provides some solutions to typical and universal problems met when using Scrum at scale. It will give you a way of working so you can use empiricism to inspect and adapt to discover answers to your own unique challenges.
The idea I have in mind is to set-up the work as a nexus.
What value can be delivered by just one team first, before an attempt is made to scale? My advice is to look very hard indeed for this MVP, and to explain the importance of doing so to stakeholders.
There will be teams working on each feature then we stitch everything up
Teams in a Nexus should have the competence to integrate their work (“stitch everything up”) on an ongoing basis. This is instrumental to risk mitigation and transparency. Planning and managing the associated dependencies is very hard to do without a proven agile delivery capability at a single team level.