Particularly in the software world, we are inundated by absolutes. Someone will argue that one platform is always the best, someone else will unequivocally state that outsourcing never works. Always this, never that: a barrage of absolute positions that take on the fervor of religious debate. I have learned that the only right answer really is "it depends", in every situation save one. There is only one absolute: that everything else depends on a clear, common understanding of the context of the situation.
All the other absolutes are hogwash. Decisions about which methodology to use, which language to program in, or even what the right ratio of testers to developers is, are often made as absolutes. While this might work some of the time, there will also be times where this will burn you.
These absolute decisions are made for all the wrong reasons. The whole industry is headed in that direction, so we had better jump on the bandwagon as well (think offshore outsourcing 5 years ago, think Agile today). It may be the belief that if it worked on the previous project, it will work for the next one. Perhaps it is the only approach that the team knows, so there isn’t even an awareness that a decision is being made. One of the most damaging reasons can be that it is the only approach that the consultant cares to pitch – and every prospect seems to need that solution, if they are inclined to pay for it (think the same two examples and time frames as before...).
The only absolute about software development that I have seen is that you absolutely need to understand the context of the situation if you are at all interested in successful decisions. Unfortunately, most teams fail to take the time to understand this context before making these decisions, and they pay the price. They may have already promised the impossible, or they may be trapped in the flawed perception that if the developers aren’t busy slinging code, the project is not yet progressing. It is far too easy to be busy, but headed in entirely the wrong direction.
I have been working with a company recently as they head down the path of developing a product for the first time, after years as a service-based group. We are engaged in analysis at this point, and have already stepped back from a debate about the relative importance of a list of features to a higher level discussion of user classes, use cases, and corresponding dialog maps and screen shots. While we have managed to channel discussions more clearly in a fruitful direction, there have been signs that we need to step back yet again. There are at least 3 different user classes or external systems that have been uncovered recently that nobody had thought of yet (how many more are there?). It was recently unearthed that the scope of the first release was seen as one thing to some of the people, something entirely different to others (what is in scope for the first round, and what to the subsequent releases look like?).
While we were moving more effectively than before, we were still stumbling, and all of those stumbles had to do with a missing piece of the system context. Everyone involved in making a decision has to have a shared understanding of that context. Getting to that point is a nontrivial exercise, but it is far better to develop that common understanding in a focused effort than it is to discover elements of this context throughout the project lifecycle, often when the cost of this discovery is significantly higher (not that it is ever measured, of course). Even for the largest of projects, a good understanding of the context would be enough information to barely fill a dozen pages, but the fan-out of ramifications is enormous. This context has several components.
There is the product/business context: identifying the specific boundaries of the system (the things I am developing or manipulating are internal, the things or people I interact with are external), the need we are trying to fill, and what makes us different from what already exists out there. Identifying what success for the business looks like at the end of the day – holding our feet to the fire, in terms of expectations.
There is the project/resources context (given that, particularly for large or complex products, it will take several projects to develop everything we want): knowing the constraints I need to work within, the gaps in my resources that I will need to work around, the risks that I will face, preferably by mitigating them rather than being broadsided by them.
We are stepping back to nail that context as effectively as we can at this point. Of that, I am absolutely sure.
Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.