Estimating time for software development in groups can be tricky. The first person's response often plants an idea in the heads of the rest of the group, leading to an incorrect estimate. One way of getting around this is to play a few rounds of planning poker.
Your clients may not understand why you follow certain practices as a project professional. They may encourage you to take shortcuts that they believe will save time, money, and difficulty. You know better, but how can you convince them?
We recently sat down with Payson Hall ahead of his upcoming 2012 Better Software Conference East presentation titled "Twelve Risks to Enterprise Software Projects - And What to Do about Them" in order to learn more about his experise in the field of risk management.
While everything should be done to avoid project failure, it does occur. When it does, management and the team must look into why a project failed, to avoid repeating mistakes in the future. Failure must be more than simply accepted or allowed. It also needs to be closely analyzed.
This article explains methods to build a team that will embrace "required work" and deliver robust software in a predictable fashion. It proposes a measure that helps calculate the throughput of an agile team by comparing work committed to work actually done.
Payson Hall looks closely at the unique idea of not just providing better service to clients, but changing the client's perception of what defines good or bad service. We've gotten so used to "normal" that we've lost the ability to appreciate it. But this can be changed.
We need to test infrastructure upgrades carefully to avoid disruptions to our applications—whether still under development or running in production. A good regression test suite can do most of what’s needed, but what if you don’t have one? You can take the time to create a new regression suite, but consultant Fiona Charles recommends an alternative: Use a cross-functional team approach to identify and target upgrade risks directly.