Project Management Words of Wisdom
I have been told by people who have been part of the projects that I have been the project manager of that I am good at what I do. Many of them have wanted to work with me again, which I know is a high compliement. As a thank you for the feedback I have received and as a way to help other project managers I am going to post my Words of Wisdom.
Bad news early is an opportunity. Bad news late is always bad.
One of the advantages of using Agile is that we expose problems sooner. By sharing bad news early the whole team has a chance to know what is going on and we have a chance to work on fixing the problem. Exposing bad news means that you might get the help you need sooner and therefore find a solution sooner. By finding out about bad news early we also have time to do something about it.
Waiting to share bad news is only delaying the inevitable moment when bad news is going to be exposed and everyone is going to want to know “Why didn’t we know about this sooner?” And if the bad news comes there might not be time to do anything except to recover from the disaster.
It is better to have three stories totally done (thru QA) than ten stories partially done
A user story has no value to the business until it has been QA tested and accepted by the business. To be very clear a user story which has been coded and unit tested has zero/no value to the business. So if we have 10 user stories each worth 8 points and all 10 of them have been coded and unit tested and all of them were given to QA the last few days of the sprint then they are worth zero (0) story points for this sprint. In a way that means all that hard work done by the developers had no value.
But if we double and potentially triple team a few user stories at the beginning of the sprint and get five (5) user stories done (QA tested, bug fixed & retested) before the end of the sprint, then we have earned 40 story points. And that has value to the business.
The approach of having multiple developers work on a single user story is slightly less efficient for the developers and it will force more discussion between developers. It will also improve software cohesion and should lower the amount of software coupling because the developers will have to agree on interfaces as they do their work. We will also end up with multiple people who know a user story.
The overall effectiveness of the team will improve because we will provide QA with testable user stories early.
“We run this company on questions, not answers.” Eric Schmidt, CEO of Google
Isaac Newton asked, “Why does an apple fall from a tree?” and, “Why does the moon not fall into the Earth?”
Charles Darwin asked, “Why do the Galapagos islands have so many species not found elsewhere?”
Albert Einstein asked, “What would the universe look like if I rode through it on a beam of light?”
We grow as human beings by asking questions and finding out what the answers are. I have found that as long as I am still asking questions I am growing both professionally and personally.
Why don’t we ask questions?
Sometimes it is because we are lazy. We think we know everything.
Sometimes it is because we don’t want other people to think we are ignorant, stupid or uninformed.
Sometimes it is because we had a bad experience in the past when asking a question.
Sometimes it is because we are too busy to stop and ask a question or two.
Sometimes it is because it easier to defer to a person in (actual or not) authority.
“The perfect is the enemy of the good.” Voltaire
One of the things we need to learn as we are doing Agile software development is to build software that is good enough for the task at hand. We need to implement software that meets the needs of the user stories as the user stories are written. We need to test the software so that we make sure the software meets the acceptance criteria of the user stories as they are written.
There are times when we are implementing software that we think "I could just add that extra bit of code to support 'x', which isn't a requirement in the user story but I know it will be." There is a Standish Group "Chaos" Report from 2002 which points out that only 20% of all software features are used either always or frequently.
This problem can also show up with testing, if the team forgets that 100% code coverage or test coverage is only a goal to strive for not one we actually expect to achieve.