A common problem on Agile projects is losing sight of the goal. When requirements are drawn up, priorities are clear, but can suffer from several problems further into the development. Several factors lead to the overall problem …
User Stories
It is important to not just consider user roles, but the actual users that will have those roles. This would be making dangerous assumptions on skills and availability. What is important to bear in mind for user stories, is the type of user that will have that user role. this reminds me of my original training in SSADM, a now largely forgotten methodology, as it focus was on the system itself. But the analysis philosophy was very focussed on interviews with the people who were going to use the system, taking account of personality and disposition towards technology.
The dangerous assumption amongst a lot of IT people make is that everyone is to some degree computer-literate. But computer literate does not mean an individual can efficiently do an IT job, and also does not mean they are happy having that job! Just being able to use the internet and email does not make an IT expert, or someone who will be happy with having their work habit and applications changing. One of the driving forces behind Agile, SCRUM, XP is people-focussed, and that people-focus should extend beyond the project team.
Development Driven
Unless there is a strong project management AND QA, it is easy for development to assume control on a project by default. PM’s used to Waterfall or PRINCE2 can miss out on the pace of Agile projects, by justifying periodic review outside of the iteration timetable. Though longer milestones are always wise once a project gains momentum, a tight reign is needed to ensure the requirements and business objectives are adhered to. It may turn out those requirements are impratical or redundant, but this needs to be evaluated and not assumed.
Subjective Testing
Much of the early testing on Agile projects is in the hands of developers, unless budget allows for testers to be seconded at these early stages (the ideal). The test management role reduces to a team leader style role during iteration testing, and a closer working relationship with the PM. But once first milestone has been reached, the role of the test manager changes to take in an overall view – i.e. traditional pain-in-the-butt QA Manager acting as quality gateway.
jaffamonkey 