Who's job is it anyway? (Score 2)

As a project manager who has run projects using a bunch of methodologies I would never expect my development teams to be responsible for managing the expectations of end users. That's my job. In my waterfall run projects, especially the ones with long schedules it's my job to set the expectation that if we agree on a design 12 months before we plan on delivering then change requests are to be expected. From both sides as well! Users will learn new things, understand their end state better and be impacted by changes in organisational goals. All of which will change their minds on the design we agreed and have been building. Similarly with development teams. Other projects will come along and change interfaces half way through, people leave, assumptions are proven wrong or right and this can involve more changes. In an agile project I generally tell my end users that I'll let them off the hook on locking down their requirements to the nth degree by the end of a phase, but in exchange for that they need to be prepared to engage with me and my team in what might look chaos from the outside but is just a different way of getting to the same end point. I remind them of this trade off along the way as well. My point is it's not the developers job to manage the expectations of what will happen in an Agile program. Developers should be left to do what they do best; develop awesome software that enables business to do what they want to do. Managing peoples expectations is my job. Josh.