Fitting a square peg in a round hole
-
I'm just reading around some agile development methods. For example, this one: link[^]
For established organizations, Scrum is very hard to deploy. Moving from yearly or semi-annual releases to weekly iterations is very, very hard. And very easy to fail at.
This is the very problem I've got. We sort of outsource work to a small development team. They are trying out Scrum, and because they are so small, they were able to switch onto it fairly well. But I have on one hand these people that work in agile ways and on the other hand report to bosses expecting waterfall development. I'm well aware I can't solve this problem overnight, so I'm just casually gathering information. What are people's thoughts on this kind of situation?
Almost, but not quite, entirely unlike... me...
-
I'm just reading around some agile development methods. For example, this one: link[^]
For established organizations, Scrum is very hard to deploy. Moving from yearly or semi-annual releases to weekly iterations is very, very hard. And very easy to fail at.
This is the very problem I've got. We sort of outsource work to a small development team. They are trying out Scrum, and because they are so small, they were able to switch onto it fairly well. But I have on one hand these people that work in agile ways and on the other hand report to bosses expecting waterfall development. I'm well aware I can't solve this problem overnight, so I'm just casually gathering information. What are people's thoughts on this kind of situation?
Almost, but not quite, entirely unlike... me...
Explain to the Higher up that waterfall method is to rigid a structure and that it does not cope well with changes in functionality, which are bound to occur in this day and age. Explain benefits of scrum. Also with this method you are going to be able to give monthly updates, (2 sprints or so) which should have tangible deliverables. (as per the scrum method) Even if those deliverables are sample or test systems. I had the same problem first time using scrum, you just need to be strong and explain the benefits, flexibility, visibility and transparency. They should be able to look into the scrum and see what is going on without disturbing you, and if the backlog of work is maintained priorities of work can be moved right up till sprint planning without any problem. Hope this helps.
James Binary Warrior.
-
I'm just reading around some agile development methods. For example, this one: link[^]
For established organizations, Scrum is very hard to deploy. Moving from yearly or semi-annual releases to weekly iterations is very, very hard. And very easy to fail at.
This is the very problem I've got. We sort of outsource work to a small development team. They are trying out Scrum, and because they are so small, they were able to switch onto it fairly well. But I have on one hand these people that work in agile ways and on the other hand report to bosses expecting waterfall development. I'm well aware I can't solve this problem overnight, so I'm just casually gathering information. What are people's thoughts on this kind of situation?
Almost, but not quite, entirely unlike... me...
We are in this position as a development team. You have to understand agile, so that you can make sense of what your developers are saying to you, and you need to be able to massage the reporting that you get from agile development into the format that your business processes require. If you can bring your bosses on board with the agile process then that will obviously help. From a waterfall point of view, 'agile development' is just development. The big difference is that you don't have a big requirements gathering or design phase before hand; instead, those are outlined in advance but fleshed out and modified throughout development. You get quite good metrics from agile development – each sprint you get a report of how many points have been taken and completed, and you can use those to make forecasts about progress, much more easily than you can with a normal waterfall project.
-
I'm just reading around some agile development methods. For example, this one: link[^]
For established organizations, Scrum is very hard to deploy. Moving from yearly or semi-annual releases to weekly iterations is very, very hard. And very easy to fail at.
This is the very problem I've got. We sort of outsource work to a small development team. They are trying out Scrum, and because they are so small, they were able to switch onto it fairly well. But I have on one hand these people that work in agile ways and on the other hand report to bosses expecting waterfall development. I'm well aware I can't solve this problem overnight, so I'm just casually gathering information. What are people's thoughts on this kind of situation?
Almost, but not quite, entirely unlike... me...
Scrum is ideal I used to use OnTime to keep track of development progress it is really a great product and their explanation of scrum (Video) is till the best I have seen online. Thing is usually with diferent customer needs comes the need to adjust , if your BA's mess up early in spec meetings it means your project is going to miss its dealine from the start . Sad thing is when BA's mess up they not the ones sitting with the developers till 3 in the morning while they code, and usually the devs that gets flak for bugs they didnt have time to test for. Best thing is to push the merrit of your methodology to business , thing is if you can give them nicely drawn reports they are usually very happy also scrum allows you to adjust your deadlines in the case of late spec.
Chona1171 Web Developer (C#), Silverlight