In the first post of this series, Spec’ing the specs: What should my software do?, we took a look at some of the high level considerations that go into planning software projects. In this post we’ll focus in on the online tools and processes that teams can use to capture project requirements.

Why do we need to document requirements at all? There’s no shortage of horror stories out there about the pitfalls of over documentation. You’ve probably seen a phonebook-sized spec document propping open an office door somewhere.

Documentation for the sake of documentation is a waste of time. But clear, concise documentation supports software projects in a few key ways:

• Clearly defined requirements guide your team’s decisions throughout the life of a software project
• Consistently recorded decisions remind your team why you made the choices you did weeks, months, and years from now
• Consciously deciding what your software should do makes it much easier to test that it actually does it once it’s complete

(more…)

As we all know, many software development projects fail to meet their objectives.   In fact, some projects never even define the overall objective; they simply dive in and start coding.

There are many reasons (just google it) why software projects fail: lack of direction, poor specs, an inexperienced development team, lack of any real testing and the list goes on.   Any of those issues can sink the proverbial development ship.  However, the issues I listed are merely the symptoms of a much larger disease.  In fact, many of them will cease to exists if you incorporate a simple principle into how projects “get done”.   That guiding principle is “partnership”. Partnership?  Yes, partnership. Sounds simple and even over-used, but it’s foundational to the success of just about any team effort.

In a “true” partnership” each party knows what is expected of them.  They each know the role they are supposed to play and realistic expectations have been established.  Unfortunately, most development efforts never address the importance of business and IT partnering for a common objective.  Instead, the coders code and the business people wonder why they don’t see screens yet.  This doesn’t happen everywhere, but it’s all too common.

So before you start that next project, set aside time to discuss how the “partnership” will work.  Listen and learn about the implied vs. explicit expectations of your partner.   For example, in my experience, there are two common implied expectations that seem to exists on any project:  1) the business will always expect to receive a reliable and testable application and 2) IT will always expect the business to provide clear specs and personnel to conduct meaningful testing.  Understanding and meeting those two expectations will go a long way to helping you achieve success, but each partnership is different and comes with its on set of rules, so be prepared to adapt.

To often, “partnering” is referred to as boiler-plate lip service or just another over used business cliche’. The truth however, is that no project can succeed without it.

Developers love creating software. They look forward to opening their editors and churning out new features. But before that first line of code can be written on a new project somebody has to decide what software should do.

A clearly defined road map for what software should do will help make the most of everyone’s time and efforts over the lifetime of a project. The tricky part is crafting the right road map for your project.

Documentation is the old standby. Does anybody read it? Meetings can be helpful. Do the hours spent really improve the product? Prototypes look like rapid progress. Are the subject experts able to make any sense of mockups?

This post is the first in a series on how development teams can better collaborate with their business counterparts to capture what software should do. This first post focuses on why road maps are so important. Another will dive deeper into different approaches for capturing requirements in a meaningful way. And a later post will look at taking that leap from a road map into construction.

(more…)

In a previous post, Dave mentioned how we are always thinking about ways to improve our software development processes at Bayside. As we grow and mature as an organization, our processes evolve. While we stay true to our core belief that a process should be simple, flexible, repeatable, and effective, we are always looking to improve. A clearly defined process won’t solve all of the issues associated with software development, but it will definitely reduce the chaos.

A development methodology is the core of a good software process.  However, there are no one-size-fits-all methodologies. While each “system” (waterfall, agile, etc) has its own merits, there is no silver-bullet solution that will fix your development process (or lack thereof). A methodology is just one link in the chain of a solid process. It’s important to look at the different methodologies available and adopt (and adapt) the one closest to you end-goal.

So what else do you need to make a process really work, here is a short list:

Methodology

Every good process needs to starts with a solid foundation. Even if you adopt you own form of a methodology, which is what most of do in reality, it is good to start by picking an existing one with a good track record. When picking a methodology, remember to consider where you want to be as development team vs. where you are today. I know that might seem simple, but I have seem many groups pick a method that closely resembles who they are vs. who they want to be. Again, it’s human nature to take the path of least resistance. Another recommendation: don’t pick an overly complicated or document-heavy methodology. You’ll notice I didn’t say document-free. You want to be productive, not mired in documentation.

Bottom line: Pick a methodology that is proven and includes the ideals of where you want to go as a team.

Management buy-in

I know, you are probably saying, “if I had a dime for each time I heard that one”, but this is one is critical. Without real support (i.e.: accountability for those who don’t align with the new process), the process will never take hold. People will not change if there is no consequence linked to NOT changing. It’s just basic human nature.

Bottom line: Wishy-washy leadership = no change.

Team buy-in

This does not mean everyone. You will almost always have the naysayers who like things as-is or want waterfall over agile or vice-versa. I recommend including your most trusted developers, the good ones, in the decision making process as you move to make changes. Defining “good” is outside the scope of this post but lets just say good doesn’t always mean the person who gets things done the fastest. This will help them to see you are committed to them and value their input.

Bottom line: Be inclusive but stay committed to the end result. Understand that some folks may leave because of the change. Be ready for that reality.

Document and Educate

Hey, I’m a developer, what’s with all the documentation? Documenting the process is important to ensure it is repeatable. Keep it simple. A wiki write-up or a simple, yet clear bulleted manifesto will suffice. Do not write a 200 page process document…unless you want it just collect dust. Make the process document available on your intranet to everyone can see it and be prepared to change it when necessary. Meet with your team and explain the points of the new process. Go over why you believe it is better than what you are doing today.

Bottom line: Keep the document simple and clear. Educate the team and make sure they know why the change is being made. People like to know why something is happening, not just that it’s happening.

Review

After each project, conduct a “post-mortem” to determine what went wrong and what went right. This will help to determine if changes are in order. Is your team more effective with this new process in place? Without these reviews, your process will never take advantage of lessons learned.

Bottom line: Be flexible. Always look to refine and improve.

A good process will yield good results consistently. But implementing a process or changing an existing one can be a painful experience for some organizations. My experience has shown that organizations that ignore the failings of their current processes, create an ever-growing amount of “tech debt.” That debt can become so heavy they collapse under the weight.  If you keep your processes simple and flexible, it can change with your organization and evolving technologies, enabling your team to be more responsive and efficient.

Take some time this week to review your software processes. Create a short list of items you know can be improved upon. You will be happy you did it.