Andrew SoswaTechnology leader| Leading global financial institutionElk Grove Village, Il, United States
I think that some over here lost reality on Scrum and want to make it written in stone methodology that never changes or adapts.
The problem is not Scrum, the problem is that some don't consider it Agile methodology and want to box it like a waterfall.
I give presentations that waterfall is better suited for infrastructure/network implementation projects for the reasons that Kiron mentioned.
On the other hand, I worked on client(waterfall) and developing firm(Scrum) methodology. Internally, we run Scrum with releases until one big bang release to the client - at much better satisfaction because we were able to adapt, experiment, and grow as a team.
So, I also worked on the project that I call Strategic Rapid Response, where the vendor (phone infrastructure) run own schedule and did not jive with my firm waterfall schedule. Their process did not even appear waterfall to us, although to them it was. They threw stuff on us on their schedule (you know who I am talking about, you have these type of vendors) and we had Rapidly adjust to create a strategy & schedule based on the piece of info that they delivered. So much fun you wouldn't your worst enemy to work on that project.
...
1 reply by Adrian Carlogea
Mar 04, 2020 4:48 PM
Adrian Carlogea
...
"Internally, we run Scrum with releases until one big bang release to the client "
Yes, despite what others say Waterfall and Scrum can coexist and this is probably the most typical scenario.
When you are delivering a brand new solution or you do a major change to an existing one you have to work months or sometimes years before you can deliver something that is usable. These kind of projects are Waterfall by default no matter how hard you try to make them Agile. :)
However if the company that delivers only uses Scrum or the customer asks for it (less frequent) then it would be used even if the project is waterfall.
In practice Scrum ends up being just a method of managing the tasks and using specific software tools such as Jira.
Scrum can really be used in the cases in which you have a working system that you continuously maintain and improve.
I think that some over here lost reality on Scrum and want to make it written in stone methodology that never changes or adapts.
The problem is not Scrum, the problem is that some don't consider it Agile methodology and want to box it like a waterfall.
I give presentations that waterfall is better suited for infrastructure/network implementation projects for the reasons that Kiron mentioned.
On the other hand, I worked on client(waterfall) and developing firm(Scrum) methodology. Internally, we run Scrum with releases until one big bang release to the client - at much better satisfaction because we were able to adapt, experiment, and grow as a team.
So, I also worked on the project that I call Strategic Rapid Response, where the vendor (phone infrastructure) run own schedule and did not jive with my firm waterfall schedule. Their process did not even appear waterfall to us, although to them it was. They threw stuff on us on their schedule (you know who I am talking about, you have these type of vendors) and we had Rapidly adjust to create a strategy & schedule based on the piece of info that they delivered. So much fun you wouldn't your worst enemy to work on that project.
"Internally, we run Scrum with releases until one big bang release to the client "
Yes, despite what others say Waterfall and Scrum can coexist and this is probably the most typical scenario.
When you are delivering a brand new solution or you do a major change to an existing one you have to work months or sometimes years before you can deliver something that is usable. These kind of projects are Waterfall by default no matter how hard you try to make them Agile. :)
However if the company that delivers only uses Scrum or the customer asks for it (less frequent) then it would be used even if the project is waterfall.
In practice Scrum ends up being just a method of managing the tasks and using specific software tools such as Jira.
Scrum can really be used in the cases in which you have a working system that you continuously maintain and improve.
...
1 reply by Kiron Bondale
Mar 04, 2020 5:04 PM
Kiron Bondale
...
Andrew -
I might challenge the statement that waterfall is the default when delivering a brand new solution as that negates the whole approach of using Scrum or some other agile delivery method to produce MVPs (to test new product business viability) and MMRs (to capture market share with a stripped down, but mass market ready version of the product).
I would agree that a replacement of an existing product is likely to require a prolonged timeframe to get to an MBI (Minimum Business Increment) and that might follow a Water-Scrum-Fall or Scrum-Fall approach.
"Internally, we run Scrum with releases until one big bang release to the client "
Yes, despite what others say Waterfall and Scrum can coexist and this is probably the most typical scenario.
When you are delivering a brand new solution or you do a major change to an existing one you have to work months or sometimes years before you can deliver something that is usable. These kind of projects are Waterfall by default no matter how hard you try to make them Agile. :)
However if the company that delivers only uses Scrum or the customer asks for it (less frequent) then it would be used even if the project is waterfall.
In practice Scrum ends up being just a method of managing the tasks and using specific software tools such as Jira.
Scrum can really be used in the cases in which you have a working system that you continuously maintain and improve.
Andrew -
I might challenge the statement that waterfall is the default when delivering a brand new solution as that negates the whole approach of using Scrum or some other agile delivery method to produce MVPs (to test new product business viability) and MMRs (to capture market share with a stripped down, but mass market ready version of the product).
I would agree that a replacement of an existing product is likely to require a prolonged timeframe to get to an MBI (Minimum Business Increment) and that might follow a Water-Scrum-Fall or Scrum-Fall approach.
Kiron
...
1 reply by Adrian Carlogea
Mar 04, 2020 5:30 PM
Adrian Carlogea
...
Hi Kiron,
You may be right but when you are developing or implementing a new solution you can't deliver software in small increment as it would usually take a very long time before you have a useful workable product.
In many cases you either deliver everything in one go or you deliver nothing. For instance the customer may be using a legacy old system that is in the process of being replaced by a new system. Before the delivery the new solution must be able to offer at least all the functionality of the old one otherwise the users would not be able to do their work anymore.
Yes internally you can plan sprints and complete small chunks of work but nobody really cares until everything is ready.
I might challenge the statement that waterfall is the default when delivering a brand new solution as that negates the whole approach of using Scrum or some other agile delivery method to produce MVPs (to test new product business viability) and MMRs (to capture market share with a stripped down, but mass market ready version of the product).
I would agree that a replacement of an existing product is likely to require a prolonged timeframe to get to an MBI (Minimum Business Increment) and that might follow a Water-Scrum-Fall or Scrum-Fall approach.
Kiron
Hi Kiron,
You may be right but when you are developing or implementing a new solution you can't deliver software in small increment as it would usually take a very long time before you have a useful workable product.
In many cases you either deliver everything in one go or you deliver nothing. For instance the customer may be using a legacy old system that is in the process of being replaced by a new system. Before the delivery the new solution must be able to offer at least all the functionality of the old one otherwise the users would not be able to do their work anymore.
Yes internally you can plan sprints and complete small chunks of work but nobody really cares until everything is ready.
...
1 reply by Kiron Bondale
Mar 05, 2020 8:14 AM
Kiron Bondale
...
That kind of refutes the success which Zappos.com had with their MVP which was extremely bare bones yet enabled them to know that there was a viable business opportunity for selling shoes online.
I'd agree that for well established solutions, you are looking at an MMR more than an MVP, but for truly novel products, an MVP is often still sufficiently usable to gain market share and to gain confidence that the business idea is viable.
Kiron
Saving Changes...
Deepesh RammoorthyICT Project Manager ( PMP®AgilePM®Certified ScrumMaster® (CSM®))| Australian Red Cross Blood ServiceTarneit, Vic, Australia
I agree with Stephane. Why not just use the Agile Mindset?
Think Infrastructure project - e.g. Data Centre Relocation
There will be elements of waterfall and sequential delivery like signing contracts, procuring manpower, On-boarding implementation partners , Statement of Works etc . However once you start the implementation, you can always use agile ceremonies for implementation .
You can definitely break up your implementation steps into user stories or simply do a task -based delivery without tagging it as Scrum - just call it iterative delivery. Put your implementation scope {stuff to be migrated to the new data center} into a backlog, prioritize that backlog , execute in sprints of two weeks , Have a showcase and retrospective at the end of the sprints.
The achievements or showcases for the sprints could be around
1) infrastructure successfully moved to the new data center and working satisfactorily within that sprint .
2) Infrastructure moved to an upgraded platform or migrated to cloud . e.g your target VMWare Vsphere environment is of the latest vendor supported version in the new area than your current area and you have just moved a few workloads onto that new platform.
3) Legacy hardware or Operating system decommissioned. Maybe in this sprint you have taken out a legacy hardware firewall or router out of service . Maybe you have decommissioned a server running Windows 2003/2008. You can showcase that this means that you have mitigated the risk of security vulnerability targeting that legacy hardware and operating system.
or for tasks requiring a continuous flow but not to be constrained by a strict timeline of 2 week sprints , think Kanban... For example you are establishing an AWS Direct Connect environment between your on-premise cloud and AWS cloud . Obviously directConnect is likely to take a few weeks . Why not break that down into discrete tasks and track it through a Kanban type Wall? Saving Changes...
You may be right but when you are developing or implementing a new solution you can't deliver software in small increment as it would usually take a very long time before you have a useful workable product.
In many cases you either deliver everything in one go or you deliver nothing. For instance the customer may be using a legacy old system that is in the process of being replaced by a new system. Before the delivery the new solution must be able to offer at least all the functionality of the old one otherwise the users would not be able to do their work anymore.
Yes internally you can plan sprints and complete small chunks of work but nobody really cares until everything is ready.
That kind of refutes the success which Zappos.com had with their MVP which was extremely bare bones yet enabled them to know that there was a viable business opportunity for selling shoes online.
I'd agree that for well established solutions, you are looking at an MMR more than an MVP, but for truly novel products, an MVP is often still sufficiently usable to gain market share and to gain confidence that the business idea is viable.
