We use the web in almost all aspects of our lives today. In fact I can’t remember when the last time I needed driving directions and didn’t turn to a browser. This ubiquity gives everyone a frame of reference to suggest ‘How’ something should be instead of defining the problem. You’ll know your in a ‘How-Wow’ party when the ideas and examples are flowing but you don’t have a solid problem statement. And while brainstorms are great it can be distracting and take you off target.

Keep things on target by grounding your team in problem statements and measures. Saying, “Let’s focus on the what not the how” and using open ended statements such as “This program will be successful when…” can be helpful. When all else fails ask for discrete numbers. Nothing is as sobering as numbers, especially these days.

What school of thought does your organization follow?

While I appreciate the 15% of MS Word features that I actually use, it is important to keep your products Market-Driven and ensure you’re ‘connecting the dots’ with real business value not just developing features for the sake of features.

“Dogma (the plural is either dogmata or dogmas, Greek δόγμα, plural δόγματα) is the established belief or doctrine held by a religion, ideology or any kind of organization, thought to be authoritative and not to be disputed, doubted or diverged from.”

Have you ever noticed that when it comes to development methodologies some people treat it like dogma? Here are some obvious benefits of adopting a methodology:

1.) It helps us know what to do
2.) How to talk with each other
3.) Helps get new folks up to speed

Methodologies are tools and as the saying goes, “Pick the right tool for the job.” Every organization and team is different and you should pick the methodology that best fits the need. From Waterfall to RUP to Agile and every variant in between, each methodology has it’s own merits. The real question is what methodology works for you and your organization, not that Agile is the best or Waterfall is the only way to go.

There is rarely one ‘right’ way to do things or what your doing now will always be the best. A lot of smart folks are constantly evolving software methodologies and the next ‘best’ methodology is right around the corner. While I find that agile methodologies have been more in-line with the companies, teams and products that I’ve managed I may look at integrating waterfall if I started a two-year banking project. Keep your options open and while you may not adopt the latest or the oldest you may learn something that you can apply today.

Software methodologies are working models that continue to evolve over time. I know folks that were convinced the waterfall process was perfect when they were first exposed to it. I believe that selecting the best software methodology is situational depending on the organization, actors and product/project. Many professional service firms have a four or five stage variant of the waterfall process i.e. (Discover, Define, Design, Develop, Deploy) or (Discover, Architect, Build, Deploy). This makes sense, as most of their engagements are projects with a start and stop around a fixed set of requirements. Once the project is complete, they move on. Conversely if an organization is managing a software product, they have ongoing product management activities that can be tough to manage with waterfall. Agile may be a much better fit for organizations that have fixed development resources, continuous development needs and more variable business requirements.

Even in a professional services capacity I’ve seen an agile approach work great when there weren’t any defined requirements and a short deadline. It provided the client a way to quickly prioritize and understand implications of their decisions. You don’t have to practice agile to appreciate short meetings where people ask what was accomplished, what will be accomplished and what are the risks. The 37signals team follows a very light approach that enables them to make quick iterations on their products. While that approach doesn’t exactly translate for larger organizations with a large number of stakeholders it doesn’t preclude larger organizations experimenting with iterative methodologies. The danger is taking a polarizing position where a methodology becomes ideology.

We should standardize for the right product, project, process and organization but not to the point of exclusion. Experiment with the methodologies and associated tools that make sense. All methodologies change over time but remember it is just a means to an end.

“Don’t let your ego get too close to your position, so that if your position gets shot down, your ego doesn’t go with it.”
-Colin Powell

Reference and Further reading
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Software_development_process
http://versionone.com/Resources/AgileBenefits.asp

I’ve been heard to say on more than one occasion, that I don’t care if it runs on cheese as long as it works. The purpose of that statement is to keep the business team focused on business problems and help them drive the solution by defining the requirements, user experience and business rules. With that said, product management still needs to be cognizant of implementation details since they will often be constrained by them later.

In a perfect world, technical decisions made today would have little bearing on functional options tomorrow. Unfortunately, in practice, that’s not true and we find the ‘NO” response from development is rooted in a technical decision made previously. Long-view thinking in technical architecture is required to scale. ‘Tossing over the Fence’ does not provide context for the long-term decision making but there are some things product management can do to overcome the disconnect.

While there is no silver bullet, a collaborative and evangelistic ‘tell-all’ strategy can help. By defining, posting, sharing, and discussing a long-term roadmap, product management can help overcome the segregation challenges. A roadmap that outlines the laundry list of business objectives and corresponding functionality gives way to discussion across organizational barriers.

“Make sure you know what you are building. Many project delays are because the ‚Äúcustomer‚Äù- the manager, corporate head, (you?) doesn‚Äôt actually know what they want.”

Too often in the project-based world getting a solid vision of what is trying to be accomplished is tough. The other ‘gotcha’ that always pops-up is find the decision maker. If you don’t know who ultimately says, “The job is complete” or if there are multiple stakeholders make sure you get it in writing. A simple document that outlines the decision makers can save a lot of pain and rework.

In my experience, ‚Äògood‚Äô developers don’t want requirements thrown over the fence but would rather take an active role in not only understanding but contributing in defining the solution. The myopic view on process-driven development often leads organizations to view the development process as a machine and people as cogs in that machine.
Too often this goal of optimization, titles and processes (which are all necessary) can reduce a developer to a ‘cog’ in the wheel. While the ‘plan’ sure looks good on paper, it doesn’t account for job satisfaction, growth or passion. While developers can be technology focused, enabling the technology team as a contributor further up in the process provides rewards in passionate developers downstream.

A CEO once asked me, “What are processes for?” I responded with the standard answer about efficiencies, standardization among other reasons and he stopped me. He said, “Processes are so people know what to do. And, when they don’t work, thats OK, we just modify them.” Processes are necessary but rarely do they inspire.

Inspiration comes from people working together and from my experience, involving the development team early yields a better solution, quality product and ultimately satisfied customer.