2 (Not So Obvious) Best Practices for Using Agile PM Software

 

I always say that if I can get one \good point out of a hour long conference session, it was worth going. I'm at the PMI Global Congress in New Orleans this morning. About 15 minutes late, I popped into the Agile UNConference session and was immediately asked to facilitate a breakout on "Tools and Techniques for Communication in an Agile Environment."  I held rapid-fire 10-minute sessions with three groups and talked about a lot of things that you might expect.

Part of each discussion was about software and I wanted to share two high-value points with you on which there was universal agreement. The first is about starting well. The second is about delivering status in a high-trust way.

The WAY you train the team on the software makes all of the difference
There is only one effective way to train people on tools. It’s using the tool, methods, and actual project data all at the same time (in a training environment where you can check understanding – not just on the job).  The folks who were anti-tool in these groups admitted they hadn’t done it that way. Those who did seemed to be universally successful.

So if you do this, you’ll know in intimate detail how the software, relates to the work you are actually trying to get done. If you have that level of understanding of what’s going on, then the next point makes a lot of sense…

Use the software to communicate with executives (don’t add another layer)
Use the actual Agile Software or Project Room Board (if there’s no software) to present to senior management. It’s what is really going on, versus yet another interpretation of what’s going on. This not only creates a window into the actual work that inspires trust from management, but also eliminates additional documentation (status reporting) to a large degree.

Have you found these to be true as well? Please share any experiences you might have...