I have the dubious pleasure of trying to provide documentation for a small application that is basically a helper application for our product. It’s NOT complicated and it shouldn’t be causing nearly the amount of drama that is currently occurring. This has been probably twenty times more frustrating than my big project.

Now, one thing to understand is that the doc team (of which I am a member) is not integrated with the project team officially. We are a separate organizational unit. With the product team of my big project, they use Scrum and I attend their weekly planning meetings and the daily standups if I feel I need to. They are very transparent and I can check the tracking log at any time to update my plans.

This little project (a single program manager, dev and tester) keep telling me they are “agile” but they have no idea what they are doing beyond having a daily meeting which seems to take an hour every day, pestering everyone else and changing schedules and basic assumptions so quickly I swear I am getting whiplash. There is No Clue here.

I’m frustrated – VERY frustrated – at this point. My team does run on a Scrum process and I keep having to defend my prioritization, my schedule and deal with each time they change their minds and (often) never tell me. The following seems to be unclear to them:

  1. Changing schedule dates – drastically – at least once every week or ten days does NOT mean you are agile. It means you have no idea what the scope of your task is and you are allowing schedule creep and bad planning to win while you rush to try to get this project out the door.
  2. Changing core deliverables and/or concepts without talking to those you depend on to provide you with something you must have before you can ship and which these changes affect does not make you agile. It means you are risking your project, your shipping and your working relationship with these people you are dependent on because you either think you can push them into doing your will or you are incapable of remembering your dependencies.
  3. Refusing to provide the requested information so a team you are dependent on can do their job and “rolling your own” version of what you think they need instead does not mean you are agile. It means you are unwilling to work with that other team and can come across as passive-aggressive or ignorant and the other team still needs the information they requested.
  4. When given a schedule by another team, pestering for updates constantly when they are meeting their schedule does not mean you are agile. It means you are annoying them and making them less likely to try to get things done early because they are spending that precious time responding to random emails on things that have already been discussed multiple times.
  5. Trying to push a release out the day before a three day holiday that backs up on a week when most staff are on vacation does not make you agile. It means you are foolishly focused on the earliest date you might bully people into shipping instead of having contingency plans for when things may go wrong
  6. Asking for documentation to be done off a non-finalized UI to “speed things up” does not make you agile. It means you are asking your doc team to write documentation at least twice and hoping they catch any instances of the non-final UI before the docs ship. Skeletons are okay, but you won’t get RTM ready docs.
  7. Shooting of wild plans from the hip does not make you agile. Disorganization, lack of ability to plan and think through processes as well as a lack of ability to track issues, decisions and schedules makes you a project from hell and someone that quickly becomes the person no one wants to work with.

That is all. My tongue may bleed soon from biting my tongue at work.