1. Did not contain the length of Backlog items:
I allowed it to expand. While backlog can be stretched and it can theoretically expand to infinity, it is a real bad idea.
This means that project planning did not factor in the schedules or was deferred to later stages of the project to accomodate moving targets based on users requests. Although a subset alone needs to be taken in Sprint, the inter-dependencies between feature sets and integration challenges with mounting scope always carry the mine to derail the project. Easier to understand, but it took me a beating to realize the importance.2. Pile up Ahead in Queue: While fresh development was executed in Sprints well, it all piled up ahead in queue in review-fixes stage. This Sprint is where all problems originated.In my project, there are 4 dependent stages where reviews are done by clients and vendors. While we executed a batch and delivered it to the review stage, in interest of time, we moved into a fresh Sprint, than waiting for review cycles to complete. Thus a Sprint was defined till a review stage. The issues in earlier sprints started coming in during reviews and some had a global impact. When we took the fixes in a separate sprint, the length of that Sprint backlog became high (due to a combination of multiple sprints) that it slowed down the project progress considerably. Thus final closure got delayed till all dependencies were cleared across all the deliveries in earlier Sprints.3. Bring in more people in middle of Sprint: 2 new resources were brought in the middle of sprint and they were expected to test the features based on understood logic and functionalities. With no background, they let issues pass through to the deliveries. These issues then extended the Sprint thereby affecting start of other Sprints. In the end, the timelines of the project had to be shifted before final deliveries started to happen.
4. Did not enforce sign offs and Prioritization at start of Sprint: Well, this was done at an informal level. But closure of a Sprint through Sprint reviews and Retrospectives, didn't happen formally. This led to a major escalation, that was then brought under control.
5. Clients and Vendors were not fully in SCRUM Wagon: While we pulled in SCRUM practices and principles, the roles of clients and vendors and their roles within the SCRUM project weren't fully articulated. We had their buy-in for sure. While Agile and SCRUM presented a good development picture and initially worked well for shorter deliveries and near to final shippable products till the control was with us, the complete cycle was not implemented within the SCRUM vocabulary (like Sprint Planning, Sprint Reviews, Sprint Retrospectives, etc) involving all stakeholders from clients and vendors alike. There wasn't an issue with this, but may be if this would been practiced, the schedules, efforts and planning would have become an easier affair.Did I screw up my SCRUM project. No. It is just that these didn't work well or that they weren't done as prescribed.
May be call it a "Theories vs Practice", "Knowledge vs Experience" or "Go by Book vs Customize for the needs" paradox in which these issues got uncovered. A lot wiser and a lot less inhibition in going with my next SCRUM implementation .
I allowed it to expand. While backlog can be stretched and it can theoretically expand to infinity, it is a real bad idea.
This means that project planning did not factor in the schedules or was deferred to later stages of the project to accomodate moving targets based on users requests. Although a subset alone needs to be taken in Sprint, the inter-dependencies between feature sets and integration challenges with mounting scope always carry the mine to derail the project. Easier to understand, but it took me a beating to realize the importance.2. Pile up Ahead in Queue: While fresh development was executed in Sprints well, it all piled up ahead in queue in review-fixes stage. This Sprint is where all problems originated.In my project, there are 4 dependent stages where reviews are done by clients and vendors. While we executed a batch and delivered it to the review stage, in interest of time, we moved into a fresh Sprint, than waiting for review cycles to complete. Thus a Sprint was defined till a review stage. The issues in earlier sprints started coming in during reviews and some had a global impact. When we took the fixes in a separate sprint, the length of that Sprint backlog became high (due to a combination of multiple sprints) that it slowed down the project progress considerably. Thus final closure got delayed till all dependencies were cleared across all the deliveries in earlier Sprints.3. Bring in more people in middle of Sprint: 2 new resources were brought in the middle of sprint and they were expected to test the features based on understood logic and functionalities. With no background, they let issues pass through to the deliveries. These issues then extended the Sprint thereby affecting start of other Sprints. In the end, the timelines of the project had to be shifted before final deliveries started to happen.
4. Did not enforce sign offs and Prioritization at start of Sprint: Well, this was done at an informal level. But closure of a Sprint through Sprint reviews and Retrospectives, didn't happen formally. This led to a major escalation, that was then brought under control.
5. Clients and Vendors were not fully in SCRUM Wagon: While we pulled in SCRUM practices and principles, the roles of clients and vendors and their roles within the SCRUM project weren't fully articulated. We had their buy-in for sure. While Agile and SCRUM presented a good development picture and initially worked well for shorter deliveries and near to final shippable products till the control was with us, the complete cycle was not implemented within the SCRUM vocabulary (like Sprint Planning, Sprint Reviews, Sprint Retrospectives, etc) involving all stakeholders from clients and vendors alike. There wasn't an issue with this, but may be if this would been practiced, the schedules, efforts and planning would have become an easier affair.Did I screw up my SCRUM project. No. It is just that these didn't work well or that they weren't done as prescribed.
May be call it a "Theories vs Practice", "Knowledge vs Experience" or "Go by Book vs Customize for the needs" paradox in which these issues got uncovered. A lot wiser and a lot less inhibition in going with my next SCRUM implementation .
via ScribeFire
No comments:
Post a Comment