I just went through this process on the other side as an 18F client. Overall, I was happy with our experience, but the key (and in my opinion highest risk/reso

I just went through this process on the other side as an 18F client. Overall, I was happy with our experience, but the key (and in my opinion highest risk/resource investment) of their process was the identification and participation of the right product owner on the client side. If you use 18F you are buying talent and a process. Besides money, you are also commiting a major personnel resource as well. The key stakeholder is expected to spend a significant amount of time on the project on a daily basis. They also need to be someone senior enough to have decision making authority, ideally a historical perspective of how the organization works, and hopefully someone who had a moderate degree of technical knowledge. Thankfully we had that person, and we were able to reassign a portion of his portfolio to someone else for the duration of the project. If we didn't have a person that checked those boxes, the project would have been much more unlikely to succeed. The checklist itself is a fine starting point, but it's not going to be universally applicable in all cases. Again, this is why it's good to have that right key stakeholder. I understand that agile may be a useful process for software development, but software is a tool/means to an end, not a goal. I also think it's useful for folks in the software industry in general to have an honest understanding of the tradeoffs being made between different management processes. It's not a simple as waterfall bad, agile good. I'm curious how many people in this industry have real cross cutting (non software) engineering management experience. I get the feeling it's not a lot, which is too bad because those are the people you are designing tools for.