Let’s face it, lots of software projects continue to fail every year, even after so many advancements in the theory and practice of software development and business analysis. After working on countless complex software projects that delivered great business value, here’s what I learned about the reasons for a project to succeed.
While debates rage as to the effectiveness of meetings in general, and books have been written on meeting organization and management, I’ve found that often meetings go wrong before they even begin because the invitation is missing (or vague in) four critical components, without which the likelihood of full participation and effectiveness is diminished.
“Without requirements, there is no way to validate a program design; that is, no way to logically connect the program to the customer’s desires.”
— Benjamin L. Kovitz
If human communication and human memory were perfect, we may not need deliberation and documentation of requirements. Alas, neither is close to true. It is the iterative exercise of modeling requirements, and then documenting them that enables shared understanding to be affirmed, and then shared with those who use requirements to guide design, construction and quality assurance. Requirements are the link between concept and product, and an important standard for measuring solution success.
Poor grammar and spelling that cause a requirements model to be inaccurate, or difficult to understand and use, are serious because they negatively affect the documentation’s ability to serve its purpose. An otherwise solid, easy to understand document with some errors in grammar and spelling, is not as serious. In either case, poor grammar and spelling should be included in the offending analyst’s professional development plan, and improvement should be encouraged and expected.
Video attributed to ChicagoRuby. I’ve made learning about, and becoming better at story telling part of my personal/professional journey to become a more effective communicator. When I saw ChicagoRuby‘s video post of Alistair Cockburn, one of my favorite agile authors/methodologists, responding to questions […]
“Agile … is an attitude, not a technique with boundaries. An attitude has no boundaries, so we wouldn’t ask ‘can I use agile here’, but rather ‘how would I act in the agile way here?’ or ‘how agile can we be, here?’”
— Alistair Cockburn
I’d like to share one of my favorite agile quotes from Alistair Cockburn, because it summarizes my own perspective so well. In my observance, many fail to differentiate agile principles from agile methodologies, and end up with a prescriptive/dogmatic view of the correct way to do or be “agile” that misses the mark.
Whether you’re working in an “Agile” or traditional delivery environment, you can find ways to apply agile principles and keep a responsive mindset.