After many years trying a vast variety of project management software, I've come to the conclusion that what matters most is the project manager, rather than the software. Nowadays when I consult with clients I advise them: "First, find a really good project manager, and then use whatever software they want to use." If you have a great project manager, and they prefer to keep track of everything on crumpled up napkins, then the whole team should be given an ample supply of crumpled up napkins. Great project managers are rare, but if you have a great one, you should let them set the parameters of project management for your project.

When you have a bad project manager, good software will not save you. This is my personal story of how things can go wrong:

-----------------------------------

At 2 PM we had a meeting scheduled to go over all of the tasks in PivotalTracker. John had promised Milburn that we would execute our work according to a project-management philosophy that the tech industry called agile. Agile software development, among many other aspects, focuses on the delivery of small, incremental improvements to software. It encourages self-organizing teams, evolving and continuous progress, and rapid response to challenges faced. The Celolot team would work two-week sprints, checking in at the end of each period to see where everyone was at.

Unfortunately, vague definitions of “done” haunted our progress. John read through a long list of tasks that had been assigned to Sital.

“Find all possible variations of ‘Close Date,’” John read from the screen. “Is this done?”

“Yeah,” muttered Sital. “Sure.”

His assurance meant nothing to me. Sital would never lie, indeed I was often surprised by his childlike honesty, but he lacked an appreciation for the many ways that software could break.

“How many variations have been tested?” I asked.

“Two,” replied Sital.

“That’s not enough,” I said.

“That’s enough,” countered John. “‘Close Date’ and ‘Contract.’ That’s all we need.”

“What about ‘Close’?” I asked.

“Oh, yeah,” John thought aloud. “What about ‘Close’?”

“I’ll see,” Sital responded somewhat robotically.

John marked it as done.

“Wait,” I objected. “That is not done.”

John turned back to Sital. “Do you think you can finish today?”

“Absolutely,” Sital assured us.

“Then I’ll mark it as done,” said John, returning to his screen.

“But it’s not done till it’s done,” I argued.

John pondered this for a brief moment. “It’ll be done today,” he shrugged. He marked it as done.

In my view, John’s casual use of the word “done” to refer to items that were nowhere near done meant that this whole effort to track tasks was a useless ceremony. But John felt good about it. He could tell Milburn that we were following a two-week sprint, just like an authentic agile team.

It was true we had the accoutrements of an agile team. We used PivotalTracker. We broke down goals into fine-grained tasks. We reviewed the task list once a week, and we added more tasks every two weeks. But the whole thing was mockery of what the Agile Process was supposed to accomplish. If you have programmers who cannot finish assignments, then there is no point in pretending to be making progress.

----------------------

related to here:

https://www.amazon.com/Destroy-Tech-Startup-Easy-Steps/dp/09...