I have started using Pivotal tracker for a project I’m working on. Conceptually, this seems really cool and I’m interested in using the agile model. However, I have one problem with everything talked about in the video.
At 4:19 in the linked video they talk about story acceptance and how it should be done by the project owner. This concept sounds great on paper but I’m not sure I can actually get the project owner to sit down and try out even half of the new features I create, let alone all of them.
My question is: how do you approach a product owner about the work that this flavor of the Agile Model asks of them? What do you do if they refuse to participate in acceptance testing?
4
What you are mentioning is a classic problem that many companies have introducing agile development.
Unfortunately, there’s no easy solution.
-
For the specific problem of acceptance, the “standard” workaround is having someone in the team acting as a proxy for the product owner. This is not great but it can work as long as this person takes care to demo regularly to the owner so they maintain the same perception of what is accurate.
-
Product owners are supposed to work together with the team on a day-to-day basis. This is because typically units of work (i.e. stories) are negotiated during development. E.g. a UI for a story is not designed beforehand. Its design is negotiated during development, so design decisions are validated on a working solution instead of a piece of paper. There’s no easy solution here. If everything is decided beforehand, there will be quality issues or inefficiencies, because it’s really hard to design everything beforehand.
-
There’s often lack of clarity on what the acceptance tests of a user story are. An absentee product owner often will not provide enough, or any, acceptance tests to make it clear what the final “black and white” objectives of a story are. Unfortunately, this means that someone in the team, possibly a QA person, will gradually replace the PO on this matter and this is not a good solution, since many of these tests are quite arbitrary in nature and teams often end up disagreeing on when a story is complete.
-
Probably the biggest problem, though, is the lack of agility. Having a set of stories and a “perfect” idea of a product is not a good implementation of agile. If everything you need to do is known in advance, you probably don’t need this methodology. The strength of agile is that it maximizes the value delivered by changing the project scope and direction in flight to take advantage of the increased product knowledge that it’s acquired during development. If there is no one to guide this process, there is basically no point developing with a methodology only “theoretically” agile.
1