Introducing Agile development after traditional project inception

Question

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:

1. What can I do to more effectively introduce change to a resistant business?
2. Are there other practices that I can introduce on the IT side to help show the business the benefits of agile?
3. 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)?
4. 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!

Answer 1

I've been assured that I have complete buy-in from the devs and the business team [...] I have no access to the end users [...]

One thing to be quite clear on is the difference between being verbally assured that you "have buy-in", on one hand, and on the other hand the actual commitment from whoever is sponsoring your work.

My best advice to you is to set aside the label "Agile" altogether. Ban the word from conversation insofar as possible. Instead, focus on the following things:

• What results you are asked to deliver (you specifically, not the team)
• What the success criteria for your mission are (again, yours rather than the team's)
• What means you have at your disposal (including people, access to people, time, information, training budget, whatever)

"Making the team more agile" is not an actionable goal. It's not specific enough, it's not measurable, it has no end condition. What you need is something specific: a target expressed in terms of X percent fewer defects, or Y percent of your feature delivery dates actually honored, by Z date.

To reach these goals you may need to introduce changes. Now a few rules of thumb apply. Every improvement is a change, but not every change is an improvement. It's often said that people resist change, but actually people resist being changed and not knowing whether the change will be an improvement.

Focus on practices which you think will be easy wins, low-hanging fruit. Focus on the practices that establish a framework not just for implementing change, but for assessing the effects of change, and reassuring people that they are resulting in improvement rather than regression. "Information radiators" are good, as are retrospectives.

Some of these changes may be both necessary and perceived as threatening, like having more access to people who have key information. Don't compromise on these: "buy in" means a process of negotiation where you actually stand a chance of delivering what you're asked to, not being led like a lamb to political slaughter.

Try to set things up so that it's hard to shift the blame to you if things don't go right (and plenty will probably go wrong). Be aware that this might happen, and be prepared if it does happen: know your exit strategy.

Answer 2

In order to introduce a new thing smoothly, you need to make sure the people will not see it as a threat and permanent.

Many of us are naturally wired to avoid any sort of new things. It's biological. People usually seeking for novelty will never cause you any problem. You need to make sure more anxious people will not see your suggestion as a threat for their current comfort.

The ideal way for a team to adopt a practice or idea is to make sure the idea is coming from them, and not any external people such as the management, or worse, some random consultants. To make this happen, create brainstorming meetings with the whole team with only one topic. The topic should be the problem. In the meeting, you will have to bring carefully the ideas and come with arguments and facts.

We don't like to take decision on permanent stuff. We are already anxious by the effect of a potential change. That behavior is well know by pet shops. Buying a dog is a very big decision and will likely radically change your life. When you are at the store, the salesman will often propose you to take it back home, and return it if you change your mind. As you may expect, there are very few returns. The proposal has only one objective: reduce the anxiety that prevent people from taking decisions. Suggest to your team practice that you try for a fixed amount of time after what you'll evaluate its effect.

Regarding your second question, I highly suggest you to bring one thing at a time.

Your documentation problem deserve it's own post here on P.SE and I don't see any problem with the fact you are in two different building if both are willing to meet regulary. There are situation in which one of the side don't want to meet at all ;)

Answer 3

Agile isn't for everyone, it sounds like your business just likes saying agile because its the hottest buzzword. First of all it probably would have been a good idea to push for a brand new project or smaller maintenance projects to start making their process more like true agile methodologies. Trying to redesign a methodology using a project that is already underway is like trying to change a tire in the middle of an 8 lane highway. You need a way to show your business agile can work, but you need an environment where it has a chance of working, but based on what you have said agile is unlikely to work well with their established culture.

Depending on what they want for documentation you may be able to show them that this is generated automatically from a tool you are using, or is redundant and document B has the information document A was requested to show. You also need to adjust your plans for documentation, let them know why your estimates are changing, and ask them to reduce the amount of requested documentation or dedicate resources like a business analyst to create the documentation.

Answer 4

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).

That's your problem. They don't get it. Someone can't ask you to be more agile and not be willing to go along for the ride. They have the wrong expectations. Things are broken, up front, before you even start. Correct the expectations or you will fail. It's like me asking you to drive 150 MPH and I give you a Chevette in which to do that.

Answer 5

Build in the time/resource/cost of the documentation they want and let them see how far it pushes the schedule out.

This may help show them just how much work they are pushing onto the project team, and how this could be reduced if they weren't doing that.