For the Software Project Manager
Before you make any commitments make sure they are going to be a win-win. A contract that calls for a fixed scope at a fixed price can be a win if the work is simple and well known. In software, it rarely is that. Look for red flags that foretell complexity such as a need to work with third party software that is not stable or well-known. Build agreements very carefully around any areas of code that have red flags.
Beware anyone who wants you to build them custom software and to assume all the risk. Never agree to a fixed price contract for doing custom work with requirements and software that are unknown unless you are paid a price that allows you to absorb a lot of risk. Anyone who has been managing software projects a while knows how easily you can lose money if requirements change (expand) and you are lax about getting change requests. If you are a software project manager- practice having that discussion about shared risk so that you are prepared when the time comes. If you are an individual developer practicing XP responding directly to your customer, make sure you are paid hourly. On the opposite end of the spectrum, if you are a project manager you in a large company with a Project Management Office, identify someone who can act as a Change Control Manager. The idea is to make sure the Product Owner understands the costs of high-risk activity and that to some extent even low-risk changes can put a project at risk by expanding the scope beyond the original estimates for time and cost.
In Scrum there is only one person responsible for setting the requirements, and that is the Product Owner. However, you can have problems because your Product Owner usually will try to expand requirements. Your Product Owner should ultimately be responsible for the business value of what is built. This means that when the Product owner must pay for additional features, he or she should pause to consider the value of having the work done. But, if you have agreed to a fix price contract then the Product Owner cannot easily see how expanding requirements hurts them. It does hurt them of course, it makes finishing the work slower and the project may run out of money.
He was looking for me to discuss risk, set appropriate expectations, and find ways to mitigate risk for both the Product Owner and Development Team.
I took Scrum training from one of the inventors of Scrum, Ken Schwaber. I came to the class well read and well practiced at using Scrum. I had all the answers. Until he set up a high risk scenario and role played being a customer- asking me- could I commit to doing this work on time and on budget? Yes! I proudly replied. And then I learned how little I really knew. He was looking for me to discuss risk, set appropriate expectations, and find ways to mitigate risk for both the Product Owner and Development Team. He wanted us to learn from his years of experience in building software. It was a little embarrassing, and you think I would have remembered it. But, later when a high risk project presented itself and I was given a chance to use what I had learned, I did it again. Yes! I said. And, I forgot to discuss realistic expectations, shared risk, or investigating third party dependencies before making commitments. Then, I crawled trough broken glass to deliver what I promised. A more professional approach would have been to refuse to accept all of the risk alone and to create a contract where the Product Owner had to share the consequences of change requests.
For the Software Developer
It is recommended now to avoid the c-word (commitment) and instead to discuss what you intend to do. What many managers experience as “The developers have no commitment” is really the opposite. The developers do not want to commit to something when they believe they cannot have absolute certainty of success. So they avoid the word. I don’t think it feels great. Call us crazy, but our team loves a challenge. We love to call out our goals and stay after them until we accomplish exactly what we set out to do. Saying what we intend to do just does not have the same motivational power as stating things as a commitment. So, how can teams make commitments that feel great from the day they make them all the way until the day they deliver them?
First, avoid committing to doing too much too fast. There isn’t a developer alive who hasn’t assumed a piece of work would take six hours that ended up taking twelve at least once in his or her life. Who hasn’t spent hours debugging something to discover it was a comma out of place? Build some padding into your estimates and enjoy surprising the customer by always taking less time.
Second, recognize the way coding frequently happens is this- the majority of stories in any month-long sprint or quarterly release will fall within the expected estimation. Extra padding isn’t necessary at all for experienced Agile teams who have gotten good at estimating. Your eight point story will turn out to be a medium-large almost every time. Every occasionally the estimate on a story is way off, not a little off but way off. You needed a spike to learn that your assumptions about a story were not correct. As soon as you recognize this- alert everyone and try a spike to gain more information. The idea is to increase transparency about why something is much harder than expected and to generate alternative ideas that might keep the project on schedule.
The key is to focus on risk frequently- look for risks, discuss them not only within the team but also with the Product Owner, document them, and do not shoulder them alone (unless you are being paid really well to shoulder all the risk alone.) If you have a conversation with a client that explores the fact that unknown requirements and dependencies on unknown or changing third party software is risky business, then you can commit to things that you know are achievable. Commit to doing the work. Commit to investigating possibilities. Commit to a clear Definition of Done. Commit to figuring out something that is a win-win. Your customers will respect your professionalism and your team will enjoy succeeding in keeping these commitments.