When discussing how to run agile projects in a more traditional organisation a lot of the focus was around the tension around “iron triangle” projects where scope, schedule and cost are fixed which is very contrary to agile projects where scope often emerges throughout the course of a project.
One of the key areas discussed to address this was the importance of the role of a product owner in a scrum team as this person is generally the face of the project to the business and is key in earning and maintaining the trust of the stakeholders through transparency and regular updates.
There was mixed experience in the groups with some organisations having full-time product owners (often recruited specifically into the organisation to do that role) but others where the product owner role is assigned to someone who already has a full time day job and may struggle to juggle the commitments of the role.
This often leads to “proxy” product owners, subject matter experts taking on board some of the role, and in some cases panels of product owners for a single product. One thing that was universally agreed was that there must be a single accountable product owner at any one time – a “single wringable neck” who has the final say on scope.
Another area of discussion was that sometimes development teams implement agile practices but other business functions are not so responsive, for example there is often a dependency on teams to produce training or marketing collateral and these teams may be accustomed to lead time and absolute deadlines. With incremental and iterative releases and changing priorities these long lead times obviously cause issues.
Engagement with other teams with a dependency on a regular basis (such as sprint reviews, standups etc) obviously can go some way to keeping the business in the loop and allowing other teams the visibility of changing schedules and progress.
Often within organisations the road to agility is embarked upon by development teams in isolation, but where these teams have worked with other departments to explain and demonstrate the benefits of an agile approach it has been shown that these same practices can be adopted to manage their own workflow and their output can be delivered incrementally and iteratively in step with the output of the development team.
Please feel free to add your comments.
Practical Agile 