TECHNOLOGYBUSINESS ....................................................................................................................................................................
TECHNOLOGYBUSINESS ....................................................................................................................................................................
2 .
The Product Owner is not empowered to make decisions
Agile , particularly Scrum , emphasises change . Scrum teams understand that things can and invariably do change and therefore have in-built processes specifically designed to deal with it . One of the major blockers to this is the inability of the Product Owner , who is the voice of the business , to make quick decisions on behalf of the stakeholders . If the Product Owner is required to submit a change request every time the project takes a minor deviation , velocity and morale hits the floor and rarely recovers .
3 .
The Product Owner is unavailable
One of the biggest traps that newly formed Scrum teams fall into is reverting to the Waterfall practice of producing meticulously detailed up-front documentation and assuming that the job is done . In an iterative development project the requirements , or User Stories , are listed in a Product Backlog which is constantly being developed and prioritised by the Product Owner through the entire SDLC . This process ensures that only the highest priority requirements are delivered and that changing business priorities can be quickly addressed .
The Product Owner is literally the voice of the business within the team and for this reason must ensure that a high level of availability is maintained to allow the team to operate with maximum efficiency . A user story can be referred to as ‘ an invitation to a conversation ’ and in my experience this is 100 % accurate . The best engineers / testers I ’ ve encountered will not begin work on a story until they ’ ve had a conversation with the Product Owner to ensure that as much ambiguity as possible is removed . This practice ensures that the business need is represented through the entire iterative process .
4 .
The “ Definition of Done ” is poorly defined
Another pitfall newly formed , or poorly managed , teams can fall into is the never-ending development chasm . Another important role for the Product Owner is to manage the scope of the project by being the arbiter of the ‘ definition of done ’. Software projects , if left to their own devices , will never be completed because there will always be something else that can be added , enhanced or removed . The Product Owner is responsible for ensuring that the features being developed have a well-defined end point and ensuring that this is communicated to the team and the stakeholders .
5 .
The Silver Bullet expectation
Scrum teams measure their productivity by ‘ Velocity ’ - Story points delivered per Sprint . This analogy is particularly apt considering that velocity is something that needs to be increased gradually . The most productive Scrum team is not going to be able to work at full velocity from day 1 .
18 CIO Magazine Spring 2015 Issue