Limiting Product Owner Powers
When product owners are highly limited, the results of the project will likely suffer. Product owners must be able to adjust the scope of the project as well as resources and team members, allowing higher chances of success. It is important to let the product owner truly own their product, and trust their judgement in what is needed rather than constrain them.
Habitual Ways of Working
A lot of agile team members who have experience with projects before agile will fall back on what they know has worked in the past. This often happens during complications or setbacks. The Boston Consulting Group says they have “found that agile teams experience a dip about two to three months into a transformation, but they ultimately embrace agile change and continue to work at a high level. (1)” It will take time, coaching, and training to help employees stay on course.
Too Much Time on Planning
Instead of planning every little detail during the planning phase of the project, an agile team should be getting feedback constantly during scrums and retrospectives. The feedback will be used to amend the initial plan. The product backlog begins to build each sprint, and is always subject to change.
Contrary to common belief, it can be best for the team members to take it upon themselves to step up to the plate to tackle different tasks. After all, the team knows what it can do more so than the project manager or leader. Use this practice instead of waiting around to be assigned.
Absence of Product Owner
It is a very prominent misconception in newly-agile environments that the product owner is not wholly a member of an agile team. The PO should be present at each scrum and available to the team during the workday. The only time a product owner may be unavailable is when they are working with different stakeholders and business personnel, however this should be avoided whenever possible.
- “Avoid Common Pitfalls in Agile”
- “Top Pitfalls of Agile Development”
- “24 Common Scrum Pitfalls Summarized” Mishkin Berteig. http://www.agileadvice.com/2011/12/05/referenceinformation/24-common-scrum-pitfalls-summarized/