Re: [scrumdevelopment] Problems Implementing Scrum
- In addition to what Steven wrote:
1. How do you test the app, can the tests be used to demo?
2. This is indeed a product owner battle, I'd advise the IT team to stay away from these discussions - it is not your responsibility. You do have to advise on changed estimates to produce the software.
--HubertOn 2/16/06, Steven Gordon <sgordonphd@...> wrote:1. Dependency issue:You can "mock" what you need from the other application, so that the product owner can "see" it (and your team can better test it). Of course, you cannot deploy it until the other application has deployed what you depend on and the application has been retested with their live functionality.2. Budget issue:Meeting or exceeding agreed upon benefit seems like the best you can do. This would seem to be your product owner's battle, though you should support them. Still, it is up to the product owner to guarantee to the organization to only drive changes that increase the benefit delivered.
On 2/16/06, Koscho, William < william_koscho@...> wrote:
I've ran a few scrum projects for a variety of projects, but I'm on a new project now that I would like to get some advice on.
For each scenario below, keep in mind that our company works with a waterfall model, so my team often interacts and has dependencies on teams who use waterfall.
- My team builds a middleware application, and often has dependencies on the front-end applications. Therefore the product owner often cannot see the working result until the front-end application makes the necessary changes. As such, we have been working in 30 day sprints to deliver code, but cannot demonstrate it to our product owner because the front-end application takes 60 days to complete their development using a waterfall model. Unfortunately they are resistant to modifying their current process. I'm looking for some advice on how we can overcome this in a more creative way to get our product owner reviews and our feedback every 30 days so that we can start our next sprint.
- Our second problem is related to budgeting, scheduling, and estimating. Every 4th quarter, the development teams are given high-level ideas of what is going to be needed for the next year. The development teams estimate how much money they are going to need to build those things for next year. So by January, there is a bucket of money allocated for each project. That allocated money is only granted if the benefits are expected to be sufficient. If we can change the items on the backlog then the benefits can constantly being changing. So you have a baseline product backlog and when a new deliverable comes along with a higher priority (and more benefits) you bump the other deliverables on the backlog. So now, we have a fixed budget (from 4 th quarter) and our benefits are either those estimated or are better. However, I just don't have a good feeling about how we do this, and I cannot put my finger on why that is. It seems that we allocated money for some benefits and the benefits can get better for a fixed price; similar to a fixed-price contract. I just wanted to get everyone else's opinions on this to see if there is a better way to handle this situation.
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...SPONSORED LINKS
YAHOO! GROUPS LINKS
- Visit your group "scrumdevelopment" on the web.
- To unsubscribe from this group, send an email to:
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service .