Introducing Agile development after traditional project inception
- by Riggy
About a year and a half ago, I entered a workplace that claimed to do Agile development. What I learned was that this place has adopted several agile practices (such as daily standups, sprint plannings and sprint reviews) but none of the principles (just in time / just good enough mentality, exposing failure early, rich communication).
I've now been tasked with making the team more agile and I've been assured that I have complete buy-in from the devs and the business team. As a pilot program, they've given me a project that just completed 15 months of requirements gathering, has a 110 page Analysis & Design document (to be considered as "written in stone"), and where I have no access to the end users (only to the committee made up of the users' managers who won't actually be using the product).
I started small, giving them a list of expected deliverables for the first 5 sprints (leaving the future sprints undefined), a list of goals for the first sprint, and I dissected the A&D doc to get enough user stories to meet the first sprint's goals.
Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).
This has been pretty rough for me as a new project manager, but there are improvements I have effectively implemented such as scrumban for story management, pair programming, and having the business give us customer acceptance tests up front (as part of the requirements documentation).
So my questions are:
What can I do to more effectively introduce change to a resistant
business?
Are there other practices that I can introduce on the
IT side to help show the business the benefits of agile?
The burden of documentation is strangling us - the business still sees
it as a risk management strategy instead of as a risk. What can we
do to alleviate their documentation concerns and demands
(specifically the quantity of documentation and their need for all
of it up front)?
We are in a separate building from our business, about 3 blocks away and they refuse to have their people on the project co-habitate b/c that person "won't be able to work on their other projects while they're at our building." They expect us to always go over there and to bundle our questions so that we can ask them all at once and not waste that person's time with "constant interruptions." What can we do to get richer communication from them?
Any additional advice would also be appreciated.
Thanks!
