Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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!

share|improve this question
1  
I feel your pain. Seems you're "correctly" introducing agile techniques iteratively. Stay the course. Hopefully you'll get some helpful responses. –  sfuqua Apr 3 '12 at 15:00
5  
Unfortunately, it sounds like you're being forced into practicing "cargo cult agile". You can either muddle through with the pretend Agile game, try the politically unpopular game of pressing for real Agile, or prepare your resume and find another game that's more to your liking. –  jfrankcarr Apr 3 '12 at 15:08
    
@jfrankcarr - I've never heard of cargo cults before and had to go read up on them. That was (sadly) a very apt analogy. –  Riggy Apr 3 '12 at 15:31
1  
@Riggy The joys of being a consultant. Nine times out of ten, the person paying you to find and fix the problem is actually indeed the problem. You may have total buy in from the developers, but your management simply doesn't get it. Agile isn't process, it is culture. These kinds of culture shifts simply don't happen in an established business until directors and executives start getting replaced. –  maple_shaft Apr 3 '12 at 15:43
1  
You might want to consider moving this to pm.stackexchange.com –  Permas Apr 5 '12 at 12:49

5 Answers 5

up vote 8 down vote accepted

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.

share|improve this answer
2  
CYA is the name of the game. The people paying you WANT you to find and fix a problem and they either realize or do not realize that they are the problem here. This puts the OP in an extremely precarious position where he/she is politically being set up for failure before even starting. Management is NOT dumb. They realize that true Agile means they lose the illusion of fine grained control over operations yet outcomes are sufferring and they have to take some kind of action. Cue the political setup that is an Agile consultant. The blame can be shifted and the status quo carries on. –  maple_shaft Apr 3 '12 at 15:57
    
@maple_shaft Maybe I'm just being a bit naive, but I don't think you should jump to outright malice right away; it sounds more like the management in this case is worried about losing understandable-to-them deliverables. After all, a big thick manual and a fractal pile of Gantt charts are an easy sign that work has happened, even if they're not particularly useful. –  Tacroy Apr 3 '12 at 16:39
    
@Tacroy, while I don't think malice, would be completely accurate, from my 4th question, you can glean that there is a definite lack of trust and respect from the business to IT (and to be fair, it goes both ways). That's why I think jfrankcarr's cargo cult analogy was so apt - we tried to compromise by giving them a road map of the first few sprints and that was a slippery slide back to traditional. –  Riggy Apr 3 '12 at 16:47
3  
@Tacroy Sure, lets remember the old saying, Don't attribute to malice what can be explained by stupidity, however I have seen management do some very underhanded malicious things in my career out of desire to maintain the status quo. Pierre puts it nicely in his answer, You need to make sure more anxious people will not see your suggestion as a threat for their current comfort. They would feel threatened if you presented them with the truth and thus malicious actions follow to protect themselves. –  maple_shaft Apr 3 '12 at 19:13

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.