Up Front & Iterative Planning

You know the question..."what kind of projects are best suited for agile?".  To me, this is the same as asking "what kind of projects are best suited for empowered teams, technical excellence, servant leadership, reducing waste?".  Would there ever be a time when you would not want these things?  I know, that is a very smart-allec response, but I just can't help myself.

I then ask "what's the other option?".  This surprisingly stumps people when I ask this.  We all know there is no such thing as "true" waterfall in software.  So, to help them along, I clarify what I "think" they are asking which is "what kinds of projects are best suited for big, upfront planning and design vs. iterative & incremental delivery?".  People almost always agree with the restatement of the question.

I believe that everything can and must be done iteratively and incrementally in software.  However, the level of "up front" may change with the type of project.  Gutting out an old accounting system and replacing it with an Oracle or Great Plains solution will require more up-front planning and analysis than a green-field Web 2.0 social networking application.

So, fellow agilists, "up-front" is not a bad word, it has to be done.  We know this already with release planning, and even sprint planning, we just don't call it "up-front".  Just be careful...VERY careful.  You run the risk digressing into waterfall.  At times, there will need to be more "up-front" than other times.  Always be asking yourself, "what is the soonest we can deliver value to customer?".

The quest for the perfect agile tool

I've been searching off and on for the perfect agile tool for years. My "dream" tool would be a one stop shop for releases, stories, tasks, acceptance criteria, test cases, points, etc., etc. Oh, and by the way, it would be INTUITIVE.

When I enter a new team, I start the search over, and almost always end up back to stickies and/or spreadsheets. Currently I am using Acunote (http://www.acunote.com), and it seems to be doing the trick. It's missing a lot of things, but it's good enough for our purposes.

I've learned to not worry about tools until there is a solid foundation. The right team (technical lead, Product Owner, Scrum Master) and a product backlog must be in place first. Then, the core Scrum team can be formed because it is clear what needs to happen. Once the Scrum team is in place, ensure they are self-organizing. NOW, it's okay to start looking at tools ... as a team.

In the meantime, my quest will continue, and maybe someday that perfect agile tool will surface. But, if it doesn't, I'll just stick to stickies and spreadsheets and be happy!

Scrum Documentation

If you are on an agile team, and you are telling your team that you don't need to document because your "agile", stop it. Stop it right now!! You're making my life difficult!

There is a strong stereotype out there, and its that with agile, you don't document. Arggghhh!!! I'm sure some of you have experienced it.

Here is what I tell people when they ask about the documentation requirements on an agile project..."If the team needs it, then they will create it". Now, I'm not talking about documents that are delivered to the customer, like help documents. I'm talking about documents such as architecture diagrams, "requirements" documents (eww), process flow diagrams, diagrams, and more diagrams.

IF these kinds of documents will make the team more productive, and produce higher quality software then document! Now, the next thing I tell people is to be LOW TECH. I mean, c'mon, do you really have to transfer that diagram on the whiteboard to visio? I've seen people take 2 weeks to do that, as the rest of the team is "waiting", i.e WASTE. Why not take a picture? It's going to change anyway, right? And, we "want" it to change, if we ever want to improve.

Remember, the end customer does not value these kinds of documents. So, DON'T SPEND A LOT OF TIME ON THEM. If your company "requires" them, then take the lowest road approach possible. Ask questions. Challenge the "process". Processes were meant to change and improve, you should not be a victim to them.

Okay, to review....

• Documentation can be good, if it makes the team more productive and the customer happier because of higher quality. But, BE CAREFUL
  
• Low tech = Good
  
• The customer DOESN'T CARE about those documents, so just take it easy there partner. Only do the bare minimum that you NEED.