Every day, you get hundreds, if not thousands of chances to observe the amazing power of opposing forces. Just look up at the sky tonight and find the Moon. The centrifugal force is trying the throw it off the orbit, while the force of gravity is pulling it towards the Earth. The delicate balance of those forces is what keeps the Moon in place. If one of those forces weakens, we will either lose our satellite or witness its spectacular crash-landing in someone's back yard.
The same metaphor applies to software development. The Product Manager pushes hard to get more requirements implemented sooner. The development team pushes back on the requirements and asks for more time. I would postulate that the project is healthy when these opposing forces are in equilibrium.
The responsbility to maintain the equilibrium lies on the shoulders of both parties. While the Product Manager should obviously refrain from making wildly unrealistic asks of the development team, making too few asks will cause the project and product to lose momentum and stagnate. Too many asks, and the team will eventually burn out causing a loss of resources and product quality. On the other side of the fence, the development team can't obviously say no to every single request from the Product Manager, but they shouldn't be agreeing to everything either. Through the process of carefully evaluating the requirements against available bandwidth and timeline, the team should push back to negotiate a realistic scope and a realistic timeline for the project. A failure to do that will again lead to a burnout and a loss of quality.
The Scrum methodology provides a reliable mechanism to keep these opposing forces in check. On a Scrum project, the Product Manager is not allowed to change requirements in the middle of a sprint. The development team is expected to commit to a set of functionality they can deliver within a sprint. Keeping sprints short (2-4 weeks) allows the team to tune up their estimates from sprint to sprint, thus ensuring that the team's ability to meet the committments improves as the project progresses.
Scrum may be new for some people, and the fact that requirements won't be locked until the end of the project may be very unnerving to Product Managers (or clients) experienced in the traditional Waterfall methodology. Therefore, educating them on how the Scrum methodology works is a key factor to the success of a Scrum project.
No comments:
Post a Comment