September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
Seems you partly answer your question already: you know what components are needed to be ported. So start with the sprint to test each of them, and define if additional work is needed. Based on your findings you'll build backlog for fixes and add them to the next sprint.
"Hit and Trail" was called long time ago "The Microsoft Effect". What you describe will not work not matter you try to do to fix it? Why? Because one of the pillars of Agile is quality. Agile in software was created with based on quality. And you are attempting against quality. Agile was created (in software) as an evolution of object orientation and object orientation is based on software engineering and it is impossible to get robust software engineering environments without quality. So, the problem you have must be solve from the view of architecture and quality. I am not saying that you have to stop everything or you have to write documents like a "Bible" in extension. But you have to take a moment (perhaps as long as one sprint) to review architecture. If you do that, I am sure you will solve your problem.
Use a spike to reduce uncertainty and learn. That is a common technique when we have a complex work item which we don't know how to tackle. The spike is time-boxed to a couple of days at most and will hopefully reduce the number of "wrong" paths we would take.
I agree with Kiron- plan these as research spikes with the associated points for the sprint. Once you have identified a solution then create the user stories needed to do the work based on the analysis done in the spike.
I agree with colleagues about the analysis task before implementation phase.
As a suggestion, during the research spikes take into consideration the relationship between components to prioritize the most important and indispensable. Depending on how they will be ported, the process of converting the other related components may be influenced for a longer or shorter execution time. The risk management process for the new architecture can help you map the most priority components to begin migration.
Hope this helps.
This sounds closest to our context. Thanks
Do we treat Spike as a special Tech Story in the current sprint and based on the success/failure of it, we pull/push additional work to/from backlog during the course of sprint?
We tried doing spikes one sprint in advance but it is getting complicated. We are inherting a legacy application with about 7-8 years old code. Trying to stand the application as-is in our more secure/protected env and in the processing hitting issues. Once the application is up, we can plan much more structured refactoring and follow regular sprints.
Correct - a spike can be used as an experiment to test a given hypothesis (almost like a mini-MVP). If you end up learning that there are no viable options, that might be cause to revise that portion of the solution approach or to negotiate with a PO for pushing back that work item till later. If it is a critical dependency for future features, then how you proceed really depends as you don't want to repeat Einstein's definition of insanity :-)
This is something very common in software development that usually happens at the beginning of a software development initiative when you start pretty much from scratch. At this stage everything is trail and error and it is extremely hard to plan and commit to anything.
This demonstrate that in reality Scrum/Agile is not suitable for some some projects that involve software development such as data migration and application migration.
But software development in general is trail and error. When a developer starts working on a task he pretty much starts trying things to implement the requirement then he does his own tests and if the tests are not fully successful he may end up trying another solution.
You problems are purely technical and normal things that happen in software development. There is nothing you can do about it and using Scrum makes things much worse.
The nature of the software development work makes it impossible to commit to anything and as such accurately estimating work is impossible. At the beginning of the project is even harder and while you progress things get easier but software developers can never fully commit to work. That's a fact and there is nothing you can do about it.
Was going to share similar thoughts as Kiron; to utilize a spike story as opportunity to get a foothold on the direction. Ensure it is understand that the spike is to have an output that is able to be showcased to the group, i.e., some quantifiable measure or proven, with all available information, of the direction chosen with the rationale and outcomes tied back to the epic or value stream/prop.
Also the technical experts when are doing trail and error can't estimate how long it would take and also if they think they have found a good solution after a while they may discover that the solution is not good so they have to go back to the drawing board.
For such situations you need some technical/solution architects and other senior technical experts to work outside Agile/Scrum and come up with some sort of design/architecture to try to implement. Scrum is a disaster when it comes to this kind of work because there is an obsession on delivering something in 2 weeks.
When you are migrating an application or data you can't deliver in iterations anyway, you either deliver everything in one go or you deliver nothing.
Please login or join to reply